Warum vpnc nach 24 Minuten die Verbindung verliert und was man ändern sollte

Ihr Tunnel stirbt in einem wiederholbaren Intervall, und das ist ein Timer, der sich selbst meldet, kein schlechtes Kabel. Vierundzwanzig Minuten sind 1440 Sekunden, jener runde Wert, den ein Profil oder eine Richtlinie am Head-End trägt. Dieselbe Konfiguration scheitert dann jedes Mal am selben Konzentrator, während jedes andere Netz funktioniert, und kein Leitungstest ändert das.

Drei Bedingungen entscheiden, welcher Timer Ihrer ist: ob der Client eine untätige Sitzung aufgibt, ob der Rekey-Austausch abgelehnt wird und ob ein übersetzendes Gateway die Kapselung umgeschrieben hat.

Welcher Timer besitzt den Abbruch

Messen Sie das Intervall über mindestens drei Wiederverbindungen, bevor Sie eine Einstellung anfassen. Eine Streuung von Sekunden deutet auf Leitungsverlust oder WLAN-Roaming hin; ein Wert, der jedes Mal innerhalb weniger Sekunden an derselben Marke landet, deutet auf einen Richtlinienwert hin. Die Sitzungslänge verrät auch, wer sie beendet hat, denn ein Timeout auf Clientseite und ein Löschen auf Serverseite hinterlassen unterschiedliche letzte Zeilen in der Debug-Ausgabe. Drei Wiederverbindungen zeigen zudem, ob das Intervall überhaupt driftet, was eine einzelne Messung nicht zeigen kann.

Notieren Sie die Zahl neben dem Head-End, mit dem Sie gesprochen haben. Sobald das Intervall stabil ist, bleibt die Wahl zwischen drei Ursachen, und genau eine geänderte Einstellung pro Wiederverbindung hält sie unterscheidbar.

Fall eins: Der Client gibt eine untätige Sitzung auf

vpnc führt seine eigene Dead-Peer-Prüfung aus, und diese Prüfung kann eine Sitzung töten, die der Konzentrator noch für lebendig hält, besonders wenn ein übersetzendes Gateway dazwischen sitzt. Das clientseitige Mittel in der Dokumentation besteht darin, den Timer lokal abzuschalten und das Head-End entscheiden zu lassen, wann ein Peer weg ist. Beide Zeilen unten gehören in das vpnc-Profil oder auf die Kommandozeile, und beide sind unabhängig von den Verschlüsselungseinstellungen.

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

Das Abschalten von Client-DPD entfernt einen Fehlalarm und entfernt zugleich Ihre einzige lokale Erkennung, also wenden Sie es allein an und beobachten Sie, ob sich das Intervall überhaupt ändert.

Fall zwei: Der Rekey wird abgelehnt

Überlebt das Intervall die DPD-Änderung, wird der Rekey der Phase 1 zum Kandidaten. Ältere vpnc-Builds gingen mit dem Rekey weniger sorgfältig um als aktuelle, und die Diffie-Hellman-Gruppe ist die übliche Meinungsverschiedenheit. Eine Gruppe zu erzwingen, die das Head-End ohnehin akzeptiert, kostet eine Zeile und eine Wiederverbindung, was es zu einem billigen Experiment statt zu einer Richtlinienänderung macht.

IKE DH Group dh5

Gültige Gruppennamen sind dh1, dh2 und dh5. Eine Gruppe, die der Konzentrator ablehnt, erzeugt einen sofortigen Fehlschlag, und auch das ist Information: Sie erfahren, dass das Head-End wählerisch ist und die ursprüngliche Gruppe wahrscheinlich richtig war.

Fall drei: Übersetzung schreibt die Kapselung um

Hinter einem übersetzenden Gateway sind Ciscos UDP-Kapselung und der standardbasierte Modus nicht austauschbar. Die falsche Wahl erzeugt häufig einen Tunnel, der sich aufbaut, Verkehr durchlässt und dann unter Last ausläuft, was wie ein Bandbreitenproblem aussieht und keines ist. Ändern Sie nur den Modus, verbinden Sie dann neu und messen Sie den Abbruch erneut. Probieren Sie den anderen Modus erst, nachdem die ersten beiden Fälle ausgeschlossen sind.

Frontends stiften hier eigene Verwirrung. NetworkManager bietet keinen vpnc-Verbindungstyp an, bis das Plugin-Paket installiert ist, und ein fehlendes Plugin erscheint als ausgegrauter Hinzufügen-Knopf statt als Fehler. Das KDE-Frontend hält dieselben Werte in einem eigenen Profil, prüfen Sie also, ob der Daemon liest, was Sie bearbeitet haben.

Ein Profil, das von der Kommandozeile aus gut verbindet, vom Desktop aus aber nicht, ist ein Frontend-Problem, kein Timer-Problem.

Prüfen Sie den Austausch, der scheitert, vor der dritten Änderung

Starten Sie den Client mit Debug-Ausgabe und lesen Sie den letzten Austausch vor dem Abbruch. Ein Löschen der Phase 1 unmittelbar vor der Trennung bedeutet, dass der Client neu verschlüsselt hat und abgelehnt wurde. Ein Löschen der Phase 2 an derselben Stelle bedeutet, dass der Tunnel von der anderen Seite abgebaut wurde und Ihre Client-Einstellungen nicht die Ursache sind.

vpnc --debug 3 office

Prüfen Sie außerdem auf einen zweiten Netzwerk-Daemon, wenn der Tunnel überlebt, aber der Verkehr stoppt. Zwei Manager, die die Routing-Tabelle schreiben, erzeugen vom Desktop aus dasselbe Symptom und ein völlig anderes Log.