Proč úplné zablokování ICMP rozbíjí funkční cestu VPN

Tunel, který projde autentizací, přenese ping a pak se zasekne na prvním velkém přenosu, je klasickým příznakem chybějící zprávy ICMP, nikoli rozbité VPN. Odesílatel se nikdy nedozví, že paket byl příliš velký, opakuje stejnou velikost a aplikace čeká. Oprava je rozhodnutí o politice firewallu, ne přeinstalace klienta. Na pořadí záleží: změřte, kde leží hranice velikosti, a pak zúžte pravidlo, které zprávu spolklo.

Co ICMP na této cestě skutečně nese

Zjišťování MTU cesty IPv4 spoléhá na to, že router oznámí, že paket s nastaveným bitem don't-fragment nebylo možné předat dál. Toto oznámení je zpráva ICMP Fragmentation Needed a bez něj nemá odesílatel důvod zmenšovat velikost segmentu. IPv6 je přísnější: routery v tranzitu nefragmentují, takže zpráva ICMPv6 Packet Too Big je jediný signál, který přiměje odesílatele se zmenšit.

Obě zprávy jsou zpětnou vazbou řídicí roviny a ani jedna není diagnostické echo. Politika, která blokuje ping, a politika, která blokuje veškeré ICMP, vypadají v seznamu pravidel podobně, ale v síti se chovají velmi odlišně. Druhá může změnit správně dimenzovaný tunel v jednosměrnou cestu pro cokoli většího než nejmenší článek řetězu.

Některé transporty provádějí vlastní zjišťování pomocí sondovacích paketů, jak popisuje RFC 4821, a jsou na této zpětné vazbě méně závislé. To je argument pro ověření, který transport používáte, ne pro předpoklad, že každý tunel je imunní.

Selhání závisí na velikosti

Ptejte se, zda selhání souvisí s velikostí paketu. Přihlašovací stránka, dotaz DNS a krátké volání API projdou, zatímco nahrání souboru, velká odpověď nebo stažení obrázku se zaseknou. Tento vzorec ukazuje na limit velikosti někde mezi oběma konci, ne na autentizaci či směrování. Úspěšný malý ping neříká téměř nic o tom, kde tato hranice leží.

Uvnitř tunelu je třeba zvážit dvě vrstvy: paket užitečného zatížení a vnější zapouzdřený paket. Vnitřní odesílatel se může chovat správně, zatímco vnější cesta je menší, než tunel předpokládá, a proto záleží jak na vlastním nastavení MTU tunelu, tak na fyzickém spoji pod ním.

Změřte, než začnete upravovat pravidla

Sondáž proveďte s bitem don't-fragment a velikostí zatížení, kterou si zvolíte, z nefunkčního klienta směrem k chráněné adrese:

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

Zatížení 1472 bajtů plus 28 bajtů hlaviček tvoří paket o velikosti 1500 bajtů. Pokud velká sonda selže s chybou fragmentace a menší projde, našli jste hranici; upravte ji o režii tunelu a opakujte, dokud funkční velikost není stabilní.

Poté ověřte, že mezeru tvoří sama zpráva. Pokud sonda selže tiše, bez chyby a bez odpovědi, zpráva se pravděpodobně zahazuje, místo aby byla doručena, a podezřelé je pravidlo.

Zúžte pravidlo a poté úlohu znovu otestujte

Oprava má povolit konkrétní řídicí zprávy, ne celý protokol. Na hostiteli s iptables má tvar povolení pro konkrétní typ; přizpůsobte syntaxi tomu, co na vaší platformě 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

Nechte odpovědi na echo zablokované, pokud je to místní politika, protože cesta je nepotřebuje. Poté znovu otestujte přenos, který původně selhal, z nového připojení, a ověřte, že čítače pravidel ukazují přicházející zprávy.

Pokud se velký přenos zasekává i poté, co jsou zprávy povoleny, zbývající limit je jinde: příliš vysoko nastavené MTU tunelu, proxy, která přepisuje pakety, nebo mezilehlý prvek, který zahazuje místo aby hlásil. Pravidlo ICMP bylo nutné, ne dostačující.