Container-HTTPS hänger på ett företags-VPN? Testa DTLS-benet

Inne i en container bakom ett företags-VPN löses DNS upp, inloggningssidan laddas, en hälsoendpunkt svarar, och sedan hänger en HTTPS-begäran tills den timar ut. Att bygga om imagen och ändra proxyvariabler ändrar ingenting, eftersom den trasiga delen inte finns i imagen. Klienten autentiserar över en transport och flyttar massdata över en annan, och bara den andra är trasig.

Två transporter, ett förvirrande symptom

En företagsklient baserad på TLS autentiserar vanligtvis över en vanlig TLS-anslutning och förhandlar sedan en andra UDP-baserad datakanal för sessionen. När det andra benet fungerar förbättras genomströmning och latens. När det filtreras eller inte får plats genom vägen lyckas allt före massöverföringen och själva överföringen stannar, vilket är exakt mönstret ovan.

En container ändrar inte den förhandlingen; den ändrar vägen som de yttre paketen tar. Värden översätter containerflödet, så UDP-datagrammen lämnar från en annan källport än klientens lokala socket och kommer tillbaka genom en översättningspost som löper ut på en mycket kortare timer än ett etablerat TCP-flöde. Om tunneln fungerar på värden men misslyckas i containern, jämför de två flödena innan du skyller på applikationen. Den jämförelsen avgör mer än någon ombyggnad av imagen.

Bestäm genom experiment, inte magkänsla

Det billigaste experimentet stänger av UDP-datakanalen och upprepar begäran. Använd kommandorads-klienten i stället för skrivbordsomslaget, så att flaggan verkligen tillämpas: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Om begäran som hängde nu slutförs var DTLS-benet problemet och resten brus.

Bekräfta resultatet i båda riktningarna från samma container, en massbegäran med flaggan och en utan. En beteendeförändring som följer flaggan är bevis; en sida som till slut laddas är det inte.

Om flaggan löser det, bestäm varför

Tre förhållanden ger samma symptom och kräver olika svar. Vägen kan filtrera UDP helt, vilket gör flaggan till det korrekta permanenta svaret för det nätverket. Vägen kan tillåta UDP men släppa stora datagram, vilket pekar på MTU och inte filtrering. Eller så kan vägen vara så förlustbenägen att UDP-benet presterar sämre än TCP, vilket är ett kapacitetsbeslut och inte ett nåbarhetsbeslut.

Skilj dem åt innan du dokumenterar en kringgående lösning. Filtrering överlever varje paketstorlek, MTU-problem syns bara över en tröskel, och förlust visar sig som omsändning och variabel fördröjning i stället för ett rent häng. Varje test snävar in orsaken utan att ändra klientkonfigurationen.

Kontrollera paketstorleken innan du behåller kringgåendet

Om storleken är orsaken tar tunnelgränssnittet emot paket som vägen inte kan bära, och problemet återkommer på alla transporter så snart nyttolasten växer. Jämför gränssnitten: ip link show tun0 på värden, sedan docker network inspect bridge för att läsa den MTU som finns i nätverksalternativen. En containerbrygga som fortfarande står på 1500 byte under en tunnel som bär mindre är det vanliga fyndet.

Sök uppåt från en känd bra storlek med ett do-not-fragment-test inne i tunneln, sänk sedan containernätets MTU eller kläm TCP MSS på tunneln. Båda rättelserna gör ofta UDP-vägen användbar igen och tar bort behovet av flaggan, vilket är det bättre resultatet när filtrering inte är orsaken.

Bestäm vad du är beredd att byta

Med datakanalen avstängd bär tunneln sin last inuti en TCP-anslutning. På en ren väg är det bara långsammare; på en förlustbenägen fördröjer ett enda förlorat segment allt bakom det och den yttre omsändningen konkurrerar med den inre. Den byteshandeln passar interaktiv utveckling och små API-anrop och passar dåligt för massöverföringar eller långa sessioner över mobila länkar.

Vilket alternativ du än väljer, notera vilken transport tunneln till slut använde och varför. En container som i tysthet hänger på en flagga som någon lade till för månader sedan är nästa avbrott, och den som felsöker den vet inte om flaggan var ett kringgående för filtrering eller en rest från ett MTU-experiment.