Dlaczego niezgodność MTU powoduje częściową łączność serwera domowego?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does MTU Mismatch Cause Partial Home Server Connectivity? - Zima Store Online

Niedopasowanie MTU powoduje częściową łączność domowego serwera, gdy małe pakiety mogą przejść przez ścieżkę, ale większe już nie. Odpowiedzi DNS, uzgadnianie TCP, pingi i krótkie wywołania API mogą się powieść, tworząc wrażenie, że trasa jest zdrowa. Połączenie jednak zatrzymuje się, gdy TLS, odpowiedź sieciowa, przesyłanie lub transfer pliku generuje pakiet IP większy niż może przenieść jedno łącze.

Poprawna ścieżka raportuje ten limit rozmiaru, aby nadawca mógł zmniejszyć swoje pakiety. Częściowa awaria pojawia się, gdy tunel, wirtualny most, router lub łącze ISP ma mniejszą MTU, a informacja zwrotna nigdy nie dociera do nadawcy — lub gdy różne warstwy reklamują rozmiary, które nie odzwierciedlają ich rzeczywistej enkapsulowanej ścieżki. Efektem jest osiągalność bez niezawodnej dostawy danych.

Krótka odpowiedź: rozmiar pakietu jest częścią łączności

MTU to największy pakiet IP, jaki interfejs może wysłać w jednej transmisji warstwy łącza. Końcowe punkty interesują się najmniejszą użyteczną wartością na całej ścieżce, a nie tylko ustawieniem 1500 bajtów widocznym na porcie Ethernet domowego serwera. Nagłówki VPN i nakładkowe zajmują miejsce, więc pakiet mieszczący się w LAN może być zbyt duży po enkapsulacji.

Awaria jest częściowa, ponieważ protokoły zaczynają od małych pakietów kontrolnych. Trójstronne uzgadnianie TCP może się zakończyć, a przeglądarka może się połączyć, zanim którakolwiek ze stron wyśle pełnowymiarowy segment danych. Jeśli zbyt duże pakiety znikają, podczas gdy potwierdzenia i mniejsze retransmisje nadal przechodzą, sesja wygląda na aktywną, ale nie robi postępów lub robi ich bardzo niewiele.

MTU, MSS i odkrywanie MTU ścieżki są powiązane, ale różne

MTU interfejsu ogranicza pakiet IP na jednym interfejsie. Maksymalny rozmiar segmentu TCP, czyli MSS, informuje, ile danych TCP końcowy punkt chce w każdym segmencie; pozostawia miejsce na nagłówki IP i TCP. Ograniczenie MSS może zmniejszyć ten reklamowany rozmiar danych na routerze, ale wpływa to na negocjacje TCP, a nie na każdy pakiet UDP lub ICMP.

Odkrywanie MTU ścieżki, czyli PMTUD, pozwala nadawcy poznać najmniejszą MTU na trasie. Dla IPv4 RFC 1191 definiuje proces, w którym router niezdolny do przesłania pakietu z ustawionym bitem Nie Fragmentuj zwraca informację zwrotną ICMP o potrzebie fragmentacji. Nadawca może wtedy obniżyć wartość MTU ścieżki i ponownie wysłać pakiet.

Routery IPv6 nie fragmentują pakietów tranzytowych. RFC 8201 określa, że węzeł IPv6 używa komunikatów ICMPv6 Packet Too Big, aby poznać mniejsze MTU ścieżki. Blokowanie tego ruchu kontrolnego nie wzmacnia ścieżki danych; uniemożliwia punktowi końcowemu dostosowanie się do rzeczywistego ograniczenia.

Gdzie ścieżka serwera domowego zaczyna odrzucać większe pakiety

Tunel zmniejsza użyteczny ładunek danych

WireGuard, IPsec, PPPoE, VLAN i inne enkapsulacje dodają nagłówki wokół oryginalnego pakietu. Pakiet wewnętrzny o rozmiarze 1500 bajtów nie zmieści się niezmieniony w zewnętrznym łączu o rozmiarze 1500 bajtów, gdy obecne są te nagłówki. Interfejs tunelu zwykle zgłasza niższe MTU, ale ręczne nadpisanie lub urządzenie pośrednie może pozostawić punkty końcowe z optymistyczną wartością.

Niedopasowanie może wpływać na dostęp zdalny, podczas gdy lokalna usługa działa bez zarzutu. Telefon w sieci Wi-Fi łączy się z serwerem przez zwykły Ethernet, podczas gdy ten sam telefon w VPN korzysta z mniejszej ścieżki tunelu. Ponieważ trasowanie, uwierzytelnianie i małe żądania nadal działają, objaw może przypominać problem z aplikacją lub certyfikatem.

Zagnieżdżone ścieżki pogłębiają problem. Pakiet kontenera może przejść przez wirtualną parę Ethernet i most, wejść do adaptera maszyny wirtualnej, a następnie do VPN. Ograniczające MTU dotyczy całej trasy, podczas gdy każdy widoczny interfejs może zgłaszać wiarygodną wartość dla swojej warstwy.

Informacje zwrotne ICMP są filtrowane lub tracone

Jeśli ograniczający router odrzuci zbyt duży pakiet i jego błąd dotrze do źródła, PMTUD może się odnowić. Jeśli firewall bezkrytycznie odrzuca cały ruch ICMP lub ICMPv6, nadawca nadal używa rozmiaru, którego ścieżka nie jest w stanie przenieść. Cloudflare opisuje tę nowoczesną awarię jako czarną dziurę MTU ścieżki: duże pakiety są cicho tracone, podczas gdy aplikacja czeka.

Asymetryczne trasowanie może dawać ten sam efekt, nawet gdy żaden firewall celowo nie blokuje wiadomości. Pakiet danych może podążać jedną ścieżką, a błąd ICMP inną; trasowanie polityk, NAT lub filtr dostawcy mogą uniemożliwić powiązanie wiadomości zwrotnej z oryginalnym nadawcą. Przechwytywanie pakietów musi więc analizować zarówno kierunek danych, jak i informacji zwrotnych.

Powtarzające się retransmisje TCP to wskazówka, nie dowód. Przeciążenie i utrata w sieci bezprzewodowej również wywołują retransmisję. Problemy z MTU stają się bardziej prawdopodobne, gdy awarie zaczynają się przy powtarzalnym rozmiarze ładunku, małe testy się powiodą, a zmniejszenie MTU interfejsu lub reklamowanego MSS natychmiast przywraca działanie.

Wirtualne sieci reklamują niewłaściwy rozmiar

Mosty kontenerów i przełączniki VM mogą dziedziczyć lub domyślnie mieć MTU większe niż warstwa bazowa. Kontener tworzy wtedy pakiet ważny dla swojego wirtualnego interfejsu, ale zbyt duży po przesłaniu przez hosta przez VPN, nakładkę chmurową lub łącze PPPoE. Funkcje offload mogą sprawiać, że przechwycenia wyglądają na większe niż pakiety na łączu, więc miejsce przechwytywania ma znaczenie.

Udokumentowany przypadek Dockera dokładnie odpowiadał temu problemowi: małe żądanie LDAP powiodło się, ale odpowiedź zniknęła, ponieważ MTU VPN wynosiło 1400, a Docker używał 1500. Sieć hosta wydawała się naprawiać aplikację, ponieważ usunęła niedopasowaną warstwę wirtualną, a nie dlatego, że aplikacja się zmieniła.

Nie wyciągaj wniosków o zachowaniu łącza na podstawie jednego przechwycenia pokazującego ogromne segmenty TCP. Ogólne wyłączanie segmentacji może prezentować systemowi operacyjnemu duże bufory i dzielić je później. Przechwytuj po stronie odbiorczej, tymczasowo wyłącz offloady do diagnozy lub porównaj liczniki interfejsu z kontrolowanymi testami rozmiaru pakietów, zanim stwierdzisz, że urządzenie wysłało niemożliwą ramkę.

Objaw	Dlaczego może działać częściowo	Przydatny następny test
Ping i SSH łączą się, ale HTTPS zawiesza się	Pakiety kontrolne mieszczą się; pakiety TLS lub odpowiedzi nie	Testuj rosnące rozmiary bez fragmentacji
LAN działa, VPN zawodzi	Enkapsulacja zmniejsza MTU zdalnej ścieżki	Porównaj MTU tunelu i rozmiar wewnętrznego pakietu
Pobieranie nie powiodło się, ale drobne wywołania API przechodzą	Tylko większe pakiety z serwera do klienta przekraczają limit	Przechwyć oba kierunki i szukaj retransmisji
Host działa, kontener przekracza limit czasu	Wirtualny interfejs reklamuje większe MTU niż warstwa bazowa	Porównaj ustawienia hosta, mostu, kontenera i tunelu

Ustawienia upstream i tunelu kształtują rzeczywiste ograniczenie

Serwer domowy nie zawsze jest miejscem powstania niezgodności. PPPoE, mechanizm przejściowy ISP, tunel zdalnego dostępu lub router nadrzędny mogą wprowadzać najszersze ograniczenie. Śledź dokładną trasę klient–usługa i zanotuj każdą granicę enkapsulacji zamiast zmieniać tylko fizyczną kartę sieciową.

Zezwól na komunikaty kontrolne potrzebne PMTUD. Dla IPv4 obejmuje to odpowiedni komunikat o niedostępności celu wymagający fragmentacji; dla IPv6 – komunikat Packet Too Big. Stosuj wąską politykę zapory według typu i stanu komunikatu zamiast blokować cały ICMP. Serwer nie może poznać ograniczenia ścieżki, którego sieć odmawia zgłoszenia.

Unikaj polegania na fragmentacji jako normalnym rozwiązaniu. RFC 8900 wyjaśnia, że fragmentacja IP wprowadza operacyjną kruchość. Dopasowanie MTU, zachowanie PMTUD lub bezpieczne testowanie transportu jest bardziej niezawodne niż zakładanie, że każdy pośrednik przekaże i złoży fragmenty.

Jeśli nie można zmienić jednego routera, ograniczenie MSS może być praktycznym obejściem TCP na granicy tunelu lub przekazywania. Ustaw je na podstawie rzeczywistej ścieżki, a nie kopiuj uniwersalnej wartości. Nie naprawi to zbyt dużych datagramów UDP, a zbyt niska wartość niepotrzebnie zwiększa narzut pakietów i nagłówków, więc potwierdź poprawę za pomocą przechwyceń i testów aplikacji.

Ustawienia serwera, VM i kontenera muszą być zgodne.

Sporządź inwentaryzację MTU na fizycznej karcie sieciowej, bondzie, VLAN-ie, moście, adapterze VM, sieci kontenera i tunelu. Wartości nie muszą być numerycznie identyczne, jeśli warstwa prawidłowo uwzględnia enkapsulację, ale żadna warstwa wewnętrzna nie powinna generować pakietów, których kolejna warstwa nie może przenieść lub zgłasza jako zbyt duże.

Dla Dockera ustaw odpowiednie MTU podczas tworzenia sieci lub poprzez konfigurację demona, a następnie w razie potrzeby odtwórz dotknięte sieci i kontenery. Przykład rozwiązywania problemów Civo pokazuje, jak MTU Dockera ignorujące warstwę bazową może powodować nieoczekiwane problemy z łącznością. Zweryfikuj działający interfejs po zmianach; samo edytowanie konfiguracji nie dowodzi, że działająca sieć została zmieniona.

Oddziel strojenie wydajności od naprawy. Wyjaśnienie ZimaSpace dotyczące rozmiaru okna TCP na łączach długodystansowych dotyczy ilości danych mogących pozostawać w transmisji, podczas gdy MTU kontroluje rozmiar pakietu. Zwiększanie buforów nie sprawi, że zbyt duży pakiet przejdzie przez mniejsze łącze.

Sprawdzenia, które wykrywają uszkodzony etap

Znajdź największy pakiet, który konsekwentnie przechodzi

Użyj odpowiednich dla platformy opcji ping, aby ustawić rozmiar ładunku i zabronić fragmentacji tam, gdzie to możliwe, pamiętając o dodaniu bajtów nagłówka IP i ICMP przy porównywaniu wyniku z MTU interfejsu. Przetestuj kilka rozmiarów z tej samej ścieżki klienta, która wykazuje błąd. Powtarzalny próg jest bardziej informatywny niż pojedynczy udany ping domyślny.

Powtórz test w sieci LAN, przez VPN i z wnętrza kontenera lub maszyny wirtualnej. Jeśli próg zmienia się na jednej granicy, ta warstwa staje się głównym podejrzanym. Niektóre sieci ograniczają lub blokują ruch echo, więc potwierdź wynik za pomocą żądań aplikacji TCP lub specjalistycznego narzędzia do ścieżki MTU.

Sprawdź interfejsy, trasy i enkapsulację

Zapisz wybraną trasę i interfejs wyjściowy dla dotkniętego celu. Sprawdź wartości MTU na każdym wirtualnym i fizycznym interfejsie, przez który przechodzi pakiet, oraz konfigurację tunelu i sieci kontenera. Nie zakładaj, że używana jest trasa domyślna, gdy aktywne jest trasowanie polityk lub dzielony tunel.

Oblicz narzut nagłówka dla rzeczywistego stosu tunelowego, włączając zewnętrzną wersję IP i transport. Bezpieczne wewnętrzne MTU musi zostawić miejsce na te nagłówki na zewnętrznej ścieżce. Jeśli tunel korzysta ze zmiennej trasy, wybierz wartość działającą na wszystkich obsługiwanych podwarstwach lub zachowaj działający mechanizm wykrywania.

Przechwyć dane i informacje zwrotne ICMP po obu stronach

Przechwyć ruch blisko nadawcy i za podejrzanym wąskim łączem. Szukaj dużego pakietu powtarzanego bez potwierdzenia, komunikatu ICMP o potrzebie fragmentacji lub komunikatu ICMPv6 Packet Too Big. Jeśli błąd pojawia się dalej w sieci, ale nigdy nie dociera do nadawcy, skup się na trasowaniu powrotnym i polityce zapory.

Dla TCP sprawdź opcje MSS w pakietach SYN i SYN-ACK i porównaj je z obserwowanymi segmentami danych. Niższe MSS może zapobiec tworzeniu przez nadawcę zbyt dużych pakietów TCP, ale nie ujawnia, czy UDP nadal jest uszkodzony. Użyj przechwycenia, aby zweryfikować naprawę, zamiast traktować załadowaną regułę zapory jako sukces.

Wyrównaj MTU lub ogranicz MSS, a następnie przetestuj ponownie

Wol preferować korektę MTU na interfejsie, który zna mniejsze podłoże. Odtwórz sieci wirtualne, gdy ich MTU jest ustalone przy tworzeniu. Jeśli to niemożliwe, ogranicz MSS TCP na granicy przekazywania lub tunelu i zezwól na wymaganą informację zwrotną ICMP. Wprowadzaj zmiany pojedynczo, aby wynik był przypisywalny.

Testuj ponownie oryginalny proces, nie tylko ping. Ukończ negocjację TLS, załaduj odpowiedź większą niż jeden pakiet, wyślij i pobierz plik oraz utrzymaj połączenie na tyle długo, by zaobserwować retransmisje. Częściowa łączność jest rozwiązana tylko wtedy, gdy aplikacje, które ją ujawniły, przesyłają dane niezawodnie w obu kierunkach.

Kiedy częściowa łączność staje się poważnym problemem

Traktuj problem jako pilny, gdy dotyczy kopii zapasowych, przywracania, zdalnej administracji, synchronizacji lub uwierzytelniania. Te procesy mogą przejść wstępne testy i zawieść dopiero po rozpoczęciu przesyłania istotnych danych, pozostawiając niekompletne kopie lub przekroczenia czasu, które operatorzy błędnie interpretują jako błędy magazynu lub poświadczeń.

Priorytetowo traktuj to również, gdy IPv6 zachowuje się inaczej niż IPv4, ścieżka tylko VPN zawodzi lub ruch kontenera różni się od ruchu hosta. Te różnice ujawniają, która trasa lub enkapsulacja zmienia użyteczny rozmiar pakietu. Im bardziej deterministyczna granica, tym mniej sensu ma ciągłe ponawianie aplikacji bez naprawy ścieżki sieciowej.

FAQ

Dlaczego mogę pingować serwer domowy, a jego strona się nie ładuje?

Domyślne pakiety ping są małe, podobnie jak wymiany DNS i uzgadnianie TCP. Strona może się zawiesić tylko wtedy, gdy TLS lub HTTP wysyła pakiet powyżej limitu ścieżki. Testuj większe, niefragmentujące sondy i przechwytuj nieudane połączenia webowe zamiast traktować jedną odpowiedź ping jako dowód, że każdy rozmiar pakietu działa.

Czy każdy interfejs powinien używać MTU 1500?

Nie. Ethernet często używa 1500, ale tunele i inne enkapsulacje potrzebują miejsca na nagłówki zewnętrzne. Ważne jest, aby każda warstwa albo reklamowała rozmiar, który może obsłużyć następna warstwa, albo otrzymywała działającą informację zwrotną pozwalającą dostosować się do najmniejszego MTU na trasie.

Czy ograniczanie MSS to to samo co ustalanie MTU?

Nie. Ograniczanie MSS zmienia rozmiar ładunku TCP reklamowany podczas nawiązywania połączenia, co może utrzymać pakiety TCP poniżej znanego limitu. Nie zmienia to MTU interfejsu i nie ogranicza bezpośrednio ruchu UDP ani innego ruchu IP.

Wyrównanie MTU i działanie PMTUD dotyczą samej ścieżki. Ograniczanie jest przydatne, gdy urządzenie przekazujące lub tunel nie może inaczej przekazać ograniczenia, ale powinno być mierzone, umieszczone na właściwej granicy i poprzedzone testami każdego dotkniętego protokołu.