Prečo úplné zablokovanie ICMP rozbíja funkčnú cestu VPN

Tunel, ktorý prejde autentifikáciou, prenesie ping a potom sa zasekne na prvom veľkom prenose, je klasickým príznakom chýbajúcej správy ICMP, nie pokazeného VPN. Odosielateľ sa nikdy nedozvie, že paket bol príliš veľký, opakuje rovnakú veľkosť a aplikácia čaká. Oprava je rozhodnutie o politike firewallu, nie preinštalovanie klienta. Na poradí záleží: zmerajte, kde leží hranica veľkosti, a potom zúžte pravidlo, ktoré správu prehltlo.

Čo ICMP na tejto ceste skutočne nesie

Zisťovanie MTU cesty IPv4 spolieha na to, že smerovač oznámi, že paket s nastaveným bitom don't-fragment nebolo možné preposlať. Toto oznámenie je správa ICMP Fragmentation Needed a bez neho odosielateľ nemá dôvod zmenšovať veľkosť segmentu. IPv6 je prísnejšie: smerovače v tranzite nefragmentujú, takže správa ICMPv6 Packet Too Big je jediný signál, ktorý prinúti odosielateľa zmenšiť sa.

Obe správy sú spätnou väzbou riadiacej roviny a ani jedna nie je diagnostické echo. Politika, ktorá blokuje ping, a politika, ktorá blokuje všetko ICMP, vyzerajú v zozname pravidiel podobne, ale v sieti sa správajú veľmi odlišne. Druhá môže zmeniť správne dimenzovaný tunel na jednosmernú cestu pre všetko väčšie než najmenší článok reťaze.

Niektoré transporty vykonávajú vlastné zisťovanie pomocou sondovacích paketov, ako opisuje RFC 4821, a sú menej závislé od tejto spätnej väzby. To je argument pre overenie, ktorý transport používate, nie pre predpoklad, že každý tunel je imúnny.

Zlyhanie závisí od veľkosti

Pýtajte sa, či zlyhanie súvisí s veľkosťou paketu. Prihlasovacia stránka, dotaz DNS a krátke volanie API prejdú, zatiaľ čo nahrávanie súboru, veľká odpoveď alebo stiahnutie obrázka sa zaseknú. Tento vzor ukazuje na limit veľkosti niekde medzi oboma koncami, nie na autentifikáciu či smerovanie. Úspešný malý ping nehovorí takmer nič o tom, kde táto hranica leží.

Vo vnútri tunela treba zvážiť dve vrstvy: paket užitočného zaťaženia a vonkajší zapuzdrený paket. Vnútorný odosielateľ sa môže správať správne, zatiaľ čo vonkajšia cesta je menšia, než tunel predpokladá, preto záleží na vlastnom nastavení MTU tunela aj na fyzickom spojení pod ním.

Zmerajte, kým začnete upravovať pravidlá

Sondážte s bitom don't-fragment a veľkosťou zaťaženia, ktorú si zvolíte, z nefunkčného klienta smerom k chránenej adrese:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

Zaťaženie 1472 bajtov plus 28 bajtov hlavičiek tvorí paket s veľkosťou 1500 bajtov. Ak veľká sonda zlyhá s chybou fragmentácie a menšia prejde, našli ste hranicu; zohľadnite réžiu tunela a opakujte, kým funkčná veľkosť nebude stabilná.

Potom overte, že medzeru tvorí samotná správa. Ak sonda zlyhá potichu, bez chyby a bez odpovede, správa sa pravdepodobne zahadzuje, a nie doručuje, a podozrivé je pravidlo.

Zúžte pravidlo a potom úlohu znova otestujte

Oprava má povoliť konkrétne riadiace správy, nie celý protokol. Na hostiteľovi s iptables má tvar povolenia pre konkrétny typ; prispôsobte syntax tomu, čo na vašej platforme spravuje firewall:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Nechajte odpovede na echo zablokované, ak je to miestna politika, pretože cesta ich nepotrebuje. Potom znova otestujte prenos, ktorý pôvodne zlyhal, z nového pripojenia, a overte, že počítadlá pravidla ukazujú prichádzajúce správy.

Ak sa veľký prenos zasekáva aj po povolení správ, zostávajúci limit je inde: príliš vysoko nastavené MTU tunela, proxy prepisujúca pakety alebo medziľahlý prvok, ktorý zahadzuje namiesto hlásenia. Pravidlo ICMP bolo nevyhnutné, nie postačujúce.