Proč se stránky OpenConnect zaseknou, dokud nesnížíte MTU tunelu

Přihlášení projde, úvodní stránka portálu se vykreslí a pak widget na nástěnce nebo sestava zůstane na waiting for host, dokud to prohlížeč nevzdá. Veřejné weby se celou dobu načítají normálně a žádné přihlašovací údaje se nezměnily. To, že malé odpovědi dorazí, zatímco velké váznou, je podpis stropu velikosti paketu, nikoli přístupového pravidla. Potvrďte tento výklad, než v profilu změníte cokoli dalšího.

Oddělte problém velikosti od problému politiky

Začněte vyloučením odmítnutí. Kdyby vás brána odmítla, spojení by selhalo hned, místo aby stránku načetlo napůl. Tunel, který se naváže a pak váznou jen větší přenosy, vám říká, že vnější cesta neunese vnitřní paket.

Mechanismem je zapouzdření. Každý vnitřní paket dostane hlavičky tunelu, takže užitečné zatížení, které se vejde do fyzického spoje, se stane vnějším paketem, který se už nevejde, a vše, co nese bit do-not-fragment, se zahodí bez odpovědi, kterou by prohlížeč mohl vyložit.

Změřte strop pomocí DF sond

Strop změřte, místo abyste ho hádali. Posílejte sondy, které odmítají fragmentaci, a snižujte zatížení po krocích, dokud se nevrátí odpověď, počínaje příkazem jako ping -M do -s 1472 host. Odpověď, která si stěžuje, že je potřeba fragmentace, zatímco je DF nastaveno, znamená, že hodnota je stále příliš vysoká. Opakujte na 1462, pak na 1452, a zastavte se u první velikosti, která odpoví. Číslo si zapište spolu s hostitelem, který jste testovali, protože odpověď patří té cestě, a ne protokolu obecně.

Testujte adresu, na kterou tunel skutečně posílá provoz. Vnější sonda proti veřejnému jménu brány a vnitřní sonda proti internímu serveru měří různé skoky a filtrování ICMP na kterékoli z nich může zdravou cestu vykreslit jako rozbitou.

Aplikujte hodnotu na zařízení tunelu

Výsledek aplikujte na rozhraní, které vytvořil klient, ne na adaptér Wi-Fi. U linuxového klienta to je ip link set dev tun0 mtu 1300 a poté ip link show tun0 pro potvrzení, že se hodnota převzala. Použijte název zařízení, který klient hlásí, protože se liší podle implementace a podle toho, jak byl tunel sestaven.

Snížení MTU tunelu zmenšuje zatížení, které každý paket nese, takže celková propustnost mírně klesne, a to je cena za to, že velké odpovědi nezmizí v černé díře. Menší číslo není automaticky bezpečnější. Změna fyzického adaptéru místo toho rozprostře škodu na každé spojení na tom spoji, zatímco přehnaně velké vnitřní pakety zůstanou stejně velké.

Nejprve použijte vlastní požadavky klienta na MTU

Když volání řídíte vy, klient může o velikost požádat, místo aby byl dodatečně záplatován. --mtu žádá od serveru MTU tunelu a --base-mtu deklaruje MTU podkladové cesty, aby brána mohla odvodit číslo tunelu. Oba jsou to požadavky a příručka klienta neslibuje, že brána některý z nich vyslyší.

Tento rozdíl určuje pořadí práce. Nejprve zkuste požadavek a prohlédněte si rozhraní, které vytvoří, a pak se vraťte k místnímu nastavení zařízení, pokud hodnota, kterou brána zvolila, stále vázne.

Ověřte to přenosem, který selhal, a pak ho zaveďte trvale

Místní změna ip link vydrží, dokud klient tunel znovu nesestaví, což se stane při dalším opětovném připojení nebo obnovení. Umístěte hodnotu tam, kde spojení začíná: obal, který spustí klienta a poté upraví zařízení, jednotka systemd s krokem ExecStartPost, nebo volba klienta, když ji brána přijme. Mějte ji vedle profilu ve verzovacím systému, aby další člověk viděl, proč tam číslo je.

Testujte požadavkem, který selhal, ne úvodní stránkou. Otevřete sestavu, stáhněte přílohu nebo spusťte načtení repozitáře, které se zaseklo, a poznamenejte si přesně, kde se zastaví, pokud se stále zastavuje. Stránka, která se po změně vykreslí, dokazuje málo, protože se vykreslovala i předtím.

Pokud stejný přenos vázne na stejném místě, teorie o MTU není prokázaná. Zachyťte provoz na tunelu a zkontrolujte, která strana přestane odesílat, než číslo znovu změníte, a předchozí hodnotu mějte zapsanou, aby vrácení zůstalo jediným příkazem.