Warum route-nopull allein den Dateiserver unerreichbar lässt
Gepushte Routen zu ignorieren ist nur die halbe Split-Tunnel-Lösung. Legen Sie den Routenbesitzer fest, tragen Sie das Büro-Präfix von Hand ein und testen Sie drei Abläufe, bevor Sie es als gelöst bezeichnen.
Der Dateiserver öffnet sich einwandfrei, und der Videoanruf im nächsten Fenster beginnt zu stocken. Nichts ist langsam, und keine MTU ist falsch: Ihr Client hat die Routenliste übernommen, die der Server ihm gegeben hat, also verlässt jetzt jedes Paket die Büro-Firewall. Die Lösung ist kein weiteres Tuning-Flag, sondern eine Entscheidung darüber, wem die Routentabelle des Clients gehört. Diese Entscheidung gehört an eine Stelle, und die Fehlermuster unten sagen Ihnen, welche Stelle Sie tatsächlich gewählt haben.
Entscheiden Sie, wem die Routentabelle gehört
Drei Besitzer sind möglich. Der Server kann Routen und ein Standard-Gateway pushen; dann installiert der Client, was ihm gesagt wird, und wird zu einem vollständigen Tunnel. Das Client-Profil kann die Eigentümerschaft übernehmen, indem es Pushes verwirft und eigene Routenzeilen mitbringt. Ein Desktop-Verbindungsmanager kann die Entscheidung ebenfalls besitzen, über seine eigenen Routen- und Standardrouten-Eigenschaften.
Jede Wahl scheitert anders, weshalb sich ein Blick in die Tabelle lohnt, bevor Sie ein Profil bearbeiten. Die Zeile, die zu Ihrem Symptom passt, ist der Besitzer, den Sie tatsächlich haben.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Wählen Sie einen und schreiben Sie ihn auf. Zwei zu mischen hinterlässt einen Host, dessen Standardpfad seiner eigenen Dokumentation widerspricht, und der nächste Ingenieur kann nicht erkennen, welche Ebene gewonnen hat. Löschen Sie den Verlierer ausdrücklich.
route-nopull filtert Pushes, es fügt keine Routen hinzu
route-nopull gehört ins Client-Profil, und seine Reihenfolge in dieser Datei ist unerheblich, weil es nur Werte verwirft, die vom Server kommen. Es verwirft gepushte Routen, einschließlich einer gepushten Standardroute, während der Tunnel weiterhin normal hochkommt.
Die Folge, die viele übersehen, ist, dass gepushte DHCP-Optionen mit verschwinden. Auch die vom Server gesendeten DNS-Einstellungen werden verworfen, sodass interne Namen nicht mehr aufgelöst werden, obwohl der Tunnel gesund ist und der Server über die Adresse erreichbar bleibt.
Das hinterlässt einen Tunnel ohne Pfad zum Büro-Präfix, es sei denn, Sie fügen selbst einen hinzu: route-nopull gefolgt von route 10.30.0.0 255.255.0.0 im selben Profil. Diese Zeile trägt eine Adresse und eine Maske; sie benennt keinen nächsten Hop.
Eine alternative Form hängt ein Gateway-Token an, route 10.30.0.0 255.255.0.0 vpn_gateway, das den Eintrag namentlich auf den Tunnel zeigt. Importprogramme unterscheiden sich darin, ob sie diese Variante übersetzen; prüfen Sie also die gespeicherte Verbindung, wenn der Eintrag in der Kernel-Tabelle fehlt.
Prüfen Sie mit Routenabfragen, nicht mit einem Ping
Ein Ping sagt Ihnen, dass etwas geantwortet hat. Eine Routenabfrage sagt Ihnen, welche Schnittstelle der Kernel wählen würde, und das ist die Frage, die Sie tatsächlich gestellt haben. Vier kurze Befehle trennen eine fehlende Route von einer Route, die auf das falsche Gerät zeigt.
Lesen Sie mit ip route show dev tun0, was der Tunnel installiert hat. Gar keine Ausgabe bedeutet null Routen, was kein funktionierender Split Tunnel ist, und das ist das übliche Ergebnis, wenn der Filter ohne die ausdrückliche Zeile hinzugefügt wird.
Prüfen Sie dann eine Büroadresse mit ip route get 10.30.5.7 und eine gewöhnliche Internetadresse mit ip route get 1.1.1.1. Die zweite sollte die physische Schnittstelle nennen; nennt sie den Tunnel, wurde der Push überhaupt nicht gefiltert.
Lesen Sie schließlich ip rule, denn eine Regel, die ein früherer Versuch hinterlassen hat, kann die gerade korrigierte Tabelle überstimmen. Ein korrektes Profil mit einer veralteten Regel darüber sieht genauso aus wie ein kaputtes Profil. Löschen Sie die Regel, die Sie zuletzt hinzugefügt haben, bevor Sie eine weitere hinzufügen.
Überlappende Subnetze sehen wie ein kaputter Tunnel aus
Zwei private Bereiche können aus Sicht des Clients identisch sein, und genau dort wird einem Split Tunnel etwas angelastet, das er nicht verursacht hat. Wenn das Büro dasselbe Präfix verteilt, das Ihr Heimrouter verwendet, deckt die Tunnelroute den Router ab, und das Heimnetz scheint zu verschwinden.
Vergleichen Sie die Adresse Ihrer eigenen Schnittstelle mit der Route, die das Profil installiert, und nutzen Sie eine einfache Adressliste, bevor Sie etwas ändern. Die Überlappung ist real, und keine Profiloption löst sie. Was Sie beheben können, ist die Benennung, damit die nächste Person zwei Bereiche statt einem sieht.
Die ehrlichen Korrekturen sind, eine Seite neu zu nummerieren oder Adressen im Büro zu übersetzen. Eine einzelne Host-Route am Router festzunageln funktioniert, bis sich die Routeradresse ändert, und dann wird daraus ein zweites Rätsel über dem ersten.
Lassen Sie die Entscheidung eine Wiederverbindung überleben
Von Hand getippte Einträge überleben keine Wiederverbindung, und ein Verbindungsmanager baut die Tabelle bei jedem Start des Profils neu auf. Legen Sie die Entscheidung dort ab, wo die Verbindung entsteht, sei es das Profil oder die gespeicherten Einstellungen des Managers. Starten Sie die Verbindung dann einmal absichtlich neu, statt das Verhalten während eines Anrufs zu entdecken. Ein Profil, das nur bis zur nächsten Wiederverbindung funktioniert, ist nicht fertig.
Testen Sie drei Wege gleichzeitig: einen Büro-Host über die wörtliche Adresse, denselben Host über den Namen und eine gewöhnliche öffentliche Website. Der mittlere hängt von dem Namensdienst ab, den Sie eingerichtet haben, nachdem Sie die gepushten DNS-Optionen verworfen haben, und er ist derjenige, der still scheitert.