Hosts im Subnetz können nur direkt auf das Hosts-Subnetz zugreifen

Ich habe kürzlich Proxmox als Virtualisierungshost eingerichtet. Es ist nur KVM + Debian in einer netten Linux-Distribution. Mein Heimnetzwerk ist 192.168.12.0/24. Ich wollte 192.168.14.0/24 als Subnetz für alle meine VMs auf dem Proxmox-Computer verwenden. Ich verwende DHCP, um fast alle meine Hosts zu konfigurieren. Wenn ich eine 'static-ip' möchte, konfiguriere ich im Allgemeinen nur manuell eine DHCP-Reservierung für das Gerät. Daher wollte ich, dass meine VMs DHCP-Adressen im Subnetz 192.168.14.0/24 erhalten.

Bei der Installation von Proxmox wurde eine Brücke mit dem Namen vmbr0bridged mit erstellt eth0. Die IP-Adresse der Bridge lautet 192.168.12.12.

Ich fügte hinzu, dass eine Brücke mit dem /etc/network/interfacesNamen vmbr14überbrückt wurde eth0.14. Ich habe ihm eine IP von gegeben 192.168.14.12. Ich habe auch im 8021qModul modprobe'd und es hinzugefügt /etc/modules.

Mein DHCP-Server befindet sich auf einem anderen Computer, 192.168.12.95auf dem sich eine Schnittstelle befindet eth0. Ich fügte eine weitere Schnittstelle namens hinzu eth0.14und gab ihr die IP von 192.168.14.95. Ich habe /etc/dhcp/dhcpd.confmit einem anderen Pool für das Subnetz aktualisiert 192.168.14.0. Die angegebene Standardroute ist 192.168.14.12das Proxmox-Gerät. DHCP funktionierte sofort ohne Probleme.

Damit Hosts im 192.168.12.0/24Netzwerk wissen, wie sie routen sollen, habe 192.168.14.0/24ich mein Internet-Gateway ( 192.168.12.2) aufgerufen und eine Route wie folgt hinzugefügt

192.168.14.0    192.168.12.12   255.255.255.0   UG    1      0        0 eth2

In der proxmox-Box ist die Weiterleitung für IPv4 bereits aktiviert

ericu@basov:~$ cat /proc/sys/net/ipv4/ip_forward 
1

Danach hat es einfach geklappt. Ich kann meine VMs problemlos von meinem Desktop aus per SSH und Ping erreichen.

Aber auf den VMs selbst kann ich nicht 192.168.12.95nur erreichen 192.168.14.95. Ich habe auf einer der VMs einen Ping durchgeführt 192.168.12.95und das Paket mit erfassttcpdump

ericu@katz:~$ sudo tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:50:16.007898 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 18, length 64
18:50:17.010380 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 19, length 64
18:50:18.012969 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 20, length 64
18:50:19.015433 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 21, length 64
18:50:20.018043 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 22, length 64

Die Pakete kommen offensichtlich an die Maschine, aber ich habe keine Ahnung, was danach passiert. Die Maschine antwortet einfach nicht. TCP funktioniert auch nicht.

ericu@katz:~$ sudo tcpdump -n tcp port 3000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:53:21.048128 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 665263 ecr 0,nop,wscale 7], length 0
18:53:22.051442 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 666264 ecr 0,nop,wscale 7], length 0
18:53:24.060540 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 668268 ecr 0,nop,wscale 7], length 0

Wenn ich versuche, auf die IP 192.168.14.95von den VMs zuzugreifen, funktioniert alles gut.

Wenn ich das mache ist ifdown eth0.14der Rechner 192.168.12.95dann von den VMs erreichbar. Dies ist offensichtlich nicht praktikabel, da der DHCP-Server erreichbar sein muss.

Warum können die Computer im 192.168.14.0/24Subnetz den Computer nur über die 192.168.14.95Adresse und nicht auch über die Adresse erreichen 192.168.12.95?

Das ist die Routing-Tabelle auf 192.168.12.95

ericu@katz:~$ ip route show
default via 192.168.12.2 dev eth0  metric 100 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.95 
192.168.14.0/24 dev eth0.14  proto kernel  scope link  src 192.168.14.95 
ericu@katz:~$ 

Dies ist die Routing-Tabelle auf 192.168.14.130

[ericu@squid3 ~]$ ip route show
default via 192.168.14.12 dev ens18  proto static  metric 1024 
192.168.14.0/24 dev ens18  proto kernel  scope link  src 192.168.14.130 
[ericu@squid3 ~]$ 

Um dieses Problem zu beheben, habe ich eine VM auf meinem Desktop erstellt. Ich habe /etc/network/interfaceswie folgt editiert

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp


auto eth0.14
iface eth0.14 inet static
    address 192.168.14.14
    netmask 255.255.255.0

Der Computer hat eine DHCP-Adresse auf eth0 von 192.168.12.172. Von konnte 192.168.12.130ich immer noch nicht darauf zugreifen 192.168.12.172. Auf der Test-VM habe ich geändert /etc/iproute2/rt_tables, um wie folgt auszusehen

#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
14 vlan14

Ich habe dann die folgenden Befehle ausgeführt

root@ubuntuvmdesktop:/home/ericu# ip route show
default via 192.168.12.2 dev eth0 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.172 
192.168.14.0/24 dev eth0.14  proto kernel  scope link  src 192.168.14.14 
root@ubuntuvmdesktop:/home/ericu# ip route del 192.168.14.0/24 dev eth0.14 src 192.168.14.14
root@ubuntuvmdesktop:/home/ericu# ip route show
default via 192.168.12.2 dev eth0 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.172 
root@ubuntuvmdesktop:/home/ericu# ip route add 192.168.14.0/24 dev eth0.14 src 192.168.14.14 table vlan14
root@ubuntuvmdesktop:/home/ericu# ip route add default via 192.168.14.12 dev eth0.14 src 192.168.14.14 table  vlan14
RTNETLINK answers: Network is unreachable
root@ubuntuvmdesktop:/home/ericu# ip rule add from 192.168.14.14 table vlan14
root@ubuntuvmdesktop:/home/ericu# ip route show table vlan14
192.168.14.0/24 dev eth0.14  scope link  src 192.168.14.14 

Dies die VM mit IP Nachdem ich kann die Maschine erreicht mit 192.168.14.14und192.168.12.172

[ericu@squid3 ~]$ nc -v 192.168.12.172 22
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.12.172:22.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
^C
[ericu@squid3 ~]$ nc -v 192.168.14.14 22
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.14.14:22.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
^C
[ericu@squid3 ~]$ 

Dies ist also mindestens eine Möglichkeit, das Problem zu beheben. Allerdings verstehe ich nicht wirklich, was es tut. Ich verstehe, dass ich dem Computer eine separate Routing-Tabelle namens "vlan14" hinzugefügt habe. Ich vermute mal, dass durch die Verwendung von ip rule addirgendwie der Verkehr 192.168.14.14in die eigene Routing-Tabelle geleitet wird. Isoliert dies das Routing für die beiden Subnetze in ihre eigene Routing-Tabelle? Alle Routenänderungen, die ich mit vorgenommen ip routehabe, bleiben jedoch nach einem Neustart nicht erhalten. Es scheint, als müsste ich /etc/network/interfacesirgendwie aktualisieren, um anzuzeigen, dass Routen in diese alternative Routing-Tabelle aufgenommen werden sollen.

Kann mir bitte jemand erklären, wie die separate Routingtabelle funktioniert? Könnte jemand erklären, wie ich meine Konfiguration ändere, damit die mit dem ipBefehl vorgenommenen Änderungen auch nach einem Neustart bestehen bleiben?

Das gesamte Linux-Routing erfolgt über Routing-Tabellen.

Eine Standardinstallation ohne Änderungen enthält eine "Haupttabelle", eine "Standardtabelle" und eine "lokale" Tabelle. Die "Haupt" -Tabelle wird angezeigt, wenn Sie ip route showohne zusätzliche Optionen ausgeführt werden. Die "lokale" Tabelle ist für die Loopback-Adressen ( 127.0.0.0/8, ff00::/8). Die "Standard" -Tabelle wird als letzter Ausweg verwendet und ist normalerweise leer.

Sie können spezielle Routing-Anweisungen hinzufügen, die für Ziele gelten, die von einem ip ruleBefehl ausgewählt werden . Sie fügen Regeln mit einer Priorität hinzu, wobei die niedrigsten Nummern zuerst abgeglichen werden. Standardmäßig sind dies die Standardregeln:

$ ip rule show
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

Eine typische Verwendung für Regeln ist, wenn Sie ein Multi-Homed-System haben, dh ein System mit mehr als einer Verbindung zum Internet. In diesem Setup müssen Sie sicherstellen, dass Antwortpakete über dieselbe Schnittstelle (dh Internetverbindung) gesendet werden, über die das ursprüngliche Paket eingegangen ist. In der Regel bedeutet dies, dass Pakete mit einer bestimmten Quelladresse von der entsprechenden Schnittstelle gesendet werden:

# ip rule add from 1.2.3.4 pref 30000 lookup first
# ip rule add from 5.6.7.8 pref 30000 lookup second
# ip route add table first  default via 1.2.3.254 dev if1 src 1.2.3.4
# ip route add table second default via 5.6.7.254 dev if2 src 5.6.7.8

Fügen Sie nun eine Standardroute hinzu, die über die bevorzugte Verbindung verläuft (z. B. die schnellste oder billigste im Volumen):

# ip route add table default via 5.6.7.254 dev if2 src 5.6.7.8

Fügen Sie eine zweite Standardroute hinzu, wenn die bevorzugte Schnittstelle nicht funktioniert:

# ip route add table default via 1.2.3.254 dev if1 src 1.2.3.4

Sie müssen sicherstellen, dass die Standardroute beim erneuten Aufrufen der bevorzugten Schnittstelle wieder an erster Stelle in der Tabelle steht. Im Allgemeinen füge ich diese Route hinzu, lösche die andere und füge sie erneut an. Es gibt wahrscheinlich einen besseren Weg ...

Sie können verschiedene Selektoren verwenden ip rule add, z. B. um es von einer Firewall-Markierung abhängig zu machen, die auf dem Paket von gesetzt wurde iptables. Verwenden Sie ip rule add helpfür das, was Sie dort setzen können; dies gilt für alle im allgemeinen ipBefehl (zB ip help, ip route help).

Das Linux Advanced Routing Guide beschreibt alles zu diesem Thema.

Damit Ihre manuelle Routenkonfiguration nach einem Neustart usw. angewendet wird, fügen Sie sie den /etc/network/interfacesSchnittstellendefinitionen post-uphinzu. Diese werden nach dem Aufrufen der Schnittstelle ausgeführt. man interfacesbeschreibt alle möglichen Dinge, die Sie in die interfacesDatei einfügen können.