Megakad a konténer HTTPS-e a vállalati VPN-en? Tesztelje a DTLS lábat

Egy vállalati VPN mögötti konténerben a DNS feloldódik, a bejelentkező oldal betöltődik, egy állapotvégpont válaszol, majd egy HTTPS kérés megakad, amíg le nem jár az időtúllépés. Az image újraépítése és a proxy változók módosítása nem változtat semmit, mert a hibás rész nincs az image-ben. Az ügyfél az egyik átvitelen hitelesít, a nagy adatokat a másikon mozgatja, és csak a második hibás.

Két átvitel, egy zavaros tünet

A TLS-alapú vállalati ügyfél általában egy közönséges TLS-kapcsolaton hitelesít, majd a munkamenethez egy második, UDP-alapú adatcsatornát tárgyal. Amikor ez a második láb működik, javul az átviteli sebesség és a késleltetés. Amikor szűrik, vagy nem fér bele az útvonalba, a nagy átvitel előtti minden sikerül, és maga az átvitel megáll, ami pontosan a fenti minta.

A konténer nem változtat ezen a tárgyaláson; a külső csomagok útvonalát változtatja. A gazdagép lefordítja a konténer folyamát, így az UDP datagramok más forrásportból indulnak, mint az ügyfél helyi socketje, és egy olyan fordítási bejegyzésen keresztül térnek vissza, amely sokkal rövidebb időzítővel jár le, mint egy kiépült TCP folyam. Ha az alagút a gazdagépen működik és a konténerben nem, hasonlítsa össze ezt a két folyamot, mielőtt az alkalmazást hibáztatná. Ez az összehasonlítás többet dönt el, mint bármilyen image-újraépítés.

Kísérlettel döntsön, ne megérzéssel

A legolcsóbb kísérlet kikapcsolja az UDP adatcsatornát, és megismétli a kérést. A parancssori ügyfelet használja az asztali burkoló helyett, hogy a kapcsoló valóban érvényesüljön: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Ha a korábban akadó kérés most befejeződik, a DTLS láb volt a probléma, a többi pedig zaj.

Erősítse meg az eredményt mindkét irányban ugyanabból a konténerből: egy nagy kérés a kapcsolóval és egy anélkül. A kapcsolót követő viselkedésváltozás bizonyíték; az oldal, amely végül betöltődik, nem az.

Ha a kapcsoló megoldja, döntse el, miért

Három feltétel ugyanazt a tünetet okozza, és különböző válaszokat kíván. Az útvonal teljesen szűrheti az UDP-t, ami a kapcsolót teszi helyes tartós válasszá annak a hálózatnak. Az útvonal engedheti az UDP-t, de eldobhatja a nagy datagramokat, ami az MTU-ra utal, nem a szűrésre. Vagy az útvonal lehet annyira veszteséges, hogy az UDP láb rosszabbul teljesít a TCP-nél, ami kapacitásdöntés, nem elérhetőségi döntés.

Különböztesse meg őket, mielőtt megoldást dokumentál. A szűrés minden csomagméretnél fennmarad, az MTU-problémák csak egy küszöb felett jelennek meg, a veszteség pedig újraküldésként és változó késleltetésként mutatkozik, nem tiszta akadásként. Minden teszt szűkíti az okot anélkül, hogy az ügyfél konfigurációját módosítaná.

Ellenőrizze a csomagméretet, mielőtt megtartaná a megoldást

Ha a méret az ok, az alagút interfésze olyan csomagokat fogad, amelyeket az útvonal nem tud továbbítani, és a probléma bármely átvitelen visszatér, amint a hasznos teher nő. Hasonlítsa össze az interfészeket: ip link show tun0 a gazdagépen, majd docker network inspect bridge a hálózati beállításokban rögzített MTU kiolvasásához. A 1500 bájton maradó konténerhíd egy kevesebbet vivő alagút alatt a szokásos lelet.

Szondázzon felfelé egy ismert jó mérettől egy töredezést tiltó teszttel az alagúton belül, majd csökkentse a konténerhálózat MTU-ját, vagy szorítsa be a TCP MSS-t az alagúton. Bármelyik javítás gyakran újra használhatóvá teszi az UDP útvonalat, és megszünteti a kapcsoló szükségességét, ami jobb eredmény, ha nem a szűrés az ok.

Döntse el, mit hajlandó felcserélni

Kikapcsolt adatcsatornával az alagút a terhét TCP-kapcsolaton belül viszi. Tiszta útvonalon ez csak lassabb; veszteségesen egyetlen elveszett szegmens késleltet mindent mögötte, és a külső újraküldés verseng a belsővel. Ez a csere interaktív fejlesztéshez és kis API-hívásokhoz illik, nagy átvitelekhez vagy mobil linken át tartó hosszú munkamenetekhez viszont rosszul.

Bármelyik lehetőséget választja, jegyezze fel, melyik átvitelt használta végül az alagút, és miért. Az a konténer, amely csendben egy hónapokkal korábban hozzáadott kapcsolótól függ, a következő kiesés, és aki hibakeresni fogja, nem fogja tudni, hogy a kapcsoló a szűrés megkerülése volt-e vagy egy MTU-kísérlet maradéka.