Ping přes VPN funguje, ale web zamrzne: zkontrolujte velikost

Odpovědi echa přicházejí, vzdálená plocha funguje a prohlížeč zůstává na prázdné stránce, dokud to nevzdá. Tomuto vzorci odpovídají dvě vysvětlení a nejde o varianty jednoho problému: politika, která službu nikdy nepovolila, nebo pakety, které se přestanou vejít, jakmile přenos naroste. Odpověď echa nevylučuje ani jedno.

Postupujte od nejmenší otázky k největší a zapisujte, co každý krok skutečně prokázal.

Odpověď echa odpovídá na mnohem menší otázku

Odpověď echa říká, že IP zásobník cíle odpověděl na ICMP požadavek z vašeho zdroje. Neříká nic o tom, zda na portu, který potřebujete, existuje TCP posluchač, zda politika tento port povoluje, ani zda cílový host filtruje provoz nezávisle na bráně. Brána, která povolí jednu službu, může jinou zahodit, zatímco oba cíle odpovídají na ping. Čtěte odpověď jako jeden fakt o jednom paketu a jednom směru.

Potvrďte cíl a port služby, než začnete cokoli jiného vykládat. Adresa, kterou jste testovali, a adresa, kterou používá aplikace, jsou někdy různé záznamy, a jméno, které se překládá na dvě adresy, to činí pravděpodobným.

Zjistěte, zda spojení začalo

Spojení okamžitě odmítnuté je odpověď posluchače nebo politiky: něco odpovědělo a řeklo ne. Spojení, které se otevře a pak se zasekne, když se data začnou pohybovat, ukazuje na velikost. Spojení, které vůbec nedokončí handshake, obvykle souvisí s politikou nebo směrováním a vypadá jako vypršení časového limitu, nikoli jako odmítnutí.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Zapište, který z těch tří případů jste pozorovali, než sáhnete na nastavení MTU. Změna velikosti tunelu kvůli opravě odmítnutého spojení tu změnu promrhá a skutečnou příčinu na čas skryje.

Změřte velikost uvedeným číslem

Když se zaseknutí objeví pod zátěží, otestujte jednu velikost paketu s nastaveným bitem zákazu fragmentace a uveďte aritmetiku, aby výsledek něco znamenal. V Linuxu s iputils vytvoří užitečné zatížení 1392 bajtů plus 8bajtová hlavička ICMP a 20bajtová hlavička IPv4 vnitřní paket přesně 1420 bajtů. Uveďte tuto aritmetiku v tiketu, protože holý ping, který dorazí k bráně, o aplikaci nic nedokazuje.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Obě sondy jsou měřicí body, nikoli doporučení velikosti tunelu. Pokud se ICMP kdekoli na cestě filtruje, vypršení časového limitu vám o velikosti nic neřekne, protože filtrování a příliš velký paket vypadají z pohledu klienta stejně. Úspěch také nic neříká o opačném směru ani o jiném cíli.

Započítejte vnější cestu

Zapouzdření přidává vlastní hlavičky, takže paket na drátě je větší než paket, který jste změřili uvnitř tunelu. Právě mezera mezi nimi umožňuje současně fungující malý požadavek a selhávající velký.

Zjišťování MTU cesty v IPv4 závisí na zpětné vazbě o paketech, které nelze předat bez fragmentace, a IPv6 používá zprávy Packet Too Big. Specifikace IPv4 tento mechanismus popisuje. Filtrování zpětné vazby ničí schopnost odesílatele učit se a nechává ho znovu odesílat pakety, které se nikdy nevejdou. Proto fungující malý požadavek a selhávající velký tak pohodlně koexistují.

Změňte jedno číslo a aplikaci otestujte znovu

Snižte MTU tunelu nebo omezujte maximální velikost segmentu pro TCP a potom zopakujte původní test aplikace, nikoli sondu. Sonda, která po změně uspěje, a aplikace, která stále visí, jsou jiný problém podobného tvaru a rozliší je jen test aplikace.

Uchovejte aritmetiku v záznamu o změně: naměřenou velikost, předpokládanou režii a hodnotu, kterou jste nastavili. Kdokoli to později zkontroluje, může předpoklad ověřit, místo aby ho znovu odvozoval ze snímku obrazovky s pingem.

Pokud aplikace funguje při každé velikosti, kterou jste vyzkoušeli, přestaňte ladit čísla a podívejte se na politiku, která odděluje fungující službu od selhávající.