Container-HTTPS henger i et bedrifts-VPN? Test DTLS-beinet

Inne i en container bak et bedrifts-VPN løses DNS opp, innloggingssiden lastes, et helse-endepunkt svarer, og deretter henger en HTTPS-forespørsel til den timer ut. Å bygge imaget på nytt og endre proxy-variabler endrer ingenting, fordi den delen som feiler ikke er i imaget. Klienten autentiserer over én transport og flytter massedata over en annen, og bare den andre er ødelagt.

To transporter, ett forvirrende symptom

En bedriftsklient basert på TLS autentiserer vanligvis over en vanlig TLS-tilkobling og forhandler deretter en andre UDP-basert datakanal for økten. Når det andre beinet virker, blir gjennomstrømningen og latensen bedre. Når det filtreres eller ikke får plass gjennom ruten, lykkes alt før massetransporten, og selve overføringen stopper, som er nøyaktig mønsteret ovenfor.

En container endrer ikke den forhandlingen; den endrer ruten de ytre pakkene tar. Verten oversetter containerflyten, så UDP-datagrammene går ut fra en annen kildeport enn klientens lokale socket og kommer tilbake gjennom en oversettelsesoppføring som utløper på en mye kortere timer enn en etablert TCP-flyt. Hvis tunnelen virker på verten og feiler i containeren, sammenlign de to flytene før du klandrer applikasjonen. Den sammenligningen avgjør mer enn noen nybygging av imaget.

Avgjør ved eksperiment, ikke magefølelse

Det billigste eksperimentet slår av UDP-datakanalen og gjentar forespørselen. Bruk kommandolinjeklienten i stedet for skrivebordsinnpakningen, slik at flagget faktisk brukes: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Hvis forespørselen som hang nå fullføres, var DTLS-beinet problemet og resten støy.

Bekreft resultatet i begge retninger fra samme container, én massforespørsel med flagget og én uten. En atferdsendring som følger flagget er bevis; en side som til slutt lastes er ikke det.

Hvis flagget fikser det, avgjør hvorfor

Tre forhold gir samme symptom, og de krever ulike svar. Ruten kan filtrere UDP helt, noe som gjør flagget til det riktige permanente svaret for det nettverket. Ruten kan tillate UDP, men droppe store datagrammer, noe som peker på MTU og ikke filtrering. Eller ruten kan være så tapsutsatt at UDP-beinet yter dårligere enn TCP, som er en kapasitetsbeslutning og ikke en tilgjengelighetsbeslutning.

Skille dem før du dokumenterer en omvei. Filtrering overlever enhver pakkestørrelse, MTU-problemer vises bare over en terskel, og tap viser seg som retransmisjon og variabel forsinkelse og ikke som et rent heng. Hver test snevrer inn årsaken uten å endre klientkonfigurasjonen.

Sjekk pakkestørrelsen før du beholder omveien

Hvis størrelsen er årsaken, godtar tunellgrensesnittet pakker ruten ikke kan bære, og problemet kommer tilbake på enhver transport så snart nyttelasten vokser. Sammenlign grensesnittene: ip link show tun0 på verten, deretter docker network inspect bridge for å lese MTU-en som er registrert i nettverksvalgene. En containerbro som fortsatt står på 1500 byte under en tunnel som bærer mindre, er det vanlige funnet.

Søk oppover fra en kjent god størrelse med en do-not-fragment-test inne i tunnelen, og senk deretter MTU-en til containernettverket eller klem TCP MSS på tunnelen. Begge rettelsene gjør ofte UDP-ruten brukbar igjen og fjerner behovet for flagget, som er det bedre resultatet når filtrering ikke er årsaken.

Avgjør hva du er villig til å bytte

Med datakanalen deaktivert bærer tunnelen nyttelasten sin inne i en TCP-tilkobling. På en ren rute er det bare langsommere; på en tapsutsatt rute forsinker ett tapt segment alt bak det, og den ytre retransmisjonen konkurrerer med den indre. Den byttehandelen passer for interaktiv utvikling og små API-kall, og passer dårlig for massetransporter eller lange økter over mobile lenker.

Uansett hvilket alternativ du velger, noter hvilken transport tunnelen endte med å bruke og hvorfor. En container som i stillhet avhenger av et flagg noen la til for måneder siden, er den neste utfordringen, og den som feilsøker den vet ikke om flagget var en omvei for filtrering eller en rest fra et MTU-eksperiment.