Tökkääkö kontin HTTPS yrityksen VPN:ssä? Testaa DTLS-haara

Yrityksen VPN:n takana olevan kontin sisällä DNS ratkeaa, kirjautumissivu latautuu, terveyspäätepiste vastaa, ja sitten HTTPS-pyyntö jumittuu, kunnes aikakatkaisu iskee. Imagen uudelleenrakentaminen ja välityspalvelimen muuttujien vaihtaminen eivät muuta mitään, koska vikaantunut osa ei ole imagessa. Asiakas todentaa itsensä yhden siirtotien kautta ja siirtää massadataa toisen kautta, ja vain toinen on rikki.

Kaksi siirtotietä, yksi hämmentävä oire

TLS-pohjainen yritysasiakas todentaa itsensä yleensä tavallisen TLS-yhteyden kautta ja neuvottelee sitten istunnolle toisen, UDP-pohjaisen datakanavan. Kun tämä toinen haara toimii, läpäisykyky ja viive paranevat. Kun se suodatetaan tai ei mahdu reitille, kaikki ennen massasiirtoa onnistuu ja itse siirto pysähtyy, mikä on täsmälleen yllä kuvattu malli.

Kontti ei muuta tuota neuvottelua; se muuttaa reittiä, jonka ulommat paketit kulkevat. Isäntä kääntää kontin virran, joten UDP-datagrammit lähtevät eri lähdeportista kuin asiakkaan paikallinen pistoke ja palaavat käännöskohdan kautta, joka vanhenee paljon lyhyemmällä ajastimella kuin vakiintunut TCP-virta. Jos tunneli toimii isännällä ja epäonnistuu kontissa, vertaa näitä kahta virtaa ennen kuin syytät sovellusta. Se vertailu ratkaisee enemmän kuin mikään imagen uudelleenrakennus.

Päätä kokeella, älä vaistolla

Halvin koe poistaa UDP-datankanavan käytöstä ja toistaa pyynnön. Käytä komentoriviasiakasta työpöytäkuoren sijaan, jotta lippu todella tulee voimaan: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Jos jumittunut pyyntö nyt valmistuu, DTLS-haara oli ongelma ja muu oli kohinaa.

Vahvista tulos molemmissa suunnissa samasta kontista: yksi massapyyntö lipulla ja yksi ilman. Lippua seuraava käyttäytymismuutos on todiste; sivu, joka lopulta latautuu, ei ole.

Jos lippu korjaa sen, päätä miksi

Kolme ehtoa tuottaa saman oireen, ja ne vaativat erilaisia vastauksia. Reitti voi suodattaa UDP:n kokonaan, mikä tekee lipusta oikean pysyvän vastauksen kyseiselle verkolle. Reitti voi sallia UDP:n mutta pudottaa suuret datagrammit, mikä viittaa MTU:hun eikä suodatukseen. Tai reitti voi olla niin häviöllinen, että UDP-haara suoriutuu huonommin kuin TCP, mikä on kapasiteettipäätös eikä tavoitettavuuspäätös.

Erottele ne ennen kuin dokumentoit kiertotien. Suodatus kestää kaikki pakettikoot, MTU-ongelmat ilmenevät vain kynnyksen yläpuolella ja häviöt näkyvät uudelleenlähetyksinä ja vaihtelevana viiveenä eikä puhtaana jumittumisena. Jokainen koe rajaa syytä muuttamatta asiakkaan kokoonpanoa.

Tarkista pakettikoko ennen kuin pidät kiertotien

Jos koko on syy, tunnelin rajapinta hyväksyy paketteja, joita reitti ei kanna, ja ongelma palaa millä tahansa siirtotiellä heti kun hyötykuormat kasvavat. Vertaa rajapintoja: ip link show tun0 isännällä, sitten docker network inspect bridge lukeaksesi verkon asetuksissa kirjatun MTU:n. Konttisilta, joka on yhä 1500 tavussa tunnelin alla, joka kantaa vähemmän, on tavallinen löydös.

Koe ylöspäin tunnetusta hyvästä koosta ei-fragmentointitestillä tunnelin sisällä, laske sitten konttiverkon MTU:ta tai kiristä TCP MSS tunnelilla. Kumpi tahansa korjaus tekee UDP-reitistä usein taas käyttökelpoisen ja poistaa lipun tarpeen, mikä on parempi lopputulos, kun suodatus ei ole syy.

Päätä, mitä olet valmis vaihtamaan

Kun datakanava on pois käytöstä, tunneli kuljettaa hyötykuormansa TCP-yhteyden sisällä. Puhtaalla reitillä se on vain hitaampaa; häviöllisellä reitillä yksi kadonnut segmentti viivästyttää kaikkea sen takana ja ulompi uudelleenlähetys kilpailee sisemmän kanssa. Tämä vaihtokauppa sopii interaktiiviseen kehitykseen ja pieniin API-kutsuihin ja sopii huonosti massasiirtoihin tai pitkiin istuntoihin mobiililinkeillä.

Minkä vaihtoehdon valitsetkin, kirjaa, mitä siirtotietä tunneli lopulta käytti ja miksi. Kontti, joka hiljaa nojaa lippuun, jonka joku lisäsi kuukausia sitten, on seuraava katkos, eikä sitä debuggaava tiedä, oliko lippu kiertotie suodatukselle vai MTU-kokeen jäänne.