Testowanie podejrzanego problemu z MTU w VPN bez zgadywania wartości

Próbowanie kolejnych wartości MTU internetu, aż jedna wyda się szybsza, nie jest testem, lecz poszukiwaniem bez reguły stopu. Skuteczna metoda zmienia jeden kontrolowany warunek rozmiaru i porównuje wynik z tą samą ścieżką. Zacznij od powtarzalnego, nieszkodliwego błędu i zachowaj działającą konfigurację, która pozwala cofnąć eksperyment. Wszystko poniżej zakłada tę dyscyplinę, bo bez niej zostaje liczba, której nie da się obronić.

Ustal ścieżkę, zanim zmienisz liczbę

Zapisz urządzenie, łącze dostępowe, protokół tunelu, punkt końcowy, cel i rodzinę adresów, zanim dotkniesz ustawienia. Te sześć faktów to ścieżka, a sonda skierowana na inną ścieżkę mierzy inny problem. Czynią też wynik powtarzalnym i właśnie to odróżnia test od popołudnia dłubania. Trzymaj notatkę obok terminala, a nie w głowie.

Zacznij od najwęższego testu, do którego masz uprawnienia. Zmiana po stronie serwera dociera do każdego użytkownika tego punktu końcowego, więc należy do końca dochodzenia, nie do początku.

Sonduj rozmiarem, który kontrolujesz

W Linuksie sonda wygląda jak ping -M do -s 1400 host, a w Windows jak ping -f -l 1400 host. W obu przypadkach ustawiasz ładunek, a nie rozmiar pakietu, ponieważ nagłówki IP i ICMP dokładają się na wierzchu.

Przeczytaj dokumentację systemu, który masz przed sobą, zamiast kopiować flagę z wpisu na forum. Wybierz cel, który kontrolujesz, żeby brak odpowiedzi był sygnałem, a nie zagadką. Zapisz dokładne polecenie i dokładny rozmiar w tej samej notatce co ścieżka. Wynik bez rozmiaru to anegdota. Jeśli zmienisz dwie rzeczy w jednym uruchomieniu, nie będziesz wiedział, która dała wynik.

Nieudana sonda nie dowodzi limitu MTU

Odrzucona sonda może oznaczać filtrowanie ICMP, a nie limit rozmiaru, i ten błąd każe ludziom stroić wartość, która nigdy nie była problemem. Porównaj sondę z rzeczywistą aplikacją oraz z komunikatem o błędzie związanym z rozmiarem albo z ograniczonym przechwyceniem, zanim cokolwiek zmienisz. Udane małe pingi też niczego nie dowodzą, bo mogą leżeć wygodnie poniżej limitu. Dwie niezależne obserwacje to minimum, zanim konfiguracja się przesunie.

Jeśli aplikacja zawodzi, a sonda się udaje, masz dowód, że nie jest to prosty limit rozmiaru na tej ścieżce. Zapisz to, bo usuwa całą gałąź możliwych zmian.

Dostosuj jeden parametr, który klient już obsługuje

Zmień ustawienie, które klient dokumentuje dla tego protokołu, i zostaw punkt końcowy oraz cel nietknięte, bo inaczej zmieniłeś dwie rzeczy naraz. Zacisk MSS TCP nie obejmuje każdego obciążenia UDP, dlatego przeglądarka, która zaczyna działać, może zostawić protokół tunelu dokładnie tak samo zepsuty. IPv4 i IPv6 to tutaj osobne ścieżki, bo nagłówki różnią się, zanim zrobi to jakiekolwiek trasowanie.

Przetestuj obie rodziny, jeśli publikujesz obie, bo wynik z jednej nic nie mówi o drugiej. Wartość, która zadziałała na tej ścieżce dziś wieczorem, jest daną, a nie MTU dla całego VPN. Nie awansuj jej na ustawienie globalne na podstawie jednego udanego transferu. Zapisz wartość obok ścieżki, z której pochodzi.

Cofnij, sprawdź i zapisz

Przywróć pierwotną wartość, jeśli porównanie nie wspiera hipotezy. Sprawdź, czy menedżer sieci nie zapisał gdzie indziej trwałego nadpisania, bo tak eksperyment staje się polityką. Połącz się ponownie i wypróbuj zwykłe aplikacje, nie tylko tę, którą testowałeś. Następnie zapisz objaw, efektywną ścieżkę, starą i nową wartość oraz to, jak powtarzalny był wynik.

Zachowaj ten zapis razem z wnioskiem o zmianę, zanim ktokolwiek rozszerzy zmianę. Mechanizm wykrywania MTU ścieżki w RFC 1191 wyjaśnia, dlaczego mniejsza wartość może uratować jedną ścieżkę i nic nie zrobić dla innej, a lista liczb nie zastępuje tego modelu. Test jest skończony, gdy potrafisz nazwać ścieżkę, rozmiar, obserwację i wartość, którą przywróciłeś.