MTU dla trasy w Linuksie: trzy regulatory rozmiaru, jedna trasa
MTU interfejsu, MTU trasy i ograniczenie MSS działają na różnych warstwach. Przypnij budżet do trasy, która wygrywa wyszukiwanie, i zachowaj zmianę odwracalną.
Trzy ustawienia w kliencie Linux brzmią jak „zrób pakiety mniejsze” i działają na różnych warstwach. MTU interfejsu ogranicza każdy pakiet wysyłany przez urządzenie. MTU trasy ogranicza pakiety, które korzystają z tej trasy, i często jest to dokładnie to, czego naprawdę chcesz dla jednego celu VPN. Ograniczenie TCP MSS zmienia to, co negocjują oba końce, i nic nie robi dla UDP.
Trzy regulatory, które wyglądają jak ta sama gałka
Postaw je obok siebie przed wyborem, bo wybór niewłaściwego wiersza wyjaśnia większość porad, które nie działają:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Obniżenie MTU Ethernetu dla całej maszyny to toporna wersja tej poprawki. Działa, ale karze też każdą inną aplikację na hoście, także te, których ścieżki były w porządku. Wartość na trasę wyraża ten sam zamiar bez kosztu ubocznego.
Porównanie dotyczy tylko ruchu, który generuje sam host. Przekazywanie pakietu dla innego klienta wiąże się z jego własną ścieżką i zewnętrznym budżetem tunelu, a metryka trasy na tym hoście nie sięga za tę granicę.
Przypnij budżet do trasy, która wygrywa wyszukiwanie
Przykładowy wpis trasy IPv4 wygląda tak:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380
Czytaj wpis jako opis zamiaru, nie jako wartość do wklejenia. Prefiks, urządzenie i preferowane źródło muszą odpowiadać rzeczywistej konfiguracji, a liczba musi pochodzić z dowodów o enkapsulowanej ścieżce, a nie z wpisu na blogu. MTU trasy ogranicza wewnętrzny pakiet IP, co nie jest tym samym co ładunek TCP 1380 bajtów ani zaszyfrowany pakiet zewnętrzny 1380 bajtów.
Zobacz, gdzie wyszukiwanie naprawdę się rozwiązuje, zanim cokolwiek dodasz. Host z regułami polityki może kierować dany cel przez inną tabelę niż main, a metryka, która istnieje tylko w main , jest niewidoczna dla tego żądania. Porównaj ip -4 route show table all z odpowiedzią z ip route get, łącznie z kontekstem znacznika lub przestrzeni nazw, gdy reguły ich używają. Jeśli oba się nie zgadzają, to tabela, która odpowiedziała, potrzebuje metryki, a nie ta, która wygląda schludniej.
mtu nie jest mtu lock
Domyślnie jądro nadal może aktualizować MTU ścieżki na podstawie informacji zwrotnej ICMP, do tego służy wykrywanie MTU ścieżki. Dodanie lock to zatrzymuje. To inna decyzja, nie mocniejszy sposób zachowania tej samej liczby, a w IPv4 zmienia udokumentowane traktowanie bitu „nie fragmentuj”.
Blokowanie jest rozsądne, gdy zmierzyłeś ścieżkę i chcesz, aby wartość pozostała, cokolwiek przyjdzie. To zły domyślny wybór, gdy sieć wysyła uzasadnioną informację zwrotną o rozmiarze, bo jądro nie może już się dostosować, a błąd przenosi się na inny objaw.
Jeśli ICMP jest gdzieś na ścieżce filtrowany, żadne ustawienie trasy tego nie naprawi. Poprawka należy do filtra, a mniejsze MTU to obejście, które ukrywa prawdziwą usterkę do następnej zmiany ścieżki.
Oprogramowanie tunelu dodaje własne regulatory rozmiaru
OpenVPN- mssfix dostosowuje rozmiar segmentu TCP do swojego udokumentowanego przypadku tunelu UDP. Działa na rozmowie TCP, więc nie jest innym zapisem MTU trasy systemu operacyjnego i nie może pomóc usłudze UDP, która ignoruje negocjacje.
Nie układaj MTU trasy, zmiany MTU interfejsu i ograniczenia MSS w jednym oknie zmian. Jeśli problem zniknie, nie będziesz wiedzieć, które miało znaczenie, a te, które zostawisz, będą ograniczać ruch latami bez powodu, który ktoś pamięta.
Zrób to odwracalnym, potem to udowodnij
Prawdziwy właściciel trasy decyduje, czy zmiana przetrwa ponowne połączenie. Klient VPN, który instaluje trasę dynamicznie, zwykle odbuduje ją bez twojej metryki, a ręczne ip route add wygląda wtedy jak poprawka, która zawiodła dzień później. Umieść wartość w konfiguracji menedżera, a jeśli potrzebujesz tymczasowego eksperymentu, najpierw zapisz pierwotną trasę.
Przetestuj na nowym połączeniu, które wykonuje operację, która utknęła, a potem potwierdź, że zamierzona trasa prywatna nadal wygrywa i że niepowiązane cele się nie zmieniły. Połącz tunel ponownie i przeczytaj trasę, bo wartość, która znika przy ponownym połączeniu, nie jest poprawką.
Jeśli dowody nie wspierają zmiany, usuń nadpisanie przez jego menedżera i przywróć pierwotne atrybuty trasy, zamiast ją kasować. Potem zapisz, co zmierzyłeś i na której ścieżce, żeby następna osoba odróżniła prawdziwą poprawę od eksperymentu pozostawionego w działaniu.