MTU czy MSS? Co naprawdę naprawia zmiana VPN

Pingi przechodzą, duże transfery zawieszają się, a tunel zgłasza, że jest zdrowy. Ktoś obniża MTU interfejsu, ktoś inny ogranicza MSS, i czasami problem znika z powodów, których nikt nie zapisuje. Te dwie liczby opisują różne obiekty, więc zmiana niewłaściwej daje poprawkę, która wygląda jak szczęście. Oto procedura: zidentyfikuj warstwę, zastosuj odpowiednią korektę, a następnie przetestuj na nowym połączeniu.

Dwie liczby, dwa obiekty

MTU należy do łącza lub interfejsu: to największy pakiet, który można przekazać bez dzielenia. MSS należy do TCP: to największa ilość ładunku TCP, jaką może przenieść segment, i wyklucza zarówno nagłówek TCP, jak i IP. Na zwykłym łączu Ethernet z IPv4 MTU 1500 bajtów daje znany MSS 1460 bajtów. Te liczby opisują różne warstwy i są wymieniane przez różne mechanizmy. Łatwo je pomylić, bo obie mierzy się w bajtach i obie są blisko 1500.

Jedna przychodzi jako ustawienie interfejsu. Druga przychodzi jako opcja w segmencie SYN, negocjowana między końcami, które nigdy nie widzą twojego interfejsu.

Gdzie ląduje zewnętrzny narzut

VPN wkłada pakiet wewnętrzny w inny, a pakiet zewnętrzny musi zmieścić się w ścieżce fizycznej. Nagłówki enkapsulacji, zewnętrzny nagłówek IP, nagłówek transportu i dowolny znacznik uwierzytelniania zużywają bajty, których pakiet wewnętrzny nie może użyć. Zostaw interfejs tunelu na 1500, a pakiet zewnętrzny regularnie przekracza to, co ścieżka może przenieść. Gdy ustawiony jest bit 'nie fragmentuj', router go odrzuca i powinien odesłać błąd ICMP; jeśli ten błąd jest filtrowany, nadawca nigdy się o tym nie dowie.

Dlatego awaria wygląda na wybiórczą. Małe żądania kończą się, a wszystko, co wypełnia segment, zastyga, bo odrzucane są tylko duże pakiety. Tunel, który przepuszcza ping, nie jest tunelem, który przenosi dane.

Ograniczanie MSS i gdzie ono działa

Ograniczanie MSS przepisuje wartość w segmencie SYN, gdy przechodzi on przez wybrany punkt, przez co oba końce wybierają mniejszy ładunek, nie wiedząc dlaczego. W Linuksie jest to cel tabeli mangle stosowany przez jawną regułę i musi trafiać w pakiety SYN w kierunku, który chcesz. Ogranicz go do interfejsu tunelu i zakresu adresów, bo szeroka reguła zmienia zachowanie ruchu, który nigdy nie wchodzi do tunelu.

Efekt dotyczy tylko TCP. Aplikacja UDP, sesja QUIC i każdy protokół, który buduje własne datagramy, pozostają nietknięte.

Diagnozuj ze stałą ścieżką

Trzymaj jedną zmienną naraz. Testuj pakietem, którego rozmiar wybierasz sam, i ustaw flagę 'nie fragmentuj', aby jądro zgłosiło wynik, zamiast go ukrywać.

Zapisz, gdzie zaczyna się awaria: wewnątrz tunelu, na interfejsie tunelu czy na ścieżce fizycznej po enkapsulacji. Potem zmień jedną liczbę i powtórz ten sam test, a nie inny. Istniejące połączenia zachowują wynegocjowany MSS, więc zmiana polityki jest widoczna tylko na nowym połączeniu, dlatego strona z pamięci podręcznej niczego nie dowodzi w żadną stronę. Jeśli jedno duże wysyłanie zacznie działać, dowiedziałeś się o tej ścieżce, a nie o każdym protokole na niej.

Czego nie naprawia każda zmiana

Obniżenie MTU interfejsu nie zmienia MSS już ustanowionej sesji. Ograniczanie MSS nie pomaga strumieniowi UDP i nie naprawia ścieżki, na której błędy ICMP są filtrowane tylko w jednym kierunku. Każda zmiana naprawia jedną klasę problemów, a resztę zostawia dokładnie taką, jaka była.

Zapisz, jaką korektę zastosowałeś, gdzie i który test pokazał różnicę, bo inaczej następny inżynier zastosuje obie i straci możliwość powiedzenia, która miała znaczenie. Jeśli ograniczenie jest realne i trwałe, wybierz MTU tunelu, które je odzwierciedla, zamiast ograniczenia, które je ukrywa. Jeśli musisz ograniczać, zostaw regułę zawężoną i skomentowaną, bo niewyjaśniona reguła mangle domyślnie staje się trwała.