OpenVPN mssfix: dlaczego jeden klient zastyga przy dużych transferach
mssfix przepisuje rozmiar segmentu TCP ogłaszany wewnątrz tunelu. Nie zmienia rozmiaru UDP, a wartość znaczy tylko to, co mówi twoja wersja.
Jeden laptop zastyga przy wysyłaniu przez tunel, podczas gdy każde inne urządzenie na tym samym serwerze nadal działa. Ten wzorzec wskazuje na jedną ścieżkę, a nie na konfigurację serwera, i jest to zwykłe wejście do pytania o mssfix. Opcja może pomóc, ale tylko tym połączeniom TCP, które naprawdę przepisuje. Znajomość jej zasięgu powstrzymuje cię przed zmianą działającego serwera, by ratować jednego klienta.
Co przepisuje opcja
mssfix edytuje maksymalny rozmiar segmentu ogłaszany w uzgadnianiach TCP przechodzących przez tunel, aby strona wysyłająca wybierała segmenty mieszczące się w zapakowanym budżecie. Działa na uzgadnianie, co oznacza, że połączenie otwarte przed zmianą zachowuje wynegocjowaną wartość.
Nie zmniejsza datagramów UDP i nie ustawia MTU tunelu. Dwa różne problemy dają ten sam objaw: nadawca TCP ignorujący limit ścieżki oraz ścieżka, która po cichu odrzuca duże pakiety dowolnego rozmiaru. mssfix zajmuje się pierwszym i nic nie robi dla drugiego.
Ta różnica wyjaśnia rozczarowujące eksperymenty. Ustawienie mniejszej wartości na ścieżce z czarną dziurą zmienia rozmiar segmentu, ale nie następujący po nim odrzut, więc transfer zawodzi w innym punkcie.
Zasięg to TCP wewnątrz tunelu
Przepisywany jest tylko ruch TCP. Sesja QUIC, gra lub aplikacja wysyłająca duże datagramy UDP zachowa własne rozmiary pakietów, a jeśli to właśnie te transfery zastygają, poprawka należy raczej do MTU tunelu lub ścieżki. Przeczytaj, jakiego protokołu używa zawodzący transfer, zanim sięgniesz po opcję TCP, bo niewłaściwa warstwa ma własną poprawkę.
Kierunek też ma znaczenie. Ustawienie klienta wpływa na ruch, który ten klient wysyła do tunelu, podczas gdy serwer obejmuje strumienie przekazywane w stronę klientów. Jeśli zastygają tylko przychodzące pobierania, wartość po stronie klienta to nie cała historia.
Liczba i słowo kluczowe nie są przenośne
Wersja społecznościowa OpenVPN 2.6 przyjmuje opcjonalne słowo kluczowe po wartości. Z mtu liczba opisuje rozmiar pakietu zewnętrznego wraz z nagłówkami IP i UDP; bez niego argument stosuje inną konwencję rozliczeniową. Dlatego wiersz skopiowany między wersjami nie opisuje tego samego budżetu pakietów. Sprawdź stronę podręcznika dostarczaną z kompilacją, którą naprawdę uruchamiasz, a nie poradnik dla innego wydania.
Składnia wygląda tak:
mssfix 1400 mtu
Traktuj 1400 jako symbol zastępczy, a nie zalecenie dla swojej ścieżki. Wyprowadź wartość z zmierzonej ścieżki i faktycznie używanego enkapsulowania, i pamiętaj, że klienci na starszych wersjach lub w innych implementacjach mogą odrzucić lub inaczej zinterpretować słowo kluczowe.
Najpierw potwierdź na jednym kliencie
Zmierz ścieżkę z zawodzącej maszyny, zanim cokolwiek zmienisz. Ładunek, który ścieżka może przenieść bez fragmentacji, to liczba, której szukasz:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1
Pierwsza próba mieści się w pakiecie 1500 bajtów, gdy doda się 28 bajtów nagłówków. Jeśli zawodzi z błędem fragmentacji, a mniejsza się udaje, użyteczny rozmiar jest gdzieś pomiędzy nimi, a narzut tunelu odlicza się od góry.
Następnie powtórz zatrzymany transfer na nowym połączeniu i porównaj. Jeśli jeden klient się poprawia, a pozostałe pozostają nietknięte, znalazłeś zasięg problemu. Jeśli zastygają wszyscy klienci, wartość po stronie serwera jest tą do przejrzenia. Żaden z tych wyników nie uzasadnia zmiany na sprzęcie, który nigdy nie był na zawodzącej ścieżce.