HTTPS v kontejneru za firemní VPN zamrzá? Otestujte DTLS nohu

Uvnitř kontejneru za firemní VPN se DNS přeloží, přihlašovací stránka se načte, zdravotní endpoint odpoví a pak HTTPS požadavek zamrzne, dokud nevyprší časový limit. Přestavění image a změna proxy proměnných nic nezmění, protože vadná část není v image. Klient se autentizuje přes jeden transport a objemná data přenáší přes jiný, a rozbitý je jen ten druhý.

Dva transporty, jeden matoucí symptom

Firemní klient založený na TLS se obvykle autentizuje přes běžné TLS spojení a poté vyjedná pro relaci druhý datový kanál založený na UDP. Když tato druhá noha funguje, propustnost a latence se zlepší. Když je filtrovaná nebo se nevejde do cesty, vše před objemným přenosem uspěje a přenos samotný se zastaví, což je přesně vzorec výše.

Kontejner tuto negociaci nemění; mění cestu, kterou se vnější pakety vydávají. Host překládá tok kontejneru, takže UDP datagramy odcházejí z jiného zdrojového portu než lokální socket klienta a vracejí se přes překladovou položku, která vyprší na mnohem kratším časovači než zavedený TCP tok. Pokud tunel na hostu funguje a v kontejneru selhává, porovnejte tyto dva toky, než obviníte aplikaci. Takové srovnání rozhodne víc než jakákoli přestavba image.

Rozhodujte experimentem, ne intuicí

Nejlevnější experiment vypne UDP datový kanál a požadavek zopakuje. Použijte klienta z příkazové řádky místo desktopového obalu, aby se příznak skutečně uplatnil: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Pokud se požadavek, který zamrzal, nyní dokončí, problémem byla DTLS noha a zbytek byl šum.

Výsledek potvrďte v obou směrech ze stejného kontejneru: jeden objemný požadavek s příznakem a jeden bez. Změna chování, která sleduje příznak, je důkaz; stránka, která se nakonec načte, není.

Pokud to příznak spraví, rozhodněte proč

Tři podmínky dávají stejný symptom a vyžadují různé reakce. Cesta může UDP zcela filtrovat, což dělá z příznaku správnou trvalou odpověď pro tuto síť. Cesta může UDP povolit, ale zahazovat velké datagramy, což ukazuje na MTU, nikoli na filtrování. Nebo může být cesta natolik ztrátová, že UDP noha funguje hůř než TCP, což je rozhodnutí o kapacitě, ne o dosažitelnosti.

Rozlište je, než zdokumentujete obchvat. Filtrování přežije každou velikost paketu, problémy s MTU se objeví jen nad prahem a ztráty se projeví jako retransmise a proměnlivé zpoždění, ne jako čisté zamrznutí. Každý test zúží příčinu, aniž by měnil konfiguraci klienta.

Zkontrolujte velikost paketu, než obchvat ponecháte

Pokud je příčinou velikost, rozhraní tunelu přijímá pakety, které cesta neunese, a problém se vrátí na jakémkoli transportu, jakmile náklad vzroste. Porovnejte rozhraní: ip link show tun0 na hostu, poté docker network inspect bridge pro přečtení MTU zaznamenaného v možnostech sítě. Kontejnerový most stále na 1500 bytech pod tunelem, který unese méně, je obvyklý nález.

Sondovat nahoru od známé dobré velikosti testem bez fragmentace uvnitř tunelu, poté snižte MTU kontejnerové sítě nebo omezte TCP MSS na tunelu. Kterákoli oprava často vrátí UDP cestu do použitelného stavu a odstraní potřebu příznaku, což je lepší výsledek, když příčinou není filtrování.

Rozhodněte, co jste ochotni vyměnit

S vypnutým datovým kanálem nese tunel svůj náklad uvnitř TCP spojení. Na čisté cestě je to jen pomalejší; na ztrátové cestě jeden ztracený segment zdrží vše za sebou a vnější retransmise soutěží s vnitřní. Tato výměna se hodí pro interaktivní vývoj a malá volání API a špatně sedí objemným přenosům nebo dlouhým relacím přes mobilní spoje.

Ať vyberete kteroukoli možnost, zaznamenejte, který transport tunel nakonec použil a proč. Kontejner, který tiše závisí na příznaku, jejž někdo přidal před měsíci, je další výpadek a ten, kdo ho bude ladit, nebude vědět, zda příznak byl obchvatem pro filtrování, nebo zbytkem experimentu s MTU.