HTTPS v kontajneri za firemnou VPN zamŕza? Otestujte DTLS nohu

Vnútri kontajnera za firemnou VPN sa DNS preloží, prihlasovacia stránka sa načíta, zdravotný endpoint odpovie a potom HTTPS požiadavka zamrzne, kým nevyprší časový limit. Prestavenie image a zmena proxy premenných nič nezmenia, pretože chybná časť nie je v image. Klient sa autentizuje cez jeden transport a objemné dáta presúva cez iný, a pokazený je len ten druhý.

Dva transporty, jeden mätúci symptóm

Firemný klient založený na TLS sa zvyčajne autentizuje cez bežné TLS spojenie a potom pre reláciu vyjedná druhý dátový kanál založený na UDP. Keď táto druhá noha funguje, priepustnosť a latencia sa zlepšia. Keď je filtrovaná alebo sa nezmestí do cesty, všetko pred objemným prenosom uspeje a samotný prenos sa zastaví, čo je presne vzor vyššie.

Kontajner túto negociáciu nemení; mení cestu, ktorou idú vonkajšie pakety. Host prekladá tok kontajnera, takže UDP datagramy odchádzajú z iného zdrojového portu než lokálny socket klienta a vracajú sa cez prekladovú položku, ktorá vyprší na oveľa kratšom časovači než zavedený TCP tok. Ak tunel na hoste funguje a v kontajneri zlyháva, porovnajte tieto dva toky, kým obviníte aplikáciu. Také porovnanie rozhodne viac než akékoľvek prestavenie image.

Rozhodujte experimentom, nie intuíciou

Najlacnejší experiment vypne UDP dátový kanál a požiadavku zopakuje. Použite klienta z príkazového riadka namiesto desktopového obalu, aby sa príznak skutočne uplatnil: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Ak sa požiadavka, ktorá zamŕzala, teraz dokončí, problémom bola DTLS noha a zvyšok bol šum.

Výsledok potvrďte v oboch smeroch z toho istého kontajnera: jedna objemná požiadavka s príznakom a jedna bez. Zmena správania, ktorá sleduje príznak, je dôkaz; stránka, ktorá sa nakoniec načíta, nie je.

Ak to príznak spraví, rozhodnite prečo

Tri podmienky dávajú rovnaký symptóm a vyžadujú rôzne reakcie. Cesta môže UDP úplne filtrovať, čo robí z príznaku správnu trvalú odpoveď pre túto sieť. Cesta môže UDP povoľovať, ale zahadzovať veľké datagramy, čo ukazuje na MTU, nie na filtrovanie. Alebo môže byť cesta natoľko stratová, že UDP noha funguje horšie ako TCP, čo je rozhodnutie o kapacite, nie o dosiahnuteľnosti.

Rozlíšte ich, kým zdokumentujete obchádzku. Filtrovanie prežije každú veľkosť paketu, problémy s MTU sa objavia len nad prahom a strata sa prejaví ako retransmisia a premenlivé oneskorenie, nie ako čisté zamrznutie. Každý test zúži príčinu bez zmeny konfigurácie klienta.

Skontrolujte veľkosť paketu, kým obchádzku ponecháte

Ak je príčinou veľkosť, rozhranie tunela prijíma pakety, ktoré cesta neunesie, a problém sa vráti na akomkoľvek transporte, len čo náklad vzrastie. Porovnajte rozhrania: ip link show tun0 na hoste, potom docker network inspect bridge na prečítanie MTU zaznamenaného v možnostiach siete. Kontajnerový most stále na 1500 bajtoch pod tunelom, ktorý unesie menej, je obvyklý nález.

Sondovať nahor od známej dobrej veľkosti testom bez fragmentácie vnútri tunela, potom znížte MTU kontajnerovej siete alebo obmedzte TCP MSS na tuneli. Ktorákoľvek oprava často vráti UDP cestu do použiteľného stavu a odstráni potrebu príznaku, čo je lepší výsledok, keď príčinou nie je filtrovanie.

Rozhodnite, čo ste ochotní vymeniť

S vypnutým dátovým kanálom nesie tunel svoj náklad vnútri TCP spojenia. Na čistej ceste je to len pomalšie; na stratovej jeden stratený segment zdrží všetko za sebou a vonkajšia retransmisia súťaží s vnútornou. Táto výmena sa hodí pre interaktívny vývoj a malé volania API a zle sedí objemným prenosom alebo dlhým reláciám cez mobilné spoje.

Akúkoľvek možnosť vyberiete, zaznamenajte, ktorý transport tunel nakoniec použil a prečo. Kontajner, ktorý ticho závisí od príznaku, ktorý niekto pridal pred mesiacmi, je ďalší výpadok, a ten, kto ho bude ladiť, nebude vedieť, či príznak bol obchádzkou pre filtrovanie alebo zvyškom experimentu s MTU.