Kein Internet über eine Windows-VPN? Der Adresspool ist verdächtig

Windows zeigt den Tunnel als verbunden an und kennzeichnet ihn mit Kein Internetzugriff, was viele für eine Windows-Eigenheit halten. Es ist eine Aussage darüber, was der Client erhalten hat: kein nutzbares Standard-Gateway, kein funktionierender Resolver und kein Rückweg für die Adressen im Tunnel. Wenn der Server eine Windows-Incoming Connection ist, erklärt eine einzige Einstellung die meisten solcher Meldungen. Die Kennzeichnung ist keine Diagnose, aber sie verengt die Suche auf drei Stellen.

Lesen Sie das Lease, bevor Sie es ändern

Führen Sie ipconfig /all auf dem Client aus und suchen Sie den VPN-Adapter unter den Einträgen. Die Adresse, das Standard-Gateway und der DNS-Server, die er auflistet, sind die Fakten, die Sie brauchen, und sie weichen häufig von dem ab, was der Administrator als ausgegeben annimmt.

Drei Muster entsprechen drei Fehlern. Eine Adresse in 169.254.0.0/16 bedeutet, dass der Client gar nichts erhalten und sich selbst eine Link-Local-Adresse zugewiesen hat. Eine plausible Adresse ohne Gateway bedeutet, dass der Pool ohne die Option ausgeliefert wurde, die dem Client eine Standardroute gibt. Ein vollständiges Lease, das trotzdem nichts erreicht, deutet auf Weiterleitung oder Übersetzung auf der Serverseite hin.

Schreiben Sie die Werte auf, bevor Sie den Server anfassen. Der nächste Schritt vergleicht sie mit dem Bereich, den der Server auszugeben glaubt, und das Gedächtnis ist ein schlechter Ersatz für ein Lease.

Warum die automatische Zuweisung ohne Gateway enden kann

Der Eintrag Incoming Connections hat eigene IPv4-Eigenschaften, getrennt vom physischen Adapter. Die Voreinstellung dort bietet an, Adressen automatisch zuzuweisen, was auf den eingebauten Zuteiler der Verbindung angewiesen ist, um Adresse, Maske, Gateway und DNS zu liefern.

Auf einer eigenständigen Arbeitsstation hat dieser Zuteiler keinen Bereich, aus dem er schöpfen könnte, sofern nicht etwas anderes auf dem Rechner einen bereitstellt, sodass der Client mit einer Link-Local-Adresse oder mit einer Adresse, aber ohne Gateway enden kann. Die Verbindung wirkt hergestellt, weil die Strecke zustande kam, während die Konfiguration dahinter unvollständig ist.

Deshalb behebt der Wechsel zu einem festgelegten Bereich so viele dieser Meldungen. Sie hören auf, einen Dienst, der möglicherweise nicht läuft, um ein erfundenes Lease zu bitten, und geben das Lease selbst an.

Dieselbe Verwirrung entsteht, wenn jemand erwartet, dass der DHCP-Server des LAN-Routers Tunnelclients bedient. Broadcast-Erkennung überquert keinen gerouteten Tunnel, daher sieht dieser Server die Anfrage nie. Das Gegenteil anzunehmen ist der häufigste Grund, einen Pool für einen Client verantwortlich zu machen, der ihn nie etwas gefragt hat.

Legen Sie einen expliziten Bereich fest, den der Server routen kann

Wählen Sie einen kleinen Block innerhalb eines Subnetzes, das der Server erreicht, außerhalb des Bereichs, den der LAN-Router ausgibt, und außerhalb jedes anderen Pools im Netzwerk. Steht der Server auf 172.20.10.0/24 und hält der Router 172.20.10.1, hält ein kurzer Block nahe dem oberen Ende dieses Subnetzes, etwa 172.20.10.201 bis 172.20.10.209, Tunnel-Leases von der Ausgabe fern, die der Router bereits verwaltet.

Tragen Sie ihn in den IPv4-Eigenschaften der Incoming Connection ein, verbinden Sie den Client erneut und lesen Sie den Adapter noch einmal, bevor Sie etwas anderes ändern. Der zweite Blick sagt Ihnen, ob der Pool die Ursache war oder nur einer von mehreren Fehlern.

Diese Befehle geben die resultierende Konfiguration und die Routen aus, die der Client jetzt hat:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Das Gateway im Lease sollte eine Adresse sein, die der Server hält, und die Standardroute des Clients sollte darauf zeigen. Ist das Lease vollständig, aber es existiert keine Route, hat der Server zugewiesen, ohne ein Gateway mitzugeben, und die Pooleinstellungen sind weiterhin die Stelle zum Nachsehen.

Eine Adresse ist kein Internetweg

Ein Lease zu empfangen bewegt nur Pakete vom Client zum Server. Für den Internetzugang muss der Server diese Pakete weiterleiten und zu seinem eigenen Uplink hin übersetzen, und das ist eine separate Konfiguration mit eigenen Fehlerarten.

Internet Connection Sharing ist die Abkürzung. Es macht den internetzugewandten Adapter zu einem gemeinsam genutzten Gateway und betreibt seine eigene Adressierung, die die Adresse dieses Adapters umschreiben und eine bestehende NAT-Regel auf einen Wert zeigen lassen kann, der nicht mehr existiert. Notieren Sie die ursprünglichen Einstellungen, bevor Sie es aktivieren.

Die geroutete Alternative hält die Adressierung stabil und verlangt, dass Sie Weiterleitung und Übersetzung ausdrücklich konfigurieren. Keiner der Ansätze ist falsch; sie auf halbem Weg zu mischen erzeugt einen Tunnel mit Lease und ohne Ausgang, was genau das Symptom ist, mit dem Sie begonnen haben. Wählen Sie ein Modell und bringen Sie es zu Ende, bevor Sie das andere hinzufügen.

Schließen Sie zuerst den äußeren Weg aus

Kein Pool kann helfen, wenn der Tunnel nie entsteht. Das Protokoll entscheidet, was der Weg tragen muss: PPTP will TCP 1723 und GRE, was IP-Protokoll 47 und kein Port ist; L2TP/IPsec will UDP 1701 plus 500 und 4500; SSTP will TCP 443.

Ein Router, der den Port, aber nicht das Protokoll weiterleitet, erzeugt einen Verbindungsversuch, der nie authentifiziert wird. Das ist ein anderer Fehler als ein Tunnel, der entsteht und dann nichts erreicht, und beide sollten nicht zusammen debuggt werden.

Testen Sie aus demselben LAN und aus dem entfernten Netzwerk. Wenn der LAN-Versuch funktioniert und der entfernte nie zur Authentifizierung gelangt, ist der äußere Weg das Problem. Wenn sich beide authentifizieren und nur der entfernte Client kein Internet hat, kehren Sie zu Pool und Ausgang zurück.