HTTPS i en container bag en virksomheds-VPN hænger? Test DTLS-benet

Inde i en container bag en virksomheds-VPN opløses DNS, login-siden indlæses, et health-endpoint svarer, og derefter hænger en HTTPS-anmodning, indtil den timer ud. At genbygge imaget og ændre proxy-variabler ændrer intet, fordi den del, der fejler, ikke er i imaget. Klienten autentificerer over én transport og flytter massedata over en anden, og kun den anden er i stykker.

To transports, ét forvirrende symptom

En virksomhedsklient baseret på TLS autentificerer normalt over en almindelig TLS-forbindelse og forhandler derefter en anden UDP-baseret datakanal til sessionen. Når det andet ben virker, forbedres gennemstrømning og latenstid. Når det filtreres eller ikke kan passe gennem ruten, lykkes alt før massetransporten, og selve transporten stopper, hvilket er præcis mønstret ovenfor.

En container ændrer ikke den forhandling; den ændrer den rute, de ydre pakker tager. Værten oversætter containerens flow, så UDP-datagrammerne forlader fra en anden kildeport end klientens lokale socket og vender tilbage gennem en oversættelsespost, der udløber på en meget kortere timer end et etableret TCP-flow. Hvis tunnelen virker på værten og fejler i containeren, så sammenlign de to flows, før du bebrejder applikationen. Den sammenligning afgør mere end nogen genbygning af imaget.

Beslut ud fra eksperimenter, ikke mavefornemmelse

Det billigste eksperiment slår UDP-datakanalen fra og gentager anmodningen. Brug kommandolinjeklienten i stedet for desktop-omslaget, så flaget faktisk anvendes: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Hvis den anmodning, der hang, nu fuldføres, var DTLS-benet problemet, og resten var støj.

Bekræft resultatet i begge retninger fra samme container, én masseanmodning med flaget og én uden. En adfærdsændring, der følger flaget, er bevis; en side, der til sidst indlæses, er ikke.

Hvis flaget løser det, så afgør hvorfor

Tre forhold giver samme symptom, og de kræver forskellige svar. Ruten kan filtrere UDP helt, hvilket gør flaget til det korrekte permanente svar for det netværk. Ruten kan tillade UDP, men tabe store datagrammer, hvilket peger på MTU snarere end filtrering. Eller ruten kan være så tabende, at UDP-benet klarer sig dårligere end TCP, hvilket er en kapacitetsbeslutning snarere end en tilgængelighedsbeslutning.

Skeln mellem dem, før du dokumenterer en workaround. Filtrering overlever enhver pakkestørrelse, MTU-problemer viser sig kun over en tærskel, og tab viser sig som retransmission og variabel forsinkelse snarere end et rent hang. Hver test indsnævrer årsagen uden at ændre klientkonfigurationen.

Tjek pakkestørrelsen, før du beholder workarounden

Hvis størrelsen er årsagen, accepterer tunneinterface pakker, som ruten ikke kan bære, og problemet vender tilbage på enhver transport, så snart nyttelasten vokser. Sammenlign interfacene: ip link show tun0 på værten, derefter docker network inspect bridge for at læse den MTU, der er registreret i netværksindstillingerne. En containerbro, der stadig er på 1500 byte under en tunnel, der bærer mindre, er det sædvanlige fund.

Søg opad fra en kendt god størrelse med en do-not-fragment-test inde i tunnelen, og sænk derefter containerens netværks-MTU eller clamp TCP MSS på tunnelen. Hver af rettelserne gør ofte UDP-ruten brugbar igen og fjerner behovet for flaget, hvilket er det bedre udfald, når filtrering ikke er årsagen.

Beslut, hvad du er villig til at bytte

Med datakanalen deaktiveret bærer tunnelen sin nyttelast inde i en TCP-forbindelse. På en ren rute er det blot langsommere; på en tabende rute forsinker et enkelt tabt segment alt bag det, og den ydre retransmission konkurrerer med den indre. Den byttehandel passer til interaktiv udvikling og små API-kald og passer dårligt til massetransporter eller lange sessioner over mobile links.

Uanset hvilken mulighed du vælger, så noter, hvilken transport tunnelen endte med at bruge, og hvorfor. En container, der i det stille afhænger af et flag, nogen tilføjede for måneder siden, er den næste nedbrud, og den person, der fejlfinder den, ved ikke, om flaget var en workaround for filtrering eller en rest fra et MTU-eksperiment.