Welcher NAT-Hop die inaktive VPN-Zuordnung verwirft und wie man das erkennt
Ein inaktiver VPN-Fluss kann an jedem zustandsbehafteten Hop sterben. Wiederholen Sie einen Test, vergleichen Sie, was jede Grenze sah, und melden Sie das eingegrenzte Ergebnis statt eines geratenen Schuldigen.
Nach einer Ruhephase verbindet sich der Tunnel neu, kein Protokoll nennt einen Schuldigen, und der naheliegende Schritt ist, das Gerät mit der beeindruckendsten Timeout-Dokumentation zu wählen. Das ist eine Vermutung im Gewand einer Diagnose. Zustand kann eine Weile in einem Heimrouter, in einem Übersetzer des Anbieters und an einer Cloud-Kante überleben, und jede dieser Stellen kann einen Fluss verwerfen, der still wird. Stattdessen können Sie den Pfad abbilden, markieren, welche Geräte Sie tatsächlich beobachten können, und einen Ruhetest ausführen, den Sie wiederholen können.
Ein wiederholbarer Test verwandelt eine Anekdote in eine Messung. Alles Folgende setzt einen Client, einen Server und ein Protokoll voraus und setzt voraus, dass Sie zwei Variablen nicht gleichzeitig ändern. Der Punkt ist, das nächste Vorkommen billiger zu machen als dieses.
Führen Sie jedes Mal denselben Ruhetest aus
Notieren Sie, wann der Fluss zuletzt in Ordnung war, wie lange er danach untätig blieb und ob ein frisches Paket ihn zurückbrachte. Diese drei Tatsachen sind die Messung; ohne sie haben Sie eine Geschichte über einen Laptop, der ausgefallen ist. Verwenden Sie bei jeder Wiederholung denselben Client, denselben Server und dasselbe Protokoll und notieren Sie den Moment, in dem das erste Paket nach der Stille gesendet wurde.
Vergleichen Sie dann, was jede Grenze, die Ihnen gehört, tatsächlich gesehen hat. Die Unterscheidung, die die Untersuchung entscheidet, ist, ob der Server nach der Pause gar nichts gesehen hat oder die Anfrage gesehen und in einen Pfad geantwortet hat, der die Antworten nicht mehr trug.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Pfade vergleichen, ohne fünf Dinge zu ändern
Ein zweites freigegebenes Zugangsnetz ist ein legitimer Vergleich, weil die NAT-Kette anders ist. Es unterscheidet sich auch in Anbieter, Funkbedingungen und möglicherweise Adressfamilie, sodass das Ergebnis eine Grenze und keine Zuschreibung ist. Halten Sie die Einschränkungen zusammen mit dem Ergebnis fest, statt sie beim Berichten stillschweigend wegzulassen. Schreiben Sie den Pfad gleich mit auf: Gerät, Rolle und ob sich sein Zustand überhaupt lesen lässt.
Was ein Vergleich von Pfaden Ihnen kauft, ist eine eingegrenzte Frage: Der Fluss überlebt auf dem einen und stirbt auf dem anderen nach ähnlicher Stille, also liegt die Variable irgendwo in den Teilen, die sich unterscheiden. Das ist ein echtes Ergebnis, auch wenn kein Gerät benannt wird, und es sagt dem nächsten Ingenieur, wo er einen Nachmittag verbringen sollte und wo nicht.
Lokalen Zustand sollte man lesen, bevor man über Anbieter spekuliert. Auf einem Linux-Gateway listet conntrack -L die verfolgten Flüsse mit ihrer Restlebensdauer auf, was eine Vermutung über einen Timer in eine Zahl verwandelt, die Sie ablaufen sehen können. Lesen Sie ihn vor und nach der Ruhephase, nicht nur danach.
Was ein Keepalive hält und was nicht
Ein unterstütztes Keepalive hält eine Zuordnung offen, und eine offene Zuordnung beweist nichts über den Dienst dahinter. Der Tunnel kann zugeordnet bleiben, während die Anwendung, die er trägt, aufgehört hat zu antworten, und aus Sicht einer Statusleuchte sehen diese beiden Situationen gleich aus. Behandeln Sie ein Keepalive als Versicherung gegen inaktives Verfallen, nicht als Gesundheitsprüfung.
Setzen Sie das Intervall am kürzesten tatsächlich gemessenen Timeout aus, nicht an einer aus einem Forum kopierten Zahl. Ein Keepalive, das unter jedem denkbaren Timer eingestellt ist, ist Verkehr, den niemand brauchte, und es entfernt auch das Symptom, das Ihnen gesagt hätte, welche Grenze zuerst abläuft. Wählen Sie das Intervall aus der gemessenen Zahl und lassen Sie alles andere in Ruhe.
Eine Änderung, dann erneut messen
Widerstehen Sie dem Drang, während eines Live-Tests jeden Timeout zu erhöhen und jedes Gateway zu leeren. Das löscht die Beweise, für die Sie gekommen sind, und unterbricht Flüsse anderer Leute, was ein schlechter Tausch für eine ungeprüfte Hypothese ist. Ändern Sie eine unterstützte Einstellung auf einem Gerät und wiederholen Sie dann die Ruhephase und die Wiederherstellung der Anwendung.
Notieren Sie, welche Grenzbeobachtung sich verschoben hat, und notieren Sie es auch, wenn sich nichts verbessert hat. Eine Einstellung, die nichts repariert hat, ist Information, und es ist billiger, das einmal zu bemerken, als es über den ganzen Bestand zu rollen.
Einen Befund schreiben, den Sie verteidigen können
Wenn ein vorgelagerter Übersetzer nicht eingesehen werden kann, sagen Sie nur, was die Beweise stützen: Der Austausch stirbt irgendwo auf diesem Stück des Pfads nach so viel Stille, und der verantwortliche Hop bleibt unbenannt. Eine eingegrenzte Aussage übersteht die Prüfung und zeigt der nächsten Person das richtige Segment. Einen verborgenen Router als Ursache zu nennen, leistet keines von beidem. Geben Sie den eingegrenzten Befund an denjenigen, dem das nicht beobachtbare Segment gehört, mit dem Intervall daran.
RFC 4787 beschreibt, warum UDP-Zuordnungs-Timer von einem Endpunkt aus schwer abzuleiten sind, und genau diese Schwierigkeit macht den eingegrenzten Befund zum ehrlichen. Timer sind real, und die Unsicherheit um sie herum ebenso.