Warum ein VPN verbunden aussehen kann, während nichts funktioniert

Ihr Client meldet verbunden, während die Schnittstelle oben ist und der Browser in eine Zeitüberschreitung läuft, und keine dieser drei Aussagen ist falsch. Verbunden beschreibt eine Schicht, die nichts mit der Seite zu tun hat, die Sie angefordert haben. Zu entscheiden, welche Schicht berichtet, erfordert eine neue Anfrage und einen Blick auf den Zähler, der beweisen würde, dass Verkehr floss. Ein Neustart wirft diesen Beweis weg und baut die Bedingungen neu auf, die Sie beobachten wollten.

Drei verschiedene Dinge, die verbunden genannt werden

Ganz unten kann verbunden bedeuten, dass ein Clientprozess läuft und einen Socket zu einem Peer hält. Darüber kann es bedeuten, dass eine Schnittstelle mit einer Adresse existiert, die ein dauerhaftes Gerät oder eine Wiederherstellungsroutine ohne lebende Sitzung dahinter erzeugen kann. Auf der Steuerungsebene kann es bedeuten, dass eine Assoziation ausgehandelt wurde, was nichts darüber sagt, ob ein einzelnes Paket darunter hindurchgegangen ist. Jede davon übersteht Fehler, die die anderen nicht überstehen, und ein Client zeigt normalerweise die stärkste, die er beanspruchen kann.

Ein grünes Symbol und ein toter Tunnel sind daher vereinbar statt widersprüchlich; sie berichten über verschiedene Objekte. Das ist der ganze Grund, warum dieser Fehler immer wieder als Clientfehler fehldiagnostiziert wird.

Senden Sie eine harmlose Anfrage an ein Ziel, das Sie tatsächlich brauchen, bevor Sie den Daemon anfassen, und lassen Sie den erforderlichen Block für direkten Verkehr stehen, während Sie arbeiten. Ein Neustart löscht die Reihenfolge der Ereignisse und erzeugt sie dann nah genug neu, um die Ursache zu verbergen, weshalb dasselbe Ticket eine Woche später ohne etwas Neues zurückkommt. Eine Anfrage, eine Zählerablesung und der Auslöser, der den Fehler hervorrief, sind der Mindestbeweis.

Welcher Zähler beweist, dass die Pakete flossen

In IPsec sind die IKE-Assoziation und die CHILD-Assoziation getrennte Objekte, und nur das Child trägt die Zähler, die diese Frage beantworten. Listen Sie das Child auf, beobachten Sie, ob Pakete in beide Richtungen zunehmen, und vergleichen Sie das mit dem, was die Anwendung zu tun versucht. Eine installierte Assoziation bei null ist ein anderer Befund als eine steigende, während die Anwendung weiter scheitert; das erste bedeutet, dass Verkehr nicht ausgewählt wird, das zweite, dass er fließt und der Fehler weiter hinten liegt. Lesen Sie die Zähler zweimal, einige Sekunden auseinander, weil eine Probe keinen Trend zeigen kann.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Nullzähler deuten auf die Auswahl: Routing, Policy, einen Namensraum, aus dem das Paket kam, oder eine Schnittstelle, an die der Client nie gebunden hat. Steigende Zähler deuten vom Tunnel weg, also fahren Sie mit Weiterleitung am fernen Ende, Namensauflösung, dem Rückweg und dem Zieldienst fort, in dieser Reihenfolge. Ein Protokoll ohne separates Child-Objekt legt denselben Beweis in seinen eigenen Begriffen offen, also nutzen Sie, was es über Peer-Zustand und Paketzahlen berichtet, statt das IPsec-Vokabular zu entlehnen. Die Form der Ablesung zählt mehr als das Werkzeug, das sie erzeugte.

Wo der Fehler sitzt, nachdem die Zähler sich bewegen

Ein Gateway, das auf seiner eigenen Verwaltungsadresse antwortet, beweist, dass das Gateway läuft, nicht dass etwas dahinter Ihre Anfrage bedient, also testen Sie die ferne Seite statt der Box in der Mitte. Namensauflösung verbirgt Fehler am besten, weil ein Resolver, der durch den Tunnel nicht erreichbar ist, genauso in eine Zeitüberschreitung läuft wie eine tote Verbindung. Zwei Abfragen trennen diese Fälle, und beide sind billig. Fragen Sie zuerst den Resolver, den der Tunnel durchsetzt, und dann einen öffentlichen Resolver nach demselben Namen.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Ein Name, der über den öffentlichen Resolver aufgelöst wird, aber nicht über den Tunnel-Resolver, bedeutet, dass der DNS-Pfad gebrochen ist, während ein Name, der über beide aufgelöst wird und im Browser trotzdem in eine Zeitüberschreitung läuft, auf den Rückweg oder auf den Dienst zeigt. Wenn der Ping auf die Adresse gelingt und die Anwendung trotzdem ablehnt, hat das Netzwerk die Anfrage zugestellt und der Dienst sie abgelehnt, was eine ganz spätere Stufe ist.

Notieren Sie den Auslöser, dann ändern Sie eine Sache

Notieren Sie, was dem Fehler vorausging: eine Phase der Untätigkeit, eine Netzwerkänderung, eine Schlüsselerneuerung, ein fortgesetztes Notebook oder ein wiederhergestelltes System. Diese erzeugen unterschiedliche Mechanismen, und nur das wiederhergestellte System repariert sich normalerweise selbst, was genau der Fall ist, der Ihnen nichts beibringt. Ein Neustart entfernt die Reihenfolge der Ereignisse und erzeugt dann Bedingungen nah genug, um die Ursache zu verbergen. Schreiben Sie den Auslöser auf, solange er noch reproduzierbar ist.

Nehmen Sie dann eine belegte Korrektur vor und wiederholen Sie die ursprüngliche Anfrage zusammen mit dem Auslöser, der den Fehler hervorrief. Untätigkeit ist der am leichtesten zu reproduzierende Auslöser, also ist sie die schnellste Bestätigung, dass die Korrektur den Mechanismus statt das Symptom adressiert hat.

Was Sie melden wollen, ist der Beweis, dass der Verkehr, den Sie senden wollten, den Dienst erreicht hat, den Sie erreichen wollten. Ein Symbol, das grün wird, eine zwischengespeicherte Seite, die lädt, und ein Zähler, der sich bewegt, beweisen alle weniger als eine abgeschlossene Anfrage gegen das beabsichtigte Ziel. Halten Sie Anfrage, Zählerablesung und Auslöser zusammen, damit die nächste Person eine Korrektur von einem Zufall unterscheiden kann.