Host-only-VM-Verkehr über einen TUN-OpenVPN-Server routen

Host-only-Adapter schaffen ein lokales virtuelles Netz, und geroutete TUN-Tunnel tragen IP-Pakete zwischen Adressen. Keines von beiden ist eine Brücke zum anderen, deshalb muss eine funktionierende Konfiguration sagen, wer weiterleitet und wem die Rückroute gehört. Werden diese beiden Zuweisungen vertauscht, antwortet der Gast dem Tunnel mit einer Quelle, nach der der Tunnel-Client nie gefragt hat. Das folgende Design hält beide Präfixe getrennt und macht den Rückweg explizit.

Zwei Netze, zwei Präfixe

Geben Sie dem Tunnel-Pool und dem Host-only-Netz unterschiedliche Präfixe und verwenden Sie niemals eines für das andere. In diesem Beispiel ist der VPN-Pool 10.44.0.0/24 und das Host-only-Netz 192.168.99.0/24, mit dem Host auf 192.168.99.1 und einem Gast auf 192.168.99.20. Dasselbe Präfix sowohl einem TUN-Gerät als auch dem Host-only-Adapter zuzuweisen, verbindet sie nicht. Es erzeugt zwei Ansprüche auf einen Adressbereich, und die Routing-Tabelle antwortet dann für den Anspruch, den sie zufällig behalten hat.

Der Host-only-Adapter existiert auf dem Host und im Gast, und er hat aus eigener Kraft keinen Weg von der Maschine weg. Bridged- und NAT-Anbindungen haben eine andere Exposition, und der Wechsel in den Bridged-Modus ist keine Voraussetzung, um einen einzelnen Gast-Dienst zu erreichen.

Der Host hält den Weg bereits

Schauen Sie sich an, was existiert, bevor Sie etwas hinzufügen. Der Host hat eine Schnittstelle im Host-only-Netz und eine Route für dieses Präfix, beide entstanden beim Hochfahren des Adapters.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Die dritte Zeile ist der Mechanismus, der den Host zu einem Hop macht. Ohne sie ist ein Paket, das aus dem Tunnel kommt, an ein Netz adressiert, das der Host erreichen kann, aber nicht weiterleiten wird. Weiterleitung ist notwendig und nicht ausreichend. Die Filter-Policy entscheidet weiterhin, ob ein bestimmter Fluss zwischen der Tunnel-Schnittstelle und der Host-only-Schnittstelle erlaubt ist, und diese Entscheidung gehört schriftlich festgehalten statt in eine Standard-Policy, die niemand gelesen hat.

Route pushen, dann filtern, was sie erreicht

Der Server kann das Host-only-Präfix an Clients liefern, die gepushte Routen akzeptieren; das ist derselbe Mechanismus wie für jedes andere Subnetz hinter dem Tunnel.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Diese beiden Regeln erlauben einen Dienst in einer Richtung und seine Antworten. Eine Route, die das ganze Präfix erreicht, und ein Filter, der einen Port erlaubt, sind eine bewusste Kombination; eine Route plus ein unbedingtes Accept ist der Weg, auf dem aus einem Lab-Dienst ein exponierter Dienst wird. Eine gepushte Route ist außerdem keine Autorisierung. Der Client akzeptiert sie, der Host leitet sie weiter, und die Gast-Firewall und der Dienst selbst haben weiterhin ein Mitspracherecht.

Der Gast braucht einen Rückweg

Ein Gast, der von 10.44.0.x erreicht wird, muss seine Antworten an die Host-only-Adresse des Hosts senden, oder der Host muss die Quelle übersetzen. Eine Adresse von VirtualBox-DHCP zu beziehen, sagt über keine der beiden Anordnungen etwas aus.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Diese Route im Gast hinzuzufügen, erhält die ursprüngliche Quelle, was Policy und Logs pro Client aussagekräftig hält. Gezielte Quellübersetzung auf dem Host ist die Alternative, und sie funktioniert, um den Preis zu verbergen, welcher Client verbunden war. Überlappung ist der andere Fehlermodus. Ein entfernter Client, dessen Heim-LAN bereits 192.168.99.0/24 verwendet, liest die gepushte Route als sein eigenes Netz, und keine Änderung auf der Serverseite behebt diese Mehrdeutigkeit. Nummerieren Sie eine Seite neu oder wählen Sie ein Präfix, das wahrscheinlich nicht kollidiert.

Ein TUN-Gerät trägt IP-Pakete, also macht das Hinzufügen eines Standard-Gateways im Gast den Tunnel nicht zu einem Ethernet-Segment mit dem Host-only-Adapter. TAP-Bridging ist ein anderes Design mit eigener Client-Unterstützung und eigener Adressverwaltung, und das Vermischen der beiden Beschreibungen führt zu Konfigurationen, die nie konvergieren.

Prüfen, dann einen Neustart überstehen

Testen Sie einen harmlosen Dienst von einem gewöhnlichen entfernten Client, prüfen Sie die Rückroute des Gasts und bestätigen Sie, dass ein Dienst, den Sie nicht erlaubt haben, abgelehnt statt langsam ist.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Starten Sie dann den VPN-Dienst und das Netzwerk der virtuellen Maschine neu und wiederholen Sie dieselben drei Prüfungen. Eine von Hand hinzugefügte Route überlebt bis zum nächsten Neustart, und eine Konfiguration, die nur in einer warmen Sitzung funktioniert, ist kein Design. Halten Sie die beiden Präfixe, die Weiterleitungs-Policy und die Gast-Route zusammen fest. Wer die nächste virtuelle Maschine hinzufügt, wird alle drei brauchen und sie sonst eine fehlgeschlagene Verbindung nach der anderen neu entdecken.