Container-HTTPS hängt im Firmen-VPN? Das DTLS-Bein testen

In einem Container hinter einem Firmen-VPN löst DNS auf, die Login-Seite lädt, ein Health-Endpunkt antwortet, und dann hängt eine HTTPS-Anfrage, bis sie in den Timeout läuft. Image neu bauen und Proxy-Variablen ändern bringt nichts, denn der fehlerhafte Teil steckt nicht im Image. Der Client authentifiziert sich über einen Transport und bewegt Massendaten über einen anderen, und nur der zweite ist kaputt.

Zwei Transporte, ein verwirrendes Symptom

Ein TLS-basierter Firmenclient authentifiziert sich normalerweise über eine gewöhnliche TLS-Verbindung und handelt danach einen zweiten, UDP-basierten Datenkanal für die Sitzung aus. Funktioniert dieses zweite Bein, verbessern sich Durchsatz und Latenz. Wird es gefiltert oder passt nicht durch den Pfad, gelingt alles vor der Massenübertragung, und die Übertragung selbst bleibt stehen, also genau das Muster von oben.

Ein Container ändert diese Aushandlung nicht; er ändert den Pfad der äußeren Pakete. Der Host übersetzt den Container-Flow, sodass die UDP-Datagramme von einem anderen Quellport als dem lokalen Socket des Clients ausgehen und über einen Übersetzungseintrag zurückkommen, der viel kürzer abläuft als ein etablierter TCP-Flow. Funktioniert der Tunnel auf dem Host und scheitert im Container, vergleiche diese beiden Flüsse, bevor du die Anwendung beschuldigst. Dieser Vergleich klärt mehr als jeder Image-Neubau.

Entscheide durch Experiment, nicht durch Bauchgefühl

Das billigste Experiment deaktiviert den UDP-Datenkanal und wiederholt die Anfrage. Nutze den Kommandozeilenclient statt des Desktop-Wrappers, damit das Flag wirklich greift: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Kommt die zuvor hängende Anfrage nun durch, war das DTLS-Bein das Problem und der Rest Rauschen.

Bestätige das Ergebnis in beide Richtungen aus demselben Container: eine Massenanfrage mit Flag und eine ohne. Eine Verhaltensänderung, die dem Flag folgt, ist ein Beweis; eine Seite, die irgendwann lädt, nicht.

Wenn das Flag hilft, entscheide warum

Drei Bedingungen erzeugen dasselbe Symptom und verlangen unterschiedliche Reaktionen. Der Pfad kann UDP komplett filtern, was das Flag zur richtigen dauerhaften Antwort für dieses Netz macht. Der Pfad kann UDP erlauben, aber große Datagramme verwerfen, was auf MTU statt auf Filterung deutet. Oder der Pfad kann so verlustbehaftet sein, dass das UDP-Bein schlechter läuft als TCP, also eine Kapazitätsfrage, keine Erreichbarkeitsfrage.

Unterscheide sie, bevor du einen Workaround dokumentierst. Filterung überlebt jede Paketgröße, MTU-Probleme zeigen sich erst oberhalb einer Schwelle, und Verlust äußert sich als Neuübertragung und schwankende Verzögerung statt als sauberes Hängen. Jeder Test grenzt die Ursache ein, ohne die Client-Konfiguration zu ändern.

Paketgröße prüfen, bevor der Workaround bleibt

Ist die Größe die Ursache, nimmt die Tunnelschnittstelle Pakete an, die der Pfad nicht tragen kann, und das Problem kehrt auf jedem Transport zurück, sobald die Nutzlast wächst. Vergleiche die Schnittstellen: ip link show tun0 auf dem Host, dann docker network inspect bridge, um die in den Netzwerkoptionen hinterlegte MTU zu lesen. Eine Container-Bridge, die unter einem Tunnel, der weniger trägt, noch auf 1500 Byte steht, ist der übliche Befund.

Taste dich mit einem Do-not-fragment-Test im Tunnel von einer bekannt guten Größe nach oben, senke dann die MTU des Container-Netzes oder begrenze die TCP-MSS am Tunnel. Beide Korrekturen machen den UDP-Pfad oft wieder nutzbar und erübrigen das Flag, also das bessere Ergebnis, wenn Filterung nicht die Ursache ist.

Entscheide, was du zu tauschen bereit bist

Mit deaktiviertem Datenkanal trägt der Tunnel seine Nutzlast in einer TCP-Verbindung. Auf einem sauberen Pfad ist das nur langsamer; auf einem verlustbehafteten verzögert ein einzelnes verlorenes Segment alles dahinter, und die äußere Neuübertragung konkurriert mit der inneren. Dieser Tausch passt zu interaktiver Entwicklung und kleinen API-Aufrufen und schlecht zu Massenübertragungen oder langen Sitzungen über Mobilfunk.

Welche Option du auch wählst, halte fest, welchen Transport der Tunnel am Ende genutzt hat und warum. Ein Container, der stillschweigend von einem Flag abhängt, das jemand vor Monaten gesetzt hat, ist der nächste Ausfall, und wer ihn debuggt, weiß nicht, ob das Flag ein Workaround für Filterung oder ein Rest aus einem MTU-Experiment war.