Zašto potpuno blokiranje ICMP-a kvari ispravnu VPN putanju

Tunel koji prođe autentifikaciju, prenese ping i zatim se zaglavi na prvom velikom prijenosu klasičan je znak nedostajuće ICMP poruke, a ne pokvarenog VPN-a. Pošiljalac nikada ne sazna da je paket bio prevelik, ponavlja istu veličinu, a aplikacija čeka. Popravka je odluka o politici zaštitnog zida, ne ponovna instalacija klijenta. Redoslijed je važan: izmjerite gdje se nalazi granica veličine, pa suzite pravilo koje je progutalo izvještaj.

Šta ICMP zapravo nosi na ovoj putanji

IPv4 otkrivanje MTU putanje oslanja se na to da ruter prijavi da paket s postavljenim don't-fragment bitom nije mogao biti proslijeđen. Taj izvještaj je ICMP Fragmentation Needed poruka, a bez nje pošiljalac nema razloga smanjiti veličinu svog segmenta. IPv6 je stroži: ruteri ne fragmentiraju u tranzitu, pa je ICMPv6 Packet Too Big poruka jedini signal koji tjera pošiljaoca da se smanji.

Obje poruke su povratna informacija kontrolne ravni i nijedna nije dijagnostički eho. Politika koja blokira ping i politika koja blokira sav ICMP izgledaju slično na listi pravila, a na mreži se ponašaju vrlo različito. Druga može pretvoriti ispravno dimenzioniran tunel u jednosmjernu putanju za sve veće od najmanje veze u lancu.

Neki transporti sami provode otkrivanje probnim paketima, kako opisuje RFC 4821, i oni manje zavise od ove povratne informacije. To je argument da provjerite koji transport koristite, a ne da pretpostavite da je svaki tunel imun.

Kvar zavisi od veličine

Pitajte korelira li kvar s veličinom paketa. Stranica za prijavu, DNS upit i kratak API poziv prolaze, dok se prijenos datoteke, veliki odgovor ili preuzimanje slike zaglavljuju. Taj obrazac upućuje na ograničenje veličine negdje između dva kraja, a ne na autentifikaciju ili usmjeravanje. Uspješan mali ping gotovo ništa ne govori o tome gdje je ta granica.

Unutar tunela treba razmotriti dva sloja: paket korisnog tereta i vanjski enkapsulirani paket. Unutrašnji pošiljalac može se ponašati ispravno dok je vanjska putanja manja nego što tunel pretpostavlja, zato su i vlastita MTU postavka tunela i fizička veza ispod nje važne.

Izmjerite prije uređivanja pravila

Provjerite s don't-fragment bitom i veličinom tereta koju sami odaberete, od neispravnog klijenta prema zaštićenoj adresi:

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

Teret od 1472 bajta plus 28 bajtova zaglavlja čini paket od 1500 bajtova. Ako velika proba ne uspije s greškom fragmentacije, a manja prođe, pronašli ste granicu; prilagodite za dodatni trošak tunela i ponavljajte dok radna veličina ne postane stabilna.

Zatim potvrdite da je praznina sam izvještaj. Ako proba ne uspije tiho, bez greške i bez odgovora, poruka se vjerojatno odbacuje, a ne dostavlja, i pravilo je osumnjičeno.

Suzite pravilo, pa ponovno testirajte zadatak

Ispravka treba dopustiti određene kontrolne poruke, a ne cijeli protokol. Na hostu s iptablesom oblik je dopuštanje za određeni tip; prilagodite sintaksu onome što upravlja zaštitnim zidom na vašoj platformi:

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

Ostavite eho odgovore blokiranima ako je to lokalna politika, jer putanji ne trebaju. Zatim ponovno testirajte prijenos koji je izvorno neuspio, iz nove veze, i potvrdite da brojači pravila pokazuju dolazak poruka.

Ako se veliki prijenos i dalje zaglavljuje nakon što su poruke dopuštene, preostalo ograničenje je drugdje: previsoko postavljen MTU tunela, proxy koji prepisuje pakete ili posredni uređaj koji odbacuje umjesto da izvijesti. ICMP pravilo bilo je nužno, ali ne i dovoljno.