Dlaczego blokowanie całego ICMP psuje działającą ścieżkę VPN

Tunel, który przechodzi uwierzytelnienie, przenosi ping i potem zawiesza się przy pierwszym dużym transferze, jest klasycznym objawem brakującego komunikatu ICMP, a nie zepsutego VPN. Nadawca nigdy nie dowiaduje się, że pakiet był za duży, powtarza ten sam rozmiar, a aplikacja czeka. Naprawa tego jest decyzją o polityce zapory, nie reinstalacją klienta. Kolejność ma znaczenie: zmierz, gdzie leży granica rozmiaru, a potem zawęź regułę, która połknęła raport.

Co ICMP naprawdę przenosi na tej ścieżce

Wykrywanie MTU ścieżki IPv4 opiera się na tym, że router zgłasza, iż pakietu z ustawionym bitem don't-fragment nie dało się przesłać dalej. Ten raport to komunikat ICMP Fragmentation Needed, a bez niego nadawca nie ma powodu zmniejszać rozmiaru segmentu. IPv6 jest surowszy: routery nie fragmentują w tranzycie, więc komunikat ICMPv6 Packet Too Big jest jedynym sygnałem, który każe nadawcy się skurczyć.

Oba komunikaty są informacją zwrotną płaszczyzny sterowania i żaden nie jest echem diagnostycznym. Polityka blokująca ping i polityka blokująca cały ICMP wyglądają podobnie na liście reguł, ale w sieci zachowują się bardzo różnie. Druga może zamienić poprawnie zwymiarowany tunel w ścieżkę jednokierunkową dla wszystkiego, co większe od najmniejszego ogniwa łańcucha.

Niektóre transporty realizują własne wykrywanie pakietami sondującymi, jak opisuje RFC 4821, i są mniej zależne od tej informacji zwrotnej. To argument za sprawdzeniem, jaki transport uruchamiasz, a nie za założeniem, że każdy tunel jest odporny.

Awaria zależy od rozmiaru

Zapytaj, czy awaria koreluje z rozmiarem pakietu. Strona logowania, zapytanie DNS i krótkie wywołanie API przechodzą, podczas gdy wysyłanie pliku, duża odpowiedź lub pobieranie obrazu się zawieszają. Ten wzorzec wskazuje na limit rozmiaru gdzieś między dwoma końcami, a nie na uwierzytelnianie czy trasowanie. Udany mały ping nie mówi prawie nic o tym, gdzie leży ta granica.

Wewnątrz tunelu trzeba rozważyć dwie warstwy: pakiet ładunku i zewnętrzny pakiet enkapsulowany. Wewnętrzny nadawca może zachowywać się poprawnie, podczas gdy zewnętrzna ścieżka jest mniejsza, niż zakłada tunel, dlatego znaczenie ma zarówno własne ustawienie MTU tunelu, jak i łącze fizyczne pod nim.

Zmierz, zanim zaczniesz edytować reguły

Sondować bitem don't-fragment i wybranym przez siebie rozmiarem ładunku, od uszkodzonego klienta w stronę adresu chronionego:

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

Ładunek 1472 bajtów plus 28 bajtów nagłówków to pakiet 1500 bajtów. Jeśli duża sonda zawiedzie z błędem fragmentacji, a mniejsza przejdzie, znalazłeś granicę; uwzględnij narzut tunelu i powtarzaj, aż działający rozmiar będzie stabilny.

Następnie potwierdź, że luka to sam raport. Jeśli sonda zawodzi po cichu, bez błędu i bez odpowiedzi, komunikat jest prawdopodobnie odrzucany, a nie dostarczany, i podejrzaną jest reguła.

Zawęź regułę, a potem ponownie przetestuj zadanie

Poprawka powinna zezwalać na konkretne komunikaty sterujące, a nie cały protokół. Na hoście z iptables formą jest zezwolenie dla konkretnego typu; dostosuj składnię do tego, co zarządza zaporą na twojej platformie:

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

Pozostaw odpowiedzi echa zablokowane, jeśli taka jest polityka lokalna, ponieważ ścieżka ich nie potrzebuje. Następnie ponownie przetestuj transfer, który początkowo zawiódł, z nowego połączenia, i potwierdź, że liczniki reguły pokazują nadchodzące komunikaty.

Jeśli duży transfer nadal się zawiesza po zezwoleniu na komunikaty, pozostały limit jest gdzie indziej: zbyt wysoko ustawione MTU tunelu, proxy przepisujące pakiety albo urządzenie pośrednie, które odrzuca zamiast raportować. Reguła ICMP była konieczna, ale niewystarczająca.