Ping cez VPN funguje, ale stránka zamrzne: skontrolujte veľkosť

Odpovede echa prichádzajú, vzdialená plocha funguje a prehliadač zostáva na prázdnej stránke, kým to nevzdá. Tomuto vzoru zodpovedajú dve vysvetlenia a nejde o varianty jedného problému: politika, ktorá službu nikdy nepovolila, alebo pakety, ktoré sa prestanú zmestiť, keď prenos narastie. Odpoveď echa nevylučuje ani jedno.

Postupujte od najmenšej otázky k najväčšej a zapisujte, čo každý krok skutočne dokázal.

Odpoveď echa odpovedá na oveľa menšiu otázku

Odpoveď echa hovorí, že IP zásobník cieľa odpovedal na ICMP požiadavku z vášho zdroja. Nehovorí nič o tom, či na porte, ktorý potrebujete, existuje TCP poslucháč, či politika tento port povoľuje, ani či cieľový host filtruje prevádzku nezávisle od brány. Brána, ktorá povoľuje jednu službu, môže inú zahodiť, hoci oba ciele odpovedajú na ping. Čítajte odpoveď ako jeden fakt o jednom pakete a jednom smere.

Potvrďte cieľ a port služby, kým začnete čokoľvek iné interpretovať. Adresa, ktorú ste testovali, a adresa, ktorú používa aplikácia, sú niekedy rôzne záznamy, a meno, ktoré sa prekladá na dve adresy, to robí pravdepodobným.

Zistite, či spojenie začalo

Spojenie okamžite odmietnuté je odpoveď poslucháča alebo politiky: niečo odpovedalo a povedalo nie. Spojenie, ktoré sa otvorí a potom sa zasekne, keď sa údaje začnú pohybovať, ukazuje na veľkosť. Spojenie, ktoré vôbec nedokončí handshake, zvyčajne súvisí s politikou alebo smerovaním a vyzerá ako vypršanie času, nie ako odmietnutie.

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

Zapíšte, ktorý z tých troch prípadov ste pozorovali, kým sa dotknete nastavení MTU. Zmena veľkosti tunela kvôli oprave odmietnutého spojenia tú zmenu premrhá a na čas skryje skutočnú príčinu.

Zmerajte veľkosť uvedeným číslom

Keď sa zaseknutie objaví pod záťažou, otestujte jednu veľkosť paketu s nastaveným bitom zákazu fragmentácie a uveďte aritmetiku, aby výsledok niečo znamenal. V Linuxe s iputils vytvorí užitočné zaťaženie 1392 bajtov plus 8-bajtová hlavička ICMP a 20-bajtová hlavička IPv4 vnútorný paket presne 1420 bajtov. Uveďte túto aritmetiku v tikete, pretože holý ping, ktorý dorazí k bráne, o aplikácii nič nedokazuje.

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

Obe sondy sú meracie body, nie odporúčania veľkosti tunela. Ak sa ICMP kdekoľvek na ceste filtruje, vypršanie času vám o veľkosti nič nepovie, pretože filtrovanie a príliš veľký paket vyzerajú z pohľadu klienta rovnako. Úspech tiež nič nehovorí o opačnom smere ani o inom cieli.

Započítajte vonkajšiu cestu

Zapuzdrenie pridáva vlastné hlavičky, takže paket na drôte je väčší ako paket, ktorý ste namerali vnútri tunela. Práve medzera medzi nimi umožňuje súčasne fungujúcu malú požiadavku a zlyhávajúcu veľkú.

Zisťovanie MTU cesty v IPv4 závisí od spätnej väzby o paketoch, ktoré nie je možné preposlať bez fragmentácie, a IPv6 používa správy Packet Too Big. Špecifikácia IPv4 tento mechanizmus opisuje. Filtrovanie spätnej väzby ničí schopnosť odosielateľa učiť sa a necháva ho znova odosielať pakety, ktoré sa nikdy nezmestia. Preto fungujúca malá požiadavka a zlyhávajúca veľká tak pohodlne koexistujú.

Zmeňte jedno číslo a aplikáciu otestujte znova

Znížte MTU tunela alebo obmedzte maximálnu veľkosť segmentu pre TCP, potom zopakujte pôvodný test aplikácie namiesto sondy. Sonda, ktorá po zmene uspeje, a aplikácia, ktorá stále visí, sú iný problém podobného tvaru, a rozlíši ich len test aplikácie.

Uchovajte aritmetiku v zázname o zmene: nameranú veľkosť, predpokladanú réžiu a hodnotu, ktorú ste nastavili. Ktokoľvek to neskôr skontroluje, môže predpoklad overiť namiesto toho, aby ho znova odvodzoval zo snímky obrazovky s pingom.

Ak aplikácia funguje pri každej vyskúšanej veľkosti, prestaňte ladiť čísla a pozrite sa na politiku, ktorá oddeľuje fungujúcu službu od zlyhávajúcej.