VirtualBox-VPN-Labor: Gateway-VM gegenüber Host-Only-Netzwerk

Sie müssen entscheiden, wie viel Maschinerie Ihr VPN-Labor verdient. Eine geroutete Gateway-VM zwischen zwei VirtualBox-Segmenten bildet die Adressübersetzung, den Rückweg und die Firewall-Position nach, hinter der ein echter Client sitzt. Ein einzelnes Host-Only-Segment gibt Ihnen eine kontrollierte Tür und sonst nichts. Die Gateway-Variante kostet drei Gäste und eine Routingtabelle, die Sie pflegen; die Host-Only-Variante kostet einen Gast und eine Richtlinie. Drei Fragen trennen sie, und die dritte entscheidet, ob Ihr Test überhaupt bestehen kann.

Beantworten Sie drei Fragen, bevor Sie irgendetwas klonen

Beginnen Sie damit, was der VPN-Server beobachten muss. Wenn der Server eine Quelladresse sehen muss, die nicht die des Testgasts ist, muss etwas zwischen beiden übersetzen, und dieses Etwas muss ein Router sein, den Sie kontrollieren. Host-Only-Netzwerke geben dem Host einen Adapter im Segment des Gasts, keinen Übersetzer. Wenn der Gast dann etwas außerhalb erreichen muss, hängen Sie einen NAT-Adapter an, und VirtualBox' eigene NAT-Engine schreibt die Quelle um, ohne Sie zu fragen.

Fragen Sie als Nächstes, ob der Gast irgendetwas außer durch den Tunnel erreichen darf. Diese Antwort wählt intern oder Host-Only, und es ist die Frage, die die meisten Laborbeschreibungen auslassen. Fragen Sie schließlich, was passieren muss, wenn der Tunnel abbricht, denn das entscheidet über Richtlinie statt Topologie, und ein Labor, das nur den glücklichen Pfad beweist, hat fast nichts getestet.

Verdrahten Sie die drei Rollen mit internen Netzwerken

Verwenden Sie drei Gäste und zwei benannte Segmente, wobei das Gateway die einzige Maschine ist, die in beiden einen Adapter hat:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Für ein internes Netzwerk gibt es keinen separaten Erstellungsschritt. Die Zeichenfolge in --intnet1 ist das Segment: Zwei Maschinen teilen es nur, wenn der Name exakt übereinstimmt, und nichts auf dem Host ist damit verbunden. Diese letzte Eigenschaft ist der Grund, warum das Labor sauber wiederholbar ist, da die Routen des Hosts, sein eigener VPN-Client und seine Firewall die Gäste nicht versehentlich erreichen können. Ein internes Segment hat außerdem keinen DHCP-Server, solange Sie keinen hinzufügen, also sind statische Adressen der kürzeste Weg.

Geben Sie dem Client nur seine WAN-Adresse, mit einem Standardgateway, das auf die WAN-Adresse des Gateways zeigt. Der Server erhält eine LAN-Adresse und verwendet die LAN-Adresse des Gateways als Standardgateway. Ein Gast, der zwei Adressen in einem Segment hält oder eine verirrte Route zum anderen Segment hat, hat einen Pfad um den Router herum, und die Tests unten werden Sie belügen.

Ich halte eine Textdatei neben den VM-Namen mit den vier Adressen und den zwei Segmentnamen und füge sie in jede Shell ein. Wochen später, wenn eine Profiländerung etwas kaputt macht, ist diese Datei der Unterschied zwischen dem Debuggen des Profils und dem Debuggen meines eigenen Gedächtnisses.

Wählen Sie intern oder Host-Only für das Segment, das nicht lecken darf

Der Host-Only-Modus erstellt einen virtuellen Adapter auf dem Host selbst, normalerweise vboxnet0, und gibt dem Host eine Adresse im Segment des Gasts. Das ist bequem für die Verwaltung und fatal für einen Isolationstest, weil der Host den Gast nun direkt erreichen kann und jeder Dienst auf der Hostseite zu einem möglichen Pfad wird. Der interne Modus hat überhaupt keinen Host-Adapter. Die beiden Modi lassen sich im Netzwerkeinstellungsfenster leicht verwechseln, prüfen Sie also den dokumentierten Unterschied statt das Etikett (siehe die Seite Netzwerkdetails von VirtualBox).

Für einen Gast, der den Tunnel nutzen muss, ist intern die sicherere Voreinstellung, mit dem Gateway als einzigem Ausgang. Wenn Sie Host-Only behalten, behandeln Sie den Host-Adapter als Verwaltungspfad und sagen Sie es laut: Der Host darf den Gast erreichen, und der Gast darf den Host nicht als Ausgang nutzen können.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Die Isolation, die Sie beweisen können, ist die Isolation, die Sie konfiguriert haben. Ein Gast mit einem internen Adapter, einer Standardroute am Gateway und ohne NAT-Adapter hat keinen Pfad, der das Gateway umgeht. Ein Gast mit einem Host-Only-Adapter und einem NAT-Adapter hat zwei Pfade, und nur einer davon ist der, den Sie testen wollten.

Routen und übersetzen Sie am Gateway, und lassen Sie es dann geschlossen fehlschlagen

VirtualBox leitet nicht zwischen Segmenten weiter; das tut der Gast. Mit der VPN-Server-VM hinter dem Gateway aktivieren Sie die Weiterleitung und übersetzen den Verkehr des Clients, während er zum Server hinausgeht:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Mit dieser Regel sieht der Server die LAN-Adresse des Gateways statt der des Clients, und genau so sieht ein echter Client hinter einem Anbieter-NAT für ein Head-End aus. Speichern Sie den sysctl-Wert in /etc/sysctl.d/ und die Regel in dem Firewall-Dienst, den die Distribution verwendet, sonst bringt ein Neustart das Labor still in einen gerouteten, aber unübersetzten Zustand zurück.

Weiterleitung ist keine Autorisierung. Unter der standardmäßigen FORWARD-Richtlinie mit dem Wert ACCEPT verlässt ein Gast, dessen Standardroute auf das Gateway zeigt, das Netzwerk über die Schnittstelle, die die Routingtabelle auswählt, mit oder ohne Tunnel. Wenn das Gateway auch einen NAT-Adapter für Paketinstallationen hat, ist dieser Adapter in dem Moment ein funktionierender unverschlüsselter Ausgang, in dem der Tunnel abbricht, und Ihr Nur-VPN-Test war nie ein Nur-VPN-Test.

Wenn der Server stattdessen entfernt ist und das Gateway den Tunnel selbst beendet, zeigt dieselbe Entscheidung auf die Tunnelschnittstelle, nicht auf die NIC, die das Internet erreicht:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Halten Sie den eigenen äußeren Transport des Tunnels und eine Out-of-Band-Verwaltungsroute getrennt vom weitergeleiteten Verkehr. Wenn der einzige Weg, das Gateway zu reparieren, durch den Tunnel führt, den Sie debuggen, wird das Labor zu einer Aussperrungsübung. Eine serielle Konsole, ein Host-Only-Verwaltungsadapter oder ein Snapshot eines bekannten guten Zustands sind billiger als die manuelle Wiederherstellung eines kaputten Routers.

Prüfen Sie den Pfad vom Gast aus, nicht vom Host

Arbeiten Sie sich nach außen. Bestätigen Sie, dass der Client die WAN-Adresse des Gateways erreicht, dann den Server durch das Gateway, dann dass eine Verbindung zum VPN-Port hinausgeht und zurückkommt. Eine Aufzeichnung an beiden Gateway-Schnittstellen zeigt, ob die Antwort ankommt und auf dem Rückweg verworfen wird, was eine Aufzeichnung nur am Client nicht unterscheiden kann:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Beweisen Sie dann den Ausgang. Fragen Sie vom Gast aus einen Adressreflexionsdienst, welche Quelle er sieht, und vergleichen Sie das mit der eigenen Ausgangsadresse des Gateways; wenn die Antwort mit der Adresse des Hosts übereinstimmt, existiert ein Pfad um den Tunnel herum. Prüfen Sie, welchen Resolver der Gast tatsächlich verwendet, und prüfen Sie IPv6 separat, denn ein Segment, in dem IPv6 aktiviert ist, während der Tunnel nur IPv4 trägt, leckt konstruktionsbedingt und nicht versehentlich.

Brechen Sie es zum Schluss absichtlich. Stoppen Sie den Tunnel oder blockieren Sie seinen äußeren Port, und öffnen Sie eine neue Verbindung vom Gast. Sie muss fehlschlagen, und der Grund muss einer sein, den Sie benennen können: keine Route, eine Ablehnungsregel oder ein toter Resolver. Starten Sie den Tunnel neu und bestätigen Sie, dass sich der Gast erholt, ohne das Netzwerk neu aufzubauen. Wenn ein Mesh-VPN wie Hamachi oder ZeroTier das Labor teilt, denken Sie daran, dass ein gebrückter Adapter dem Adapternamen folgt, nicht dem Mesh, also muss die Brücke neu ausgerichtet werden, nachdem der Client seinen eigenen virtuellen Adapter installiert hat.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Den Tunnel eines Gasts mit dem Host zu teilen spiegelt das Problem. Die Standardroute des Hosts auf den Gast zu richten funktioniert, und ein Proxy im Gast ebenso; NAT durch den Host trägt den Tunnel des Gasts nicht für Verkehr, den der Host erzeugt hat. Speichern Sie die Segmentnamen und die Firewall-Regeln an einem Ort, machen Sie einen Snapshot des funktionierenden Zustands und notieren Sie die Quelladresse, die der Server beobachtet hat. Die nächste Profiländerung kostet dann einen Skriptlauf statt eines neu aufgebauten Labors.