UDP-VPN bleibt im Leerlauf stehen: Die Firewall hat deinen Flow vergessen

Das VPN verbindet, funktioniert eine Weile und leitet dann keinen Verkehr mehr durch, während der Client noch eine Sitzung anzeigt. Ein Neuverbinden behebt es, was es wie einen Client-Fehler aussehen lässt. Meist ist es eine Firewall oder ein NAT-Gerät, das eine inaktive UDP-Zuordnung verworfen hat und nicht weiß, dass der Tunnel noch existiert.

Das Symptom ist konsistent genug, um es zu diagnostizieren: Es tritt nach Inaktivität auf, nicht unter Last.

Wie ein Leerlauf-Stillstand aussieht

Miss ihn, statt ihn zu beschreiben. Notiere, wie lange der Tunnel still liegt, bevor der Verkehr stoppt, ob ein neues ausgehendes Paket ihn wiederbelebt und ob die Client-Schnittstelle noch ihre Adresse hält. Wenn eine frische Anfrage vom Client funktioniert, eine Antwort auf einen bestehenden Flow aber nicht, ist die Zuordnung der Verdächtige. Wenn nichts funktioniert, bis du neu verbindest, ist auch der Sitzungszustand des Clients weg.

Beides hängt mit Inaktivität zusammen, und beide brauchen unterschiedliche Korrekturen.

Schreib die Zeiten auf, bevor du etwas änderst. Ein Bericht, dass es nach etwa zehn Leerlaufminuten stoppt, ist prüfbar, ein Bericht, dass es zufällig abreißt, nicht. Dieser Unterschied entscheidet, ob du einem Timer oder einer Routing-Änderung nachjagst.

Finde das Gerät, das vergessen hat

Mehrere Geräte können Zustand für denselben Flow halten: der lokale Router, ein vorgelagerter Übersetzer, eine Cloud-Grenze und die Host-Firewall. Jedes hat seinen eigenen Timer, und der kürzeste gewinnt. Ein Ausfall von fünf Minuten bedeutet meist, dass ein Gerät deutlich unter den anderen konfiguriert ist.

Nimm nicht an, dass ein dokumentierter Standardwert der Timeout auf deinem Pfad ist. Er ist der Standardwert eines Geräts.

• Heimrouter: oft Minuten, gelegentlich viel weniger.
• Cloud-NAT oder Load Balancer: Schlag den dokumentierten Leerlauf-Timeout speziell für UDP nach.
• Host-Firewall: netfilter-Tracking-Timer gelten pro Flow.

Prüfe die Timer auf dem tatsächlichen Pfad

Unter Linux sind die netfilter-Tracking-Timer sichtbar und einstellbar: sysctl net.netfilter.nf_conntrack_udp_timeout und net.netfilter.nf_conntrack_udp_timeout_stream. Der zweite gilt, sobald Verkehr in beide Richtungen gesehen wurde, weshalb ein etablierter Tunnel eine bloße Probe überleben kann.

RFC 4787 beschreibt das UDP-NAT-Verhalten und empfohlene Mindestwerte. Das ist die Referenz, die du zitierst, wenn ein Hersteller-Standard ungewöhnlich kurz aussieht.

Keepalive und Neuverbinden sind verschiedene Werkzeuge

Ein Keepalive hält eine Zuordnung am Leben; ein Neuverbinden baut eine tote Sitzung neu auf. Sie lösen unterschiedliche Fehler und sind keine austauschbaren Geschwindigkeitseinstellungen. WireGuards PersistentKeepalive sendet ein Paket in festem Intervall, um die NAT-Bindung offen zu halten. OpenVPNs keepalive Option erledigt dieselbe Aufgabe auf ihre eigene Weise. Keines hilft, wenn das Gerät in der Mitte den Flow bereits vergessen hat und beide Richtungen verwirft.

Sehr häufige Proben erzeugen Arbeit, ohne die falsche Grenze zu reparieren.

Prüfe mit einer neuen Anfrage, nicht mit einem Seitenneuladen

Wiederhole nach einer Timer-Änderung oder einem hinzugefügten Keepalive das Leerlaufszenario genau wie zuvor. Stelle dann eine wirklich neue Anfrage aus der abgedeckten Anwendung. Ein Browser-Tab, der schon geladen war, kann aus dem Cache rendern und sagt dir nichts.

Bleibt der Stillstand, geh einen Hop nach außen und prüfe die Zustandstabelle dieses Geräts.