Heng HTTPS i ein container på eit bedrifts-VPN? Test DTLS-beinet
Innlogging verkar i containeren, men HTTPS heng, så test UDP-datakanalen. Slå av DTLS, samanlikn begge flytane og sjekk deretter MTU før du held på flagget.
Inne i ein container bak eit bedrifts-VPN blir DNS løyst opp, innloggingssida blir lasta, eit helseendepunkt svarar, og deretter heng ein HTTPS-førespurnad til han går ut på tid. Å byggje imaget på nytt og endre proxyvariablar endrar ingenting, fordi delen som feilar ikkje er i imaget. Klienten autentiserer over éin transport og flyttar massedata over ein annan, og berre den andre er øydelagd.
To transportar, eitt forvirrande symptom
Ein bedriftsklient basert på TLS autentiserer vanlegvis over ei vanleg TLS-tilkopling og forhandlar deretter ein andre UDP-basert datakanal for økta. Når det andre beinet verkar, blir gjennomstrøyminga og latensen betre. Når det blir filtrert eller ikkje får plass gjennom ruta, lukkast alt før massetransporten, og sjølve overføringa stoppar, som er nøyaktig mønsteret ovanfor.
Ein container endrar ikkje den forhandlinga; han endrar ruta dei ytre pakkane tek. Verten omset containerflyten, så UDP-datagramma går ut frå ein annan kjeldeport enn den lokale socketen til klienten og kjem tilbake gjennom ein omsetjingsoppføring som går ut på ein mykje kortare timar enn ein etablert TCP-flyt. Viss tunnelen verkar på verten og feilar i containeren, samanlikn dei to flytane før du klandrar applikasjonen. Den samanlikninga avgjer meir enn nokon nybygging av imaget.
Avgjer ved eksperiment, ikkje magekjensle
Det billegaste eksperimentet slår av UDP-datakanalen og gientek førespurnaden. Bruk kommandolinjeklienten i staden for skrivebordsinnpakninga, slik at flagget faktisk blir brukt: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Viss førespurnaden som hang no blir fullført, var DTLS-beinet problemet og resten støy.
Stadfest resultatet i båe retningar frå same container, éin massførespurnad med flagget og éin utan. Ei åtferdsendring som følgjer flagget er bevis; ei side som til slutt blir lasta er ikkje det.
Viss flagget fiksar det, avgjer kvifor
Tre tilhøve gir same symptom, og dei krev ulike svar. Ruta kan filtrere UDP heilt, noko som gjer flagget til det rette permanente svaret for det nettet. Ruta kan tillate UDP, men sleppe store datagram, noko som peikar på MTU og ikkje filtrering. Eller ruta kan vere så tapsutsett at UDP-beinet yter dårlegare enn TCP, som er eit kapasitetsvedtak og ikkje eit tilgjengevedtak.
Skil dei før du dokumenterer ein omveg. Filtrering overlever kvar pakkestorleik, MTU-problem viser seg berre over ein terskel, og tap viser seg som retransmisjon og variabel forseinking og ikkje som eit reint heng. Kvar test snevrar inn årsaka utan å endre klientkonfigurasjonen.
Sjekk pakkestorleiken før du held på omvegen
Viss storleiken er årsaka, godtek tunellgrensesnittet pakkar ruta ikkje kan bera, og problemet kjem tilbake på kvar transport så snart nyttelasta veks. Samanlikn grensesnitta: ip link show tun0 på verten, deretter docker network inspect bridge for å lese MTU-en som er registrert i nettverksvala. Ei containerbru som framleis står på 1500 byte under ein tunnel som ber mindre, er det vanlege funnet.
Søk oppover frå ein kjend god storleik med ein do-not-fragment-test inne i tunnelen, og senk deretter MTU-en til containernettverket eller klem TCP MSS på tunnelen. Båe rettingane gjer ofte UDP-ruta brukbar igjen og fjernar trongen for flagget, som er det betre resultatet når filtrering ikkje er årsaka.
Avgjer kva du er villig til å bytte
Med datakanalen deaktivert ber tunnelen nyttelasta si inne i ei TCP-tilkopling. På ei rein rute er det berre seinare; på ei tapsutsett rute forseinkar eitt tapt segment alt bak det, og den ytre retransmisjonen konkurrerer med den indre. Den bytehandelen passar for interaktiv utvikling og små API-kall, og passar dårleg for massetransportar eller lange økter over mobile lenkjer.
Uansett kva alternativ du vel, noter kva transport tunnelen enda med å bruke og kvifor. Ein container som i det stille er avhengig av eit flagg nokon la til for månader sidan, er den neste feilen, og den som feilsøkjer han veit ikkje om flagget var ein omveg for filtrering eller ein rest frå eit MTU-eksperiment.