Stoppar HTTPS í gámi bak við fyrirtækis-VPN? Prófaðu DTLS-fótinn

Inni í gámi bak við fyrirtækis-VPN leysist DNS, innskráningarsíðan hleðst, heilsufarsendapunktur svarar, og þá stoppar HTTPS-beiðni þar til tíminn rennur út. Að endurbyggja ímyndina og breyta proxy-breytum breytir engu, því bilaði hlutinn er ekki í ímyndinni. Biðlarinn auðkennir sig yfir einum flutningi og flytur magnmikil gögn yfir öðrum, og aðeins sá seinni er bilaður.

Tveir flutningar, eitt ruglandi einkenni

Fyrirtækjabiðlari byggður á TLS auðkennir sig venjulega yfir venjulegri TLS-tengingu og semur síðan um aðra UDP-gagnarás fyrir lotuna. Þegar sá seinni fótur virkar batna afköst og seinkun. Þegar hann er síaður eða kemst ekki í gegnum slóðina tekst allt fyrir magnflutninginn og flutningurinn sjálfur stöðvast, sem er einmitt mynstrið hér að ofan.

Gámur breytir ekki þeirri samningaviðræðu; hann breytir slóðinni sem ytri pakkarnir fara. Hýsillinn þýðir straum gámsins, svo UDP-datagrammin fara frá öðru upprunahöfn en staðbundin sókn biðlarans og snúa aftur um þýðingarfærslu sem rennur út á mun styttri tíma en staðfest TCP-straumur. Ef göngin virka á hýslinum en mistakast í gáminum, berðu saman þessa tvo strauma áður en þú kennir forritinu um. Sá samanburður sker úr um meira en nokkur endurbygging ímyndar.

Ákveddu með tilraun, ekki innsæi

Ódýrasta tilraunin slekkur á UDP-gagnarásinni og endurtekur beiðnina. Notaðu skipanalínubiðlarann í stað skjáborðsumbúðarinnar, svo fáninn virki í raun: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Ef beiðnin sem stöðvaðist klárast núna, var DTLS-fóturinn vandamálið og restin hávaði.

Staðfestu niðurstöðuna í báðar áttir úr sama gámi, ein magnbeiðni með fánanum og ein án. Atferlisbreyting sem fylgir fánanum er sönnun; síða sem hleðst að lokum er það ekki.

Ef fáninn lagar það, ákveddu hvers vegna

Þrjú skilyrði framkalla sama einkennið og kalla á mismunandi viðbrögð. Slóðin getur síað UDP algjörlega, sem gerir fánann að réttu varanlegu svari fyrir það net. Slóðin getur leyft UDP en sleppt stórum datagrammum, sem bendir til MTU frekar en síunar. Eða slóðin getur verið svo tapmikil að UDP-fóturinn stendur sig verr en TCP, sem er ákvörðun um afkastagetu en ekki um aðgengi.

Greindu þau áður en þú skjalfestir vinnulausn. Síun lifir allri pakkastærð, MTU-vandamál koma aðeins fram yfir þröskuldi og tap birtist sem endursending og breytileg seinkun en ekki hrein stöðvun. Hver prófun þrengir orsökina án þess að breyta stillingum biðlarans.

Athugaðu pakkastærð áður en þú heldur vinnulausninni

Ef stærðin er orsökin tekur göngutengið við pökkum sem slóðin getur ekki borið, og vandamálið kemur aftur á hvaða flutningi sem er um leið og farmurinn stækkar. Berðu saman tengin: ip link show tun0 á hýslinum, síðan docker network inspect bridge til að lesa MTU sem skráð er í netvalkostunum. Gámabrú sem er enn á 1500 bætum undir göngum sem bera minna er algenga niðurstaðan.

Kannaðu upp á við frá þekktri góðri stærð með prófun án sundrungar inni í göngunum, lækkaðu síðan MTU gámanetsins eða þrengdu TCP MSS á göngunum. Hvor leiðréttingin sem er gerir UDP-slóðina oft nothæfa aftur og fjarlægir þörfina fyrir fánann, sem er betri niðurstaða þegar síun er ekki orsökin.

Ákveddu hverju þú ert tilbúin að skipta á móti

Með gagnarásinni óvirka bera göngin farm sinn inni í TCP-tengingu. Á hreinni slóð er það bara hægara; á tapmikilli slóð seinkar einu töpuðu sviði öllu sem á eftir kemur og ytri endursending keppir við innri. Þessi skipti henta gagnvirkri þróun og litlum API-köllum og henta illa magnflutningum eða löngum lotum um farsímatengingar.

Hvaða valkost sem þú velur skaltu skrá hvaða flutning göngin enduðu á að nota og hvers vegna. Gámur sem byggir hljóðlega á fána sem einhver bætti við fyrir mánuðum er næsta bilun, og sá sem kembir henni veit ekki hvort fáninn var vinnulausn fyrir síun eða leifar af MTU-tilraun.