VPN verbunden, aber ein Dienst scheitert: die Stufe isolieren

Ein abgeschlossener Handshake sagt nichts über den Namen, die Route, die Paketgröße oder den Listener. Gehen Sie vier Stufen durch und lassen Sie den ersten Fehler den Defekt benennen.

„Verbunden“ ist die am wenigsten aussagekräftige Angabe in einem VPN-Ticket. Sie hält fest, dass zwei Peers einen Handshake abgeschlossen haben, und nichts über den abgefragten Namen, die Schnittstelle, über die das Paket ging, seine Größe oder ob die Gegenseite es annahm. Deshalb kann ein Dienst scheitern, während jede andere Anwendung auf demselben Laptop funktioniert. Gehen Sie die Stufen der Reihe nach durch, und die erste, die scheitert, benennt den Defekt.

Beginnen Sie mit dem Namen, nicht mit dem Tunnel

Lösen Sie auf, bevor Sie routen, denn eine schlechte Antwort macht jeden späteren Test sinnlos. Fragen Sie den Namen beim System-Resolver ab und vergleichen Sie diese Antwort mit der Adresse, die die Anwendung tatsächlich verwendet hat. Ein privater Name, der als öffentliche Adresse zurückkommt, bedeutet, dass die Abfrage an einen Resolver ging, der sie nichts angeht. Ein Name, der sich nicht auflösen lässt, ist dieselbe Kategorie, nur lauter.

resolvectl query host.internal
getent hosts host.internal

Browser mit eigener Einstellung für sicheres DNS scheitern hier, während der Rest des Systems funktioniert. Deshalb gehört eine reine Browser-Beschwerde zuerst in diese Stufe, bevor jemand eine Route anfasst. Vergleichen Sie beide Befehle statt nur einen, denn getent folgt dem NSS-Pfad und die Resolver-Abfrage nicht.

Fragen Sie den Kernel, welchen Pfad er gewählt hat

Die Routing-Tabelle ist eine Präferenzreihenfolge, und der Pfad, den der Kernel wählt, ist nicht immer der im Diagramm. Fragen Sie ihn direkt nach dem betreffenden Ziel. Die Antwort nennt die Schnittstelle, den nächsten Hop und die Quelladresse, die verwendet wird. Ein Paket kann durch den Tunnel mit einer Quelladresse verlassen, die die Gegenseite ablehnt, und ein spezifischerer Eintrag in der physischen Tabelle kann es stattdessen über die Wi-Fi-Schnittstelle senden.

ip route get 10.20.30.40
ip -brief address show

Lesen Sie die Felder dev, via und src in dieser Reihenfolge, denn jedes schließt einen anderen Verdacht aus. Diese Stufe verantwortet auch den Zustand, den der Client installiert hat, denn Firewall-Regeln und Routen können nach einem abnormalen Beenden bestehen bleiben. Deshalb sind „kein Internet ohne den Tunnel“ und „kein Internet, solange der Client nicht läuft“ eine Fehlerfamilie und nicht zwei.

Prüfen Sie die Paketgröße

Eine kleine Antwort, die zurückkommt, während eine große Übertragung stockt, deutet zuerst auf die Pfad-MTU hin. Eine einzelne Probe mit gesetztem do-not-fragment-Bit, aus dem Tunnel gesendet, trennt diese Stufe von den übrigen. Erhöhen Sie die Nutzlast, bis die Probe scheitert, und Sie haben die Zahl, auf die es ankommt.

ping -M do -s 1400 10.20.30.40

Kleine Proben gelingen, während eine Verzeichnisauflistung oder ein Upload hängt — das ist die Signatur dieser Stufe. Die Beschwerde klingt nach Zugangsdaten oder einer Firewall-Regel, und sie ist keins von beidem.

Die Zahl ist eine Eigenschaft des Pfades, nicht des Clients, daher kann ein Wert, der an einem Büroanschluss funktioniert, an einer Mobilfunkverbindung scheitern. Bewahren Sie den Probe-Befehl beim Ticket auf, denn die nächste Person braucht dieselbe Messung. Wenn eine kleinere Nutzlast durchkommt, ist die Lösung ein Clamp oder eine niedrigere Tunnel-MTU, nicht eine neue Chiffre.

Testen Sie die Gegenseite

Testen Sie das Ziel über seine Adresse und sehen Sie dann nach, was dort lauscht. Eine abgelehnte Verbindung und eine Verbindung, die nie antwortet, sind verschiedene Befunde. Die erste sagt, dass etwas läuft und diesen Port nicht bedient, die zweite, dass gar nichts zurückkam. Keines von beiden ist standardmäßig ein Client-Problem.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nichts, was durch einen Tunnel erreichbar ist, kann ein Dienst sein, der nur auf 127.0.0.1 lauscht, denn der Listener sieht das Paket nie. Wenn die Firewall des fernen Hosts das Büro-Subnetz zulässt und den Tunnel-Pool ablehnt, sieht das Ergebnis wie ein Client-Fehler aus und ist keiner. Remote Desktop oder Dateifreigabe, die brechen, während Web-Traffic überlebt, landet normalerweise hier, wie der Nutzer es auch formuliert.

Ordnen Sie die Beschwerde einer Stufe zu

Die meisten Meldungen fallen in eine von fünf Formen, und jede Form nennt eine Stufe. Eine Website, die nur durch den Tunnel funktioniert, ist eine Namensantwort oder eine an die Quelladresse gebundene Richtlinie. Updates, die ohne den Tunnel scheitern, während Surfen funktioniert, sind ein Namens- oder Routenproblem für diesen Client.

Dass alles stoppt, wenn ein Anbieter-Client startet, ist installierter Zustand, also eine Route- und Firewall-Frage. Ein Dienst unerreichbar, während der Rest in Ordnung ist, ist die Gegenseite. Übertragungen, die nach wenigen Sekunden stocken, sind die Paketgröße. Gleichen Sie die Form ab, bevor Sie Befehle ausführen, denn sie entscheidet, welche Belege zuerst gesammelt werden.

Notieren Sie die Stufe, die den ersten Fehler erzeugt hat, zusammen mit der Befehlsausgabe. Ein Ticket, das sagt, die Quelladresse sei falsch gewesen, mit angehängter Routenzeile, ist es wert, bearbeitet zu werden, während eines, das das VPN als kaputt meldet, es nicht ist.

Ähnliche Artikel