Die Verbindung kommt zustande, und der Adapter zeigt eine Adresse aus dem Bürobereich, also liegt die natürliche Schlussfolgerung nahe, dass die VPN Ihnen eine LAN-Adresse gegeben und Sie damit ins LAN gesetzt hat. Keine der beiden Hälften stimmt ganz. L2TP trägt eine PPP-Sitzung, und PPP handelt die innere IPv4-Adresse mit IPCP aus. Diese Adresse ist ein zwischen zwei Peers vereinbarter Sitzungsparameter, kein vom DHCP-Server des Büros ausgegebenes Lease, und ihr Besitz macht Sie nicht zum Nachbarn am Bürokabel.

Zwei Adressen in einer Verbindung

In einer L2TP-Verbindung gibt es zwei unabhängige Aushandlungen. Die äußere baut einen geschützten Pfad zwischen Ihrem Gerät und dem VPN-Endpunkt über das Netz auf, das Sie ohnehin haben. Die innere ist die PPP-Sitzung, und dort werden Ihre Sitzungsadresse und die Adresse des Gegenübers vereinbart. Internetverkehr kann ganz unter einer dritten Adresse das Haus verlassen, der öffentlichen Adresse des Endpunkts, weshalb eine VPN-Prüfseite und die Adapteradresse selten übereinstimmen.

Diese drei Rollen getrennt zu halten beantwortet die meisten Fragen, die Leute an diese Schicht herantragen. Eine private Nummer auf der VPN-Schnittstelle ist normal und zu erwarten. Sie sagt nichts darüber aus, ob der Endpunkt Ihren öffentlichen Ausgang geändert hat, und entscheidet nicht für sich, welche Ziele Ihr Verkehr erreicht.

Was IPCP genau tut

IPCP ist das IPv4-Kontrollprotokoll für PPP. Jede Seite sendet Configure-Request-Nachrichten, die die gewünschten Optionen beschreiben, und die Adressoption ist eine davon. Ein Client ohne Adresse fragt üblicherweise mit 0.0.0.0, und der Server antwortet mit einem Configure-Nak, der die Adresse trägt, die der Client verwenden soll. Danach fordert der Client diese Adresse an, und die Sitzung kommt mit einer lokalen und einer entfernten Adresse zustande.

Dieser Austausch ist in den PPP- und IPCP-Spezifikationen dokumentiert und erklärt ein Detail, das wie ein Fehler aussieht: Die Adresse wählt der Server nach seiner eigenen Richtlinie, die ein Pool, eine Einstellung pro Benutzer oder eine an die authentifizierte Identität gebundene Adresse sein kann. Ist der Pool erschöpft oder widerspricht die Richtlinie der Anfrage, kann die Authentifizierung gelingen, während die Adressaushandlung scheitert, und der Client meldet eine Verbindung, die nie zur Ruhe kommt.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Eine pppd-Logzeile, die eine lokale und eine entfernte Adresse nennt, ist das erfolgreiche Ende dieser Aushandlung. Ihr Fehlen neben einer erfolgreichen Authentifizierung deutet auf die Adressstufe hin, nicht auf die Zugangsdaten.

Warum das LAN Ihnen nicht antworten kann

Eine Adresse aus dem Bereich der Gegenseite weckt die Erwartung, dass Hosts in diesem LAN Sie erreichen, und meist können sie es nicht, es sei denn, der Server leitet Ihre Sitzungsadresse zurück in den Tunnel. Im Pool zu sein ist eine Aussage über die Zuteilung, nicht über die Topologie. Der Dateiserver des Büros hat keine Route zu Ihrer Sitzungsadresse, es sei denn, der VPN-Server leitet sie weiter, und selbst dann ist es vielleicht nicht erlaubt.

Deshalb verursachen sich überlappende Bereiche Probleme, die außer Verhältnis zu ihrer scheinbaren Größe stehen. Überschneidet sich der Pool mit einem LAN, das der Client bereits nutzt, hat die Routing-Tabelle des Clients nun zwei Ansprüche auf dasselbe Präfix, und der falsche gewinnt oft aus Gründen, die nichts mit dem Tunnel zu tun haben.

Erst die Sitzung prüfen, dann die Route

Prüfen Sie zuerst die Schnittstelle, dann die Routen, dann ein Ziel, das zählt. Jeder Schritt hat seinen eigenen Fehlermodus, und alle drei gleichzeitig zu testen liefert eine Schlussfolgerung, die Sie später nicht verteidigen können.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Zeigt die öffentliche Prüfung die Adresse des Endpunkts, während ein privates Ziel in einen Timeout läuft, trägt der Tunnel Ihre Standardroute, und die Gegenseite antwortet für dieses Ziel nicht. Antwortet das private Ziel, ändert sich die öffentliche Prüfung aber nicht, nutzt das Profil Split-Tunneling, und nur ein Teil des Verkehrs verwendet die Sitzung.

Halten Sie die drei Stufen auseinander

Authentifizierung, Adressaushandlung und Weiterleitung scheitern unterschiedlich, und jede hat einen anderen Verantwortlichen. Zugangsdaten sind ein Identitätsproblem, IPCP-Erschöpfung ist ein Problem der Serverrichtlinie, und eine fehlende Rückroute ist ein Problem des Netzwerkdesigns. Alle drei als „die VPN ist kaputt“ zu melden garantiert eine langsame Behebung.

Notieren Sie die zugewiesene Adresse, den Pool, aus dem sie stammt, und ob das LAN sie erreichen soll. Diese eine Notiz verhindert, dass die nächste Person ein DHCP-Lease annimmt und nach einem Bereich sucht, der nie beteiligt war.

Ähnliche Artikel