Warum scheitert Ihr Gast-VPN hinter VirtualBox-NAT?

Ein Browser in der virtuellen Maschine funktioniert, und der VPN-Client auf demselben Gast kann keine Daten übertragen. Der Gast hat offensichtlich Konnektivität, also liegt der Fehler darin, was das äußere Protokoll des VPN benötigt und was das virtuelle NAT durchlässt. Drei Bedingungen entscheiden das Ergebnis: welcher Prozess das VPN besitzt, wie der äußere Austausch auf der Leitung aussieht und ob der Adaptermodus der ist, den Sie meinen. Die Bedingung zu benennen, die Sie ändern können, ist die ganze Entscheidung.

Lokalisieren Sie den VPN-Prozess, bevor Sie das Netzwerk beschuldigen

Entscheiden Sie zuerst, ob das VPN im Gast oder auf dem Host läuft, denn die beiden Anordnungen scheitern unterschiedlich. Ein Client im Gast baut seine eigene äußere Verbindung über den Gastadapter und die dahinterliegende Übersetzung auf. Ein Host-VPN erfasst den Verkehr des Gasts nach Host- und Hypervisor-Richtlinie, was ein getrennter Erfassungspunkt mit eigenen Regeln ist. Beide können gleichzeitig laufen und die Beweise verwirren, daher identifizieren Sie diejenige, die diesen Verkehr tragen soll, bevor Sie eine von beiden anfassen.

Notieren Sie jetzt den Adaptermodus des Gasts, bevor Sie irgendetwas ändern. Dieser eine Wert erklärt das meiste des Folgenden, und er ist das Erste, wonach Sie später jeder fragen wird.

Der äußere Austausch entscheidet über die Kompatibilität

Die VirtualBox-Netzwerkdokumentation nennt NAT-Einschränkungen, die hier zählen: Sie lässt keine anderen Protokolle als TCP und UDP durch, GRE wird als nicht unterstützt genannt, und PPTP wird als betroffenes Beispiel angeführt. PPTP nutzt einen TCP-Kontrollaustausch und GRE für die Daten, sodass die Kontrollverbindung gelingen kann, während der Datenpfad dieselbe Grenze nicht überqueren kann. Das sind zwei verschiedene Beweise, und nur einer davon betrifft die Übertragung von Verkehr. TCP-Port 47 in einer Firewall-Regel zu erlauben ist nicht dasselbe wie IP-Protokoll 47 zu erlauben, und beides wird ständig verwechselt.

Halten Sie die Einschränkung an dieser NAT-Anordnung fest und nicht an jedem Gerät, das das Wort NAT verwendet. Ein physischer Router kann GRE anstandslos durchlassen, während das virtuelle NAT es verwirft, und ein anderer Hypervisor trifft seine eigene Wahl darüber, was er weiterleitet. Wo die Organisation einen freigegebenen Transport innerhalb von TCP oder UDP anbietet, verwenden Sie deren unterstützten Client und das Profil für diesen Pfad. Kompatibilität ist eine Anforderung unter mehreren, und sie begründet weder Serververtrauen noch Kontoberechtigung noch funktionierende private Routen.

Was Bridging tatsächlich ändert

Eine Bridge übergibt die MAC-Adresse des Gasts an das physische Segment, statt sie hinter Übersetzung zu verbergen. Der Gast bezieht dann eine Adresse von dem DHCP-Server, der dieses Segment bedient, antwortet mit ARP für diese Adresse und erscheint dem Upstream-Switch als ein weiterer Port. Das entfernt den virtuellen Übersetzungspfad, weshalb ein altes Rezept ihn empfiehlt, und es ändert gleichzeitig drei andere Dinge. Die Adressierung kommt nun vom lokalen Segment statt vom Hypervisor, Freigabe bedeutet, dass der Gast für dieses Segment sichtbar ist, und Zulassung hängt vom Switch-Port und dessen Richtlinie ab. Jedes davon kann ein Grund sein, die Änderung abzulehnen, und keines davon betrifft das VPN-Protokoll.

Bridging installiert kein fehlendes Plugin, liefert keinen nicht verfügbaren geheimen Agenten und repariert keine Authentifizierungsablehnung. Es macht auch kein veraltetes Protokoll zu einer guten Wahl, und wo der Betreiber einen gepflegten Ersatz hat, ist dieser die Entscheidung und nicht die Änderung des Hypervisors. Portweiterleitung ist eine ganz dritte Rolle: Sie veröffentlicht einen eingehenden Dienst und tut nichts für das äußere Protokoll eines ausgehenden Clients.

Zwei Tunnel, zwei Beweisspuren

Ein Gast-VPN braucht einen nutzbaren Pfad von der Gastschnittstelle zu seinem Peer, bevor eine innere Adresse oder private Route zählt. Wo ein Host-VPN vorhanden ist, kann es diesen äußeren Austausch nach seiner eigenen Richtlinie weiterleiten oder blockieren, und der innere Tunnel des Gasts beginnt erst, nachdem der äußere gelingt. Die Abdeckung keiner Schicht lässt sich an einem einzelnen verbundenen Symbol oder an der öffentlichen Adresse des Host-Browsers ablesen.

Behalten Sie die erste Fehlermeldung statt der letzten, denn der früheste Fehler benennt die Schicht. Ändern Sie jeweils eine unterstützte Netzwerkanordnung, mit demselben Gastprofil und denselben Anmeldedaten, damit der Vergleich etwas bedeutet. Entscheiden Sie anhand des Fehlers, welche Stufe brach: lokale Integration, Transport, Authentifizierung oder Ressourcenzugriff nach dem Hochfahren des Tunnels. Jede davon hat einen anderen Verantwortlichen, und nur eine ist eine Hypervisor-Frage.

Welche Bedingung Sie tatsächlich blockiert

Inzwischen verengt sich die Entscheidung auf drei Fragen mit unterschiedlichen Antworten. Liegt das äußere Protokoll außerhalb von TCP und UDP, ist der NAT-Modus die Einschränkung, und Bridging oder ein freigegebener TCP/UDP-Transport ist der Weg nach vorn. Schließt der äußere Austausch ab und der Datenpfad nicht, ist die Einschränkung dieselbe wie beim zweiten Beweis. Kommt der Tunnel hoch und antworten Ressourcen nicht, hat das Problem den Hypervisor bereits hinter sich gelassen und liegt bei Routing oder Richtlinie.

Schreiben Sie die Antwort mit dem Adaptermodus daneben auf, sonst wiederholt die nächste Person denselben Nachmittag. Testen Sie nach jeder Korrektur die tatsächliche Anwendung und Namensauflösung im Gast, verbinden Sie sich dann neu und proben Sie die Fehlerrichtlinie. Eine funktionierende Webseite durch den Tunnel beweist nur, dass der Webpfad funktioniert, was eine kleinere Behauptung ist, als es sich im Moment anfühlt.