Zašto blokiranje celokupnog ICMP-a kvari ispravnu VPN stazu

Tunel koji prođe autentikaciju, prenese ping i zatim se zaglavi na prvom velikom prenosu 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. Redosled je važan: izmerite gde je granica veličine, pa suzite pravilo koje je progutalo izveštaj.

Šta ICMP zapravo nosi na ovoj stazi

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

Obe 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 spisku pravila, ali se na mreži ponašaju veoma različito. Druga može pretvoriti ispravno dimenzionisan tunel u jednosmernu stazu za sve veće od najmanje veze u lancu.

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

Kvar zavisi od veličine

Pitajte da li kvar korelira sa veličinom paketa. Stranica za prijavu, DNS upit i kratak API poziv prolaze, dok se prenos datoteke, veliki odgovor ili preuzimanje slike zaglavljuju. Taj obrazac ukazuje na ograničenje veličine negde između dva kraja, a ne na autentikaciju ili rutiranje. Uspešan mali ping gotovo ništa ne govori o tome gde je ta granica.

Unutar tunela treba razmotriti dva sloja: paket korisnog tereta i spoljašnji enkapsulirani paket. Unutrašnji pošiljalac se može ponašati ispravno dok je spoljašnja staza manja nego što tunel pretpostavlja, zato su i sopstveno MTU podešavanje tunela i fizička veza ispod njega važni.

Izmerite pre uređivanja pravila

Proverite sa 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 uspe sa 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 izveštaj. Ako proba ne uspe tiho, bez greške i bez odgovora, poruka se verovatno odbacuje, a ne dostavlja, i pravilo je osumnjičeno.

Suzite pravilo, pa ponovo testirajte zadatak

Ispravka treba da dozvoli određene kontrolne poruke, a ne ceo protokol. Na hostu sa iptablesom oblik je dozvola 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 stazi ne trebaju. Zatim ponovo testirajte prenos koji je izvorno neuspeo, iz nove veze, i potvrdite da brojači pravila pokazuju dolazak poruka.

Ako se veliki prenos i dalje zaglavljuje nakon što su poruke dozvoljene, preostalo ograničenje je drugde: previsoko postavljen MTU tunela, proxy koji prepisuje pakete ili posredni uređaj koji odbacuje umesto da izvesti. ICMP pravilo je bilo neophodno, ali ne i dovoljno.