WireGuard zastyga: limit MTU czy brakująca reguła przekazywania?
Wszystko za serwerem to problem przekazywania lub trasy powrotnej. Małe żądania działają, a duże zastygają — to sygnatura rozmiaru pakietu.
Nawykiem jest obniżanie MTU, gdy tylko WireGuard zacznie się źle zachowywać, a ten nawyk ukrywa inny defekt. Brama, która nie przekazuje, i ścieżka, która nie przenosi dużych pakietów, dają rozróżnialne wzorce: jedna zawodzi w obu kierunkach i przy każdym rozmiarze, druga przeżywa małe żądania i ginie na dużych. Ustal, którą formę masz, zanim zmienisz jakąkolwiek liczbę. Test jest tani i usuwa połowę możliwych przyczyn.
Dwa defekty, dwie różne formy
Problem przekazywania pojawia się zaraz za serwerem. Uścisk dłoni się udaje, adres tunelu odpowiada, a nic za bramą nie jest osiągalne nawet małym żądaniem. Pakiet dotarł do serwera i nie został przekazany albo odpowiedź nie miała trasy powrotnej.
Problem rozmiaru pojawia się tylko powyżej progu. DNS, uścisk dłoni TCP i małe wywołanie API działają, a pobieranie pliku lub duża odpowiedź zawiesza się. Pakiety, które się zmieściły, przeszły od końca do końca, a te, które się nie zmieściły, zostały gdzieś odrzucone bez użytecznego raportu.
Te opisy wskazują na różnych ludzi i różne pliki konfiguracji, dlatego zmierzenie formy jest warte więcej niż domysł. Jeden ping do bramy nie potrafi ich rozdzielić.
Wyklucz przekazywanie, zanim cokolwiek zmniejszysz
Przetestuj cel za bramą, a nie samą bramę. Ping do adresu tunelu serwera dowodzi tylko, że interfejs jest włączony i że docierasz do maszyny kończącej tunel. Ruch dla szerszej sieci zależy od włączonego przekazywania IP na tej maszynie i od zapory, która pozwala na przekazywany strumień. Oba muszą być prawdziwe, a jeśli jeden jest fałszywy, powstaje ta sama cisza.
Routing powrotny liczy się tak samo. Jeśli sieć docelowa nie wie, jak dotrzeć do adresu tunelu klienta, żądanie przychodzi, a odpowiedź znika, i klient zgłasza przekroczenie czasu, które wygląda identycznie jak odrzucone przekazanie.
Tam, gdzie projekt używa translacji adresów, reguła translacji jest częścią tej trasy powrotnej. Usunięcie jej podczas tropienia problemu z MTU zamienia działający projekt w zepsuty, więc przeczytaj istniejące reguły, zanim je edytujesz.
Zmierz, gdzie zaczyna się zerwanie
Najpierw odczytaj stan przekazywania i reguły filtrowania. To kontrole tylko do odczytu i odpowiadają na tanie pytanie:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Następnie sprawdź rozmiary z bitem don’t-fragment, od klienta, w stronę hosta za bramą:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Jeśli pierwsza próba działa, a druga zawodzi z błędem fragmentacji, ścieżka mówi ci swój użyteczny rozmiar. Jeśli żadna nie działa, patrzysz na przekazywanie lub routing, a MTU nie jest zmienną, którą trzeba zmienić.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
Napraw warstwę, którą udowodniłeś
Gdy przekazywanie jest defektem, poprawką jest reguła przekazywania lub trasa, wyrażona tak wąsko, jak pozwala projekt. Gdy rozmiar jest defektem, poprawką jest MTU uwzględniający enkapsulację na tej konkretnej ścieżce, zastosowany do interfejsu, który go potrzebuje, a nie do każdego adaptera we flocie.
Tak czy inaczej, powtórz potem to samo zadanie wobec tego samego celu. Jeśli pierwotny duży transfer teraz się kończy, zmiana dotyczyła warstwy, która zawodziła. Jeśli poprawiła się tylko mała próba, leczyłeś objaw, a prawdziwy limit nadal stoi.
Zapisz, którą formę zaobserwowałeś przed zmianą. Ta jedna linia, zanotowana obok poprawki, jest tym, co powstrzymuje następną osobę przed obniżeniem MTU, które nigdy nie było problemem.