Ping przez VPN działa, ale strona się zawiesza: sprawdź rozmiar

Odpowiedzi echa przychodzą, pulpit zdalny działa, a przeglądarka zostaje na pustej stronie, aż się podda. Do tego wzorca pasują dwa wyjaśnienia i nie są to warianty jednego problemu: polityka, która nigdy nie zezwoliła na usługę, albo pakiety, które przestają się mieścić, gdy transfer rośnie. Odpowiedź echa nie wyklucza żadnego z nich.

Przejdź od najmniejszego pytania do największego i zapisz, co każdy krok naprawdę udowodnił.

Odpowiedź echa odpowiada na znacznie mniejsze pytanie

Odpowiedź echa mówi, że stos IP celu odpowiedział na żądanie ICMP z twojego źródła. Nie mówi nic o tym, czy na potrzebnym porcie istnieje nasłuch TCP, czy polityka zezwala na ten port ani czy host docelowy filtruje ruch niezależnie od bramy. Brama, która zezwala na jedną usługę, może odrzucić inną, podczas gdy oba cele odpowiadają na ping. Czytaj odpowiedź jako jeden fakt o jednym pakiecie i jednym kierunku.

Potwierdź cel i port usługi, zanim zinterpretujesz cokolwiek innego. Adres, który testowałeś, i adres używany przez aplikację bywają różnymi rekordami, a nazwa rozwiązująca się na dwa adresy czyni to prawdopodobnym.

Ustal, czy połączenie się rozpoczęło

Połączenie odrzucone natychmiast to odpowiedź nasłuchu albo polityki: coś odpowiedziało i powiedziało nie. Połączenie, które się otwiera, a potem zastyga, gdy dane zaczynają płynąć, wskazuje na rozmiar. Połączenie, które w ogóle nie kończy uzgadniania, zwykle wynika z polityki lub routingu i wygląda jak przekroczenie czasu, a nie jak odmowa.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Zapisz, który z tych trzech przypadków zaobserwowałeś, zanim dotkniesz ustawień MTU. Zmiana rozmiaru tunelu, aby naprawić odrzucone połączenie, marnuje tę zmianę i na jakiś czas ukrywa prawdziwą przyczynę.

Zmierz rozmiar podaną liczbą

Gdy zawieszenie pojawia się pod obciążeniem, przetestuj jeden rozmiar pakietu z ustawionym bitem zakazu fragmentacji i podaj arytmetykę, żeby wynik coś znaczył. W Linuksie z iputils ładunek 1392 bajtów plus nagłówek ICMP 8 bajtów i nagłówek IPv4 20 bajtów daje pakiet wewnętrzny dokładnie 1420 bajtów. Podaj tę arytmetykę w zgłoszeniu, bo goły ping, który dociera do bramy, niczego nie dowodzi o aplikacji.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Obie próby to punkty pomiarowe, a nie zalecenia rozmiaru tunelu. Jeśli ICMP jest filtrowany gdziekolwiek na ścieżce, przekroczenie czasu nic nie mówi o rozmiarze, bo filtrowanie i zbyt duży pakiet wyglądają z punktu widzenia klienta tak samo. Sukces też nic nie mówi o kierunku odwrotnym ani o innym celu.

Uwzględnij ścieżkę zewnętrzną

Enkapsulacja dodaje własne nagłówki, więc pakiet na drucie jest większy niż pakiet zmierzony wewnątrz tunelu. Właśnie różnica między nimi umożliwia jednoczesne istnienie działającego małego żądania i zawodzącego dużego.

Wykrywanie MTU ścieżki w IPv4 zależy od informacji zwrotnej o pakietach, których nie można przekazać bez fragmentacji, a IPv6 używa komunikatów Packet Too Big. Specyfikacja IPv4 opisuje ten mechanizm. Filtrowanie informacji zwrotnej psuje zdolność nadawcy do uczenia się i pozostawia go przy ponownym wysyłaniu pakietów, które nigdy się nie zmieszczą. Dlatego działające małe żądanie i zawodzące duże tak wygodnie współistnieją.

Zmień jedną liczbę i przetestuj aplikację ponownie

Obniż MTU tunelu albo ogranicz maksymalny rozmiar segmentu dla TCP, a potem powtórz pierwotny test aplikacji zamiast próby. Próba, która po zmianie się udaje, i aplikacja, która nadal się zawiesza, to inny problem o podobnym kształcie, i tylko test aplikacji je rozróżnia.

Zachowaj arytmetykę w zapisie zmiany: zmierzony rozmiar, założony narzut i ustawioną wartość. Ktoś, kto to później przejrzy, może sprawdzić założenie zamiast wyprowadzać je od nowa ze zrzutu ekranu z pingiem.

Jeśli aplikacja działa przy każdym wypróbowanym rozmiarze, przestań dostrajać liczby i spójrz na politykę, która oddziela działającą usługę od zawodzącej.