Konteineri HTTPS takerdub ettevõtte VPN-is? Testige DTLS haru

Ettevõtte VPN-i taga olevas konteineris laheneb DNS, sisselogimisleht laaditakse, tervisekontrolli lõpp-punkt vastab ja siis takerdub HTTPS-päring kuni ajalõpuni. Image'i ümberehitamine ja puhverserveri muutujate muutmine ei muuda midagi, sest rikkis osa ei ole image'is. Klient autendib end ühe transpordi kaudu ja liigutab hulgiandmeid teise kaudu ning ainult teine on katki.

Kaks transporti, üks segane sümptom

TLS-põhine ettevõtteklient autendib end tavaliselt hariliku TLS-ühenduse kaudu ja peab seejärel seansi jaoks läbi teise, UDP-põhise andmekanali. Kui see teine haru töötab, paranevad läbilaskevõime ja latentsus. Kui see filtreeritakse või ei mahu teekonnale, õnnestub kõik enne hulgisiiret ja siire ise peatub, mis on täpselt ülaltoodud muster.

Konteiner ei muuda seda läbirääkimist; see muudab teed, mida välised paketid läbivad. Host tõlgib konteineri voo, nii et UDP-datagrammid väljuvad teisest lähtepordist kui kliendi kohalik pesa ja naasevad tõlkekirje kaudu, mis aegub palju lühema taimeriga kui loodud TCP voog. Kui tunnel töötab hostis ja ebaõnnestub konteineris, võrrelge neid kahte voogu enne rakenduse süüdistamist. See võrdlus otsustab rohkem kui ükski image'i ümberehitus.

Otsustage katse, mitte intuitsiooni järgi

Odavaim katse lülitab UDP andmekanali välja ja kordab päringut. Kasutage käsurea klienti, mitte töölaua mähise, et lipp tõesti rakenduks: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Kui takerdunud päring nüüd lõpule jõuab, oli probleem DTLS harus ja ülejäänu oli müra.

Kinnitage tulemus mõlemas suunas samast konteinerist: üks hulgipäring lipuga ja üks ilma. Lipule järgnev käitumismuutus on tõend; leht, mis lõpuks laaditakse, ei ole.

Kui lipp selle parandab, otsustage miks

Kolm tingimust tekitavad sama sümptomi ja nõuavad erinevaid vastuseid. Teekond võib UDP täielikult filtreerida, mis teeb lipu selle võrgu jaoks õigeks püsivaks vastuseks. Teekond võib UDP-d lubada, kuid suuri datagramme maha visata, mis viitab MTU-le, mitte filtreerimisele. Või võib teekond olla nii kadudega, et UDP haru töötab halvemini kui TCP, mis on läbilaskevõime, mitte kättesaadavuse otsus.

Eristage neid enne, kui dokumenteerite möödapääsulahendi. Filtreerimine püsib iga paketi suuruse juures, MTU-probleemid ilmnevad ainult üle lävendi ja kaod väljenduvad kordussaadetises ja muutlikus viites, mitte puhtas takerdumises. Iga test kitsendab põhjust ilma kliendi seadistust muutmata.

Kontrollige paketi suurust enne, kui möödapääsulahendi alles jätate

Kui põhjuseks on suurus, võtab tunneli liides vastu pakette, mida teekond kanda ei suuda, ja probleem naaseb igal transpordil niipea, kui kasulik koormus kasvab. Võrrelge liideseid: ip link show tun0 hostis, seejärel docker network inspect bridge, et lugeda võrguvalikutes kirjas olevat MTU-d. Konteineri sild, mis on endiselt 1500 baidi juures tunneli all, mis kannab vähem, on tavaline leid.

Sondige ülespoole teadaolevalt heast suurusest killustamiskeelu testiga tunneli sees, seejärel langetage konteineri võrgu MTU-d või klammerdage tunnelil TCP MSS. Kumbki parandus teeb UDP tee sageli taas kasutatavaks ja kõrvaldab lipu vajaduse, mis on parem tulemus, kui filtreerimine ei ole põhjus.

Otsustage, mida olete valmis vahetama

Andmekanali väljalülitamisel kannab tunnel oma koormust TCP-ühenduse sees. Puhtal teekonnal on see lihtsalt aeglasem; kadudega teekonnal viivitab üks kaotatud segment kõike selle taga ja välimine kordussaadetis konkureerib sisemisega. See vahetus sobib interaktiivseks arenduseks ja väikesteks API-kutseteks ning sobib halvasti hulgisiirete või pikkade seanssidega mobiililinkide kaudu.

Ükskõik millise valiku teete, kirjutage üles, millist transporti tunnel lõpuks kasutas ja miks. Konteiner, mis sõltub vaikselt lipust, mille keegi lisas kuid tagasi, on järgmine katkestus, ja selle siluja ei tea, kas lipp oli filtreerimise möödapääsulahendus või MTU-katse jääk.