HTTPS v vsebniku se zatakne na poslovnem VPN? Preizkusite krak DTLS

V vsebniku za poslovnim VPN se DNS razreši, prijavna stran se naloži, končna točka za zdravje odgovori, nato pa zahteva HTTPS obvisi, dokler ne poteče čas. Ponovno graditi sliko in spreminjati proxy spremenljivke ne spremeni ničesar, ker okvarjeni del ni v sliki. Odjemalec se overi prek enega prevoza in prenaša velike podatke prek drugega, in pokvarjen je le drugi.

Dva prevoza, en zmeden simptom

Poslovni odjemalec, ki temelji na TLS, se običajno overi prek običajne povezave TLS, nato pa se za sejo dogovori o drugem podatkovnem kanalu, ki temelji na UDP. Ko ta drugi krak deluje, se prepustnost in zakasnitev izboljšata. Ko je filtriran ali se ne ujame v pot, vse pred velikim prenosom uspe, sam prenos pa se ustavi, kar je natanko zgornji vzorec.

Vsebnik tega dogovarjanja ne spremeni; spremeni pot, po kateri gredo zunanji paketi. Gostitelj prevede tok vsebnika, zato datagrami UDP odhajajo z drugega izvornega vrat kot lokalni vtičnica odjemalca in se vračajo skozi prevodni vnos, ki poteče na veliko krajšem časovniku kot vzpostavljen tok TCP. Če tunel deluje na gostitelju, v vsebniku pa ne, primerjajte ta dva toka, preden obtožite aplikacijo. Ta primerjava razreši več kot kakršna koli ponovna gradnja slike.

Odločajte s poskusom, ne z intuicijo

Najcenejši poskus izklopi podatkovni kanal UDP in ponovi zahtevo. Uporabite odjemalca ukazne vrstice namesto namiznega ovoja, da se zastavica res uporabi: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Če se zahteva, ki je obvisela, zdaj zaključi, je bil krak DTLS težava, ostalo pa šum.

Rezultat potrdite v obe smeri iz istega vsebnika: ena velika zahteva z zastavico in ena brez. Sprememba vedenja, ki sledi zastavici, je dokaz; stran, ki se na koncu naloži, ni.

Če zastavica to popravi, odločite zakaj

Trije pogoji dajejo enak simptom in zahtevajo različne odzive. Pot lahko UDP popolnoma filtrira, kar naredi zastavico pravilen trajen odgovor za to omrežje. Pot lahko dovoljuje UDP, a zavrača velike datagrame, kar kaže na MTU, ne na filtriranje. Ali pa je pot tako izgubna, da krak UDP deluje slabše kot TCP, kar je odločitev o zmogljivosti, ne o dosegljivosti.

Razlikujte jih, preden dokumentirate obhod. Filtriranje preživi vsako velikost paketa, težave z MTU se pokažejo šele nad pragom, izgube pa se kažejo kot ponovno pošiljanje in spremenljiva zakasnitev, ne kot čisto obvisenje. Vsak test zoži vzrok, ne da bi spremenil konfiguracijo odjemalca.

Preverite velikost paketa, preden obdržite obhod

Če je vzrok velikost, vmesnik tunela sprejema pakete, ki jih pot ne more nositi, in težava se vrne na vsakem prevozu, takoj ko breme naraste. Primerjajte vmesnike: ip link show tun0 na gostitelju, nato docker network inspect bridge za branje MTU, zapisanega v omrežnih možnostih. Vsebniški most, ki je še vedno na 1500 bajtih pod tunelom, ki nosi manj, je običajna ugotovitev.

Sondirajte navzgor od znane dobre velikosti s preskusom prepovedi drobljenja znotraj tunela, nato znižajte MTU vsebniškega omrežja ali zategnite TCP MSS na tunelu. Vsak od popravkov pogosto znova naredi pot UDP uporabno in odpravi potrebo po zastavici, kar je boljši izid, kadar filtriranje ni vzrok.

Odločite, kaj ste pripravljeni zamenjati

Z izklopljenim podatkovnim kanalom tunel nosi svoje breme znotraj povezave TCP. Na čisti poti je to le počasneje; na izgubni en sam izgubljen segment zakasni vse za njim in zunanje ponovno pošiljanje tekmuje z notranjim. Ta menjava ustreza interaktivnemu razvoju in majhnim klicem API, slabo pa ustreza velikim prenosom ali dolgim sejam prek mobilnih povezav.

Katero koli možnost izberete, zabeležite, kateri prevoz je tunel na koncu uporabil in zakaj. Vsebnik, ki tiho visi na zastavici, ki jo je nekdo dodal pred meseci, je naslednja odpoved, in tisti, ki jo bo razhroščeval, ne bo vedel, ali je bila zastavica obhod za filtriranje ali ostanek poskusa z MTU.