Nag-hang ang HTTPS sa container sa corporate VPN? Subukan ang DTLS na binti

Sa loob ng container sa likod ng corporate VPN, nagre-resolve ang DNS, naglo-load ang login page, sumasagot ang health endpoint, at pagkatapos ay nag-hang ang isang HTTPS request hanggang mag-timeout. Walang nababago sa muling pagbuo ng image at pagbabago ng proxy variables, dahil ang sirang bahagi ay wala sa image. Nagpapatunay ng pagkakakilanlan ang client sa isang transport at naglilipat ng malaking data sa iba, at ang pangalawa lang ang sira.

Dalawang transport, isang nakalilitong sintomas

Ang corporate client na nakabatay sa TLS ay karaniwang nagpapatunay sa isang ordinaryong TLS connection, tapos nakikipag-ayos ng pangalawang UDP-based na data channel para sa session. Kapag gumana ang pangalawang binting iyon, bumubuti ang throughput at latency. Kapag sinasala ito o hindi kasya sa landas, nagtatagumpay ang lahat bago ang malaking paglilipat at humihinto ang paglilipat mismo, na eksaktong pattern sa itaas.

Hindi binabago ng container ang negosasyong iyon; binabago nito ang landas na tinatahak ng panlabas na packet. Isinasalin ng host ang daloy ng container, kaya lumalabas ang UDP datagram mula sa ibang source port kaysa sa lokal na socket ng client, at bumabalik sa pamamagitan ng translation entry na nag-expire sa mas maikling timer kaysa sa establisadong TCP flow. Kung gumagana ang tunnel sa host pero nabigo sa container, ihambing ang dalawang daloy na iyon bago sisihin ang application. Mas maraming napagpapasyahan ng paghahambing na iyon kaysa sa anumang muling pagbuo ng image.

Magpasya sa pamamagitan ng eksperimento, hindi sa hula

Ang pinakamurang eksperimento ay i-disable ang UDP data channel at ulitin ang request. Gamitin ang command-line client sa halip na desktop wrapper, para tunay na mailapat ang flag: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Kung natapos na ngayon ang request na nag-hang, ang DTLS na binti ang problema at ang natitira ay ingay.

Kumpirmahin ang resulta sa dalawang direksyon mula sa parehong container, isang malaking request na may flag at isa na wala. Ang pagbabago ng pag-uugali na sumusunod sa flag ay ebidensya; ang pahinang sa huli ay nag-load ay hindi.

Kung naayos ito ng flag, magpasya kung bakit

Tatlong kondisyon ang gumagawa ng parehong sintomas, at kailangan nila ng magkakaibang tugon. Maaaring salain ng landas ang UDP nang buo, na ginagawang ang flag ang tamang permanenteng sagot para sa network na iyon. Maaaring payagan ng landas ang UDP pero itinatapon ang malalaking datagram, na tumuturo sa MTU at hindi sa pagsasala. O maaaring sapat ang pagkawala sa landas para mas mahina ang binti ng UDP kaysa TCP, na desisyon sa kapasidad at hindi sa abot.

Ibukod ang mga ito bago idokumento ang isang solusyong pansamantala. Nabubuhay ang pagsasala sa anumang laki ng packet, lumilitaw lamang ang mga problema sa MTU sa itaas ng isang hangganan, at lumilitaw ang pagkawala bilang retransmission at nagbabagong pagkaantala, hindi bilang malinis na pag-hang. Bawat pagsubok ay nagpapaliit ng dahilan nang hindi binabago ang configuration ng client.

Tingnan ang laki ng packet bago panatilihin ang pansamantalang solusyon

Kung laki ang dahilan, tinatanggap ng tunnel interface ang mga packet na hindi kayang dalhin ng landas, at bumabalik ang problema sa anumang transport sa sandaling lumaki ang payload. Ihambing ang mga interface: ip link show tun0 sa host, tapos docker network inspect bridge para basahin ang MTU na nakatala sa mga network option. Ang container bridge na nasa 1500 byte pa rin sa ilalim ng tunnel na mas kaunti ang dinadala ang karaniwang natuklasan.

Mag-probe pataas mula sa kilalang magandang laki gamit ang do-not-fragment test sa loob ng tunnel, tapos ibaba ang MTU ng container network o higpitan ang TCP MSS sa tunnel. Alinman sa dalawang pagwawasto ay madalas na nagpapaging-gamit muli ng UDP path at nag-aalis ng pangangailangan sa flag, na siyang mas magandang kinalabasan kapag hindi pagsasala ang dahilan.

Magpasya kung ano ang handa mong isuko

Kapag naka-disable ang data channel, dinadala ng tunnel ang payload sa loob ng TCP connection. Sa malinis na landas ito ay mas mabagal lamang; sa may pagkawala, ang isang nawawalang segment ay nagpapabagal sa lahat ng nasa likod nito at ang panlabas na retransmission ay nakikipagkumpitensya sa panloob. Ang palitang iyon ay bagay sa interactive na pag-unlad at maliliit na API call, at hindi bagay sa malalaking paglilipat o mahabang session sa mobile link.

Anuman ang piliin mong opsyon, itala kung aling transport ang ginamit ng tunnel sa huli at bakit. Ang container na tahimik na umaasa sa flag na idinagdag ng isang tao ilang buwan na ang nakalipas ay ang susunod na pagkaabala, at ang magde-debug nito ay hindi malalaman kung ang flag ay pansamantalang solusyon sa pagsasala o labi ng eksperimento sa MTU.