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šiljatelj nikada ne sazna da je paket bio prevelik, ponavlja istu veličinu, a aplikacija čeka. Popravak je odluka o politici vatrozida, ne ponovna instalacija klijenta. Redoslijed je važan: izmjerite gdje se nalazi granica veličine, pa suzite pravilo koje je progutalo izvještaj.

Što ICMP zapravo nosi na ovoj putanji

IPv4 otkrivanje MTU putanje oslanja se na to da usmjerivač 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šiljatelj nema razloga smanjiti veličinu svog segmenta. IPv6 je stroži: usmjerivači ne fragmentiraju u tranzitu, pa je ICMPv6 Packet Too Big poruka jedini signal koji tjera pošiljatelja da se smanji.

Obje poruke su povratna informacija kontrolne ravnine i nijedna nije dijagnostički eho. Politika koja blokira ping i politika koja blokira sav ICMP izgledaju slično na popisu 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 ovise o ovoj povratnoj informaciji. 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. Unutarnji pošiljatelj 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

Ispravak 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 vatrozidom 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.