HTTPS u kontejneru iza korporativnog VPN-a zapinje? Testirajte DTLS krak

Unutar kontejnera iza korporativnog VPN-a DNS se razrješava, stranica za prijavu se učita, zdravstvena krajnja točka odgovori, a zatim HTTPS zahtjev zapne dok ne istekne vrijeme. Ponovna izgradnja slike i promjena proxy varijabli ne mijenjaju ništa jer neispravni dio nije u slici. Klijent se autentificira preko jednog prijenosa i prenosi velike podatke preko drugog, a samo je drugi pokvaren.

Dva prijenosa, jedan zbunjujući simptom

Korporativni klijent zasnovan na TLS-u obično se autentificira preko obične TLS veze, a zatim pregovara drugi podatkovni kanal zasnovan na UDP-u za sesiju. Kad ta druga noga radi, propusnost i latencija se poboljšavaju. Kad je filtrirana ili ne može proći putem, sve prije velikog prijenosa uspijeva, a sam prijenos staje, što je točno gornji obrazac.

Kontejner ne mijenja taj pregovor; mijenja put kojim idu vanjski paketi. Host prevodi tok kontejnera, pa UDP datagrami izlaze s drugog izvornog porta od lokalnog socketa klijenta i vraćaju se kroz zapis prijevoda koji istječe na mnogo kraćem mjeraču od uspostavljenog TCP toka. Ako tunel radi na hostu, a ne uspijeva u kontejneru, usporedite ta dva toka prije nego što okrivite aplikaciju. Ta usporedba rješava više od bilo koje ponovne izgradnje slike.

Odlučujte eksperimentom, ne intuicijom

Najjeftiniji eksperiment isključuje UDP podatkovni kanal i ponavlja zahtjev. Upotrijebite klijent naredbenog retka umjesto radne ljuske kako bi se zastavica doista primijenila: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Ako se zahtjev koji je zapinjao sada dovrši, DTLS krak je bio problem, a ostalo je šum.

Potvrdite rezultat u oba smjera iz istog kontejnera: jedan veliki zahtjev sa zastavicom i jedan bez nje. Promjena ponašanja koja slijedi zastavicu je dokaz; stranica koja se na kraju učita nije.

Ako zastavica to popravi, odlučite zašto

Tri uvjeta daju isti simptom i traže različite odgovore. Put može potpuno filtrirati UDP, što zastavicu čini ispravnim trajnim odgovorom za tu mrežu. Put može dopuštati UDP, ali odbacivati velike datagrame, što upućuje na MTU, a ne na filtriranje. Ili put može biti toliko gubitnički da UDP krak radi lošije od TCP-a, što je odluka o kapacitetu, a ne o dostupnosti.

Razlikujte ih prije nego što dokumentirate zaobilazno rješenje. Filtriranje preživljava svaku veličinu paketa, problemi s MTU-om pojavljuju se samo iznad praga, a gubitak se pokazuje kao ponovno slanje i promjenjivo kašnjenje, a ne kao čisto zapinjanje. Svaki test sužava uzrok bez promjene konfiguracije klijenta.

Provjerite veličinu paketa prije nego što zadržite zaobilazno rješenje

Ako je veličina uzrok, sučelje tunela prihvaća pakete koje put ne može nositi, a problem se vraća na svakom prijenosu čim teret naraste. Usporedite sučelja: ip link show tun0 na hostu, zatim docker network inspect bridge za čitanje MTU-a zabilježenog u mrežnim opcijama. Kontejnerski most koji je još na 1500 bajtova ispod tunela koji nosi manje uobičajen je nalaz.

Sondirajte prema gore od poznate dobre veličine testom bez fragmentacije unutar tunela, zatim snizite MTU kontejnerske mreže ili stisnite TCP MSS na tunelu. Svaki od tih ispravaka često vraća UDP put u upotrebljivo stanje i uklanja potrebu za zastavicom, što je bolji ishod kad filtriranje nije uzrok.

Odlučite što ste spremni zamijeniti

S isključenim podatkovnim kanalom tunel nosi svoj teret unutar TCP veze. Na čistom putu to je samo sporije; na gubitničkom, jedan izgubljeni segment odgađa sve iza sebe i vanjsko ponovno slanje natječe se s unutarnjim. Ta razmjena odgovara interaktivnom razvoju i malim API pozivima, a loše pristaje velikim prijenosima ili dugim sesijama preko mobilnih veza.

Koju god opciju odabrali, zabilježite koji je prijenos tunel na kraju koristio i zašto. Kontejner koji tiho ovisi o zastavici koju je netko dodao prije mjeseci sljedeći je ispad, a osoba koja ga bude otklanjala neće znati je li zastavica bila zaobilazno rješenje za filtriranje ili ostatak pokusa s MTU-om.