Ich richte einen KVM-Virtualisierungshost mit richtlinienbasiertem Routing ein (192.168.1.0/24-Verwaltungsnetzwerk für Host-bezogenen Datenverkehr wie Updates, SSH usw., 192.168.2.0/24-DMZ-Netzwerk, das an VMs weitergeleitet wird).
Das Setup sieht so aus (mit ^^^ meine ichwie obenzur Darstellung der Baumstruktur)
#external connectivity
eth0 -> vlan110 -> brhost (192.168.1.9)
^^^ -> vlan120 -> brguest (192.168.2.4)
#internal connectivity
brguestA (10.0.1.1) -> tapA0
^^^ -> tapA1
^^^ -> tapA2
brguestB (10.0.2.1) -> tapB0
^^^ -> tapB1
# ... and so on for each VM group subnet
Maschinen An sind in einem „Switch“, Bn im zweiten usw. Der Host verhält sich wie ein Router und hat iptables installiert. Die Quell-IP wird pro Bridge auf iptables-Ebene validiert.
Im Allgemeinen funktioniert alles „Normale“, aber wenn ich einige Grenzfalloperationen durchführe, verhält es sich immer noch so, wie es sollte, aber die Protokolle deuten darauf hin, dass es eher Zufall ist als dass es tatsächlich richtig funktioniert. Zum Beispiel:
Verbindung zu 192.168.1.3 von VM (anderer Host im Verwaltungsnetzwerk), die blockiert ist Operation auf iptables Ebene (TCP-Reset) gibt
(iptables reject log) IN=brguestA OUT=brguest SRC=10.0.1.2 DST=192.168.1.3 ... IPv4: martian source 10.0.1.2 from 192.168.1.3 on dev brhost
Beachten Sie, dass OUTdie Schnittstelle tatsächlich korrekt ist, was sie tun soll, wenn man die Logik der Trennung von Host- und Gastnetzwerken berücksichtigt, und selbst wenn solche Pakete vom Host weitergeleitet würden, würden sie trotzdem von der Firewall gelöscht. Trotzdem können Host-IPTables sie nicht richtig mit TCP-Reset ablehnen, sodass solche Verbindungen einfach auf der VM hängen bleiben und keinen Reset erhalten.
Verbindung zu 192.168.1.9 von VM gibt
IPv4: martian source 192.168.1.9 from 10.0.1.2 on dev brguestA
und sonst nichts. Das Vertauschen von 10.0.1.x und 192.168.1.x in diesen Protokollen verwirrt mich wirklich und ich verstehe nicht wirklich, was diese bedeuten (welche die Quell-IP und welche die Ziel-IP ist). Ich weiß nicht wirklich, was der Host versucht und warum es fehlschlägt. Hier ist die Ausgabe von mir ip ruleund ip route:
ip rule
0: from all lookup local
32763: from 10.0.0.0/16 lookup guest
32764: from 192.168.2.0/24 lookup guest
32765: from all iif lo lookup host
32766: from all lookup main
32767: from all lookup default
ip route show table host
default via 192.168.1.1 dev brhost proto static
192.168.1.0/24 dev brhost proto static
ip route show table guest
default via 192.168.2.1 dev brguest proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ... so on for other networks
ip route show table main
192.168.1.0/24 dev brhost proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ...
Ich verwende systemd-networkdfür die Netzwerkverwaltung. IchGedankeDies geschieht, weil der Host immer versucht, mit brhostdem Gerät als OUTPUTPakettyp zu antworten iif, auf den er eingestellt ist, losodass es von der Regel erfasst wird from iif lookup host. Dies scheint jedoch nicht der Fall zu sein, da die Verbindung 192.168.2.4ordnungsgemäß abgelehnt wird, sodass es nicht immer brhostals Ausgabequelle ausgewählt wird.