Mity o MTU w VPN: dlaczego twoje pakiety się kurczą i gdzie znika miejsce

Ktoś mówi ci, że VPN "traci pakiety z powodu MTU", ustawiasz tunel na 1400 i transfer znów działa. Ten wynik wydaje się diagnozą. Zwykle to zbieg okoliczności w arytmetyce: wybrałeś liczbę wystarczająco małą, by zmieścić się pod limitem, którego nigdy nie zidentyfikowałeś, i spotkasz ten sam limit w następnej sieci z innym budżetem.

Większość tego powodują dwa mity. Pierwszy to przekonanie, że MTU interfejsu tunelu jest MTU ścieżki. Drugi, że enkapsulacja kosztuje "jeden nagłówek", a PPPoE nie kosztuje nic, co warto liczyć. Oba są błędne w sposób, który sprawia, że wybrana liczba wygląda arbitralnie, choć w rzeczywistości jest określona.

Mit pierwszy: MTU tunelu to MTU ścieżki

Wartość ustawiona na interfejsie tunelu to lokalna obietnica dotycząca największego wewnętrznego pakietu, który implementacja przekaże w dół. Rzeczywista pojemność ścieżki jest właściwością każdego łącza między tobą a drugim końcem i może się zmienić, gdy zmieni się trasa, gdy połączenie mobilne zostanie przekazane albo gdy ruch pójdzie innym peeringiem. Ustawione 1500 mówi, co zbuduje twój host, a nie co przeniesie sieć.

Wykrywanie MTU ścieżki istnieje po to, by pogodzić oba, i zależy od informacji zwrotnej. W IPv4 router, który nie może przesłać pakietu pełnego rozmiaru, powinien wysłać komunikat ICMP "fragmentation needed", a nadawca obniża swoje oszacowanie. W IPv6 odpowiednikiem jest komunikat Packet Too Big, a routery w ogóle nie fragmentują w tranzycie. Gdy ta informacja jest filtrowana, nadawca nadal tworzy pakiety, których ścieżka nie przeniesie, i nic mu nie mówi dlaczego.

Mit drugi: enkapsulacja kosztuje jeden nagłówek

Policz warstwy zewnętrzne uczciwie. Zewnętrzny nagłówek IP to 20 bajtów w IPv4 lub 40 w IPv6. Enkapsulacja UDP do przejścia przez NAT dodaje 8. Protokół tunelu dodaje własny nagłówek, wektor inicjalizacyjny lub nonce, dopełnienie do granicy bloku lub wyrównania szyfru, końcówkę i wartość kontroli integralności. W zależności od protokołu i szyfru suma spokojnie sięga dziesiątek bajtów, zanim wewnętrzny pakiet w ogóle się zacznie.

Potem odejmij ponownie nagłówki samego pakietu wewnętrznego. Segment TCP wewnątrz tunelu niesie własny 20-bajtowy nagłówek IP i 20-bajtowy nagłówek TCP, a MSS w TCP wynika z MTU, nie z nominalnego ładunku tunelu. Dlatego ping z mniejszym ładunkiem może się udać, podczas gdy transfer pliku się zatrzymuje: narzędzia testują różne rzeczy i tylko jedno z nich ćwiczy segment TCP pełnego rozmiaru.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Pierwsze polecenie raportuje ustawione MTU tunelu. Dwie sondy wysyłają ładunek 1472 bajtów, co z 28 bajtami nagłówków IPv4 i ICMP daje pakiet 1500 bajtów, a potem mniejszy. Jeśli duża sonda zawodzi całkowicie, a mała się udaje, masz usterkę zależną od rozmiaru, a nie ogólny problem z routingiem.

Mit trzeci: PPPoE nadal daje ci czyste 1500

Konwencjonalne łącze dostępowe PPPoE nie przenosi pakietu IP o rozmiarze 1500 bajtów. Nagłówek PPPoE plus pole protokołu PPP zajmują 8 bajtów wewnątrz ramki Ethernet, co zostawia 1492 dla pakietu IP. To tradycyjny limit opisany w RFC 2516. Jeśli prowadzisz VPN przez takie łącze, narzut tunelu pochodzi z tych 1492, a nie z 1500.

RFC 4638 definiuje sposób negocjowania większego ładunku PPP, gdy obsługują go zarówno koncentrator dostępu, jak i sprzęt klienta, dlatego samo "to połączenie używa PPPoE" nie dowodzi konkretnej liczby. Ustawienie lokalne nie może zmusić urządzenia pośredniego do przyjęcia pakietu, dla którego nigdy nie zostało skonfigurowane, więc użyteczne pytanie brzmi, co łącze faktycznie wynegocjowało, a nie co mówi etykieta.

Dlaczego usterka wygląda wybiórczo

To, że małe żądania się udają, a duże transfery zatrzymują, to klasyczny podpis czarnej dziury MTU ścieżki. Uścisk dłoni, zapytanie DNS i wywołanie API mieszczą się wszystkie; transfer masowy tworzy segmenty pełnego rozmiaru, które giną na jednym łączu, a komunikat ICMP, który miał zgłosić problem, nigdy nie dociera. Połączenie wygląda dobrze, a pobieranie wisi, co każe ludziom patrzeć na serwer zamiast na ścieżkę.

Drugi, powiązany błąd to mieszanie trzech liczb: MTU interfejsu, MSS w TCP i własnego ustawienia fragmentacji lub dopełniania protokołu. Ściskanie MSS na routerze przepisuje ogłaszane MSS, aby nadawca budował mniejsze segmenty; nie zmienia MTU tunelu i nie pomaga ruchowi UDP. Danie wszystkim trzem tej samej liczby, bo wyglądają pokrewnie, to sposób, w jaki dobrze zamierzona zmiana psuje działającą konfigurację.

Co zmienić i w jakiej kolejności

Zacznij od dowodów. Potwierdź sondami powyżej, że usterka zależy od rozmiaru, a potem znajdź najmniejszy rozmiar, który przechodzi, i największy, który zawodzi. Sprawdź rzeczywiste MTU łącza dostępowego, zanim obwinisz tunel; łącze PPPoE ogranicza budżet, zanim VPN go dotknie. Zapisz pierwotne wartości, aby zmianę można było cofnąć.

Potem zastosuj najmniejszą korektę, którą dokumentuje klient. Wiele klientów oferuje MTU tunelu oraz opcję poprawki MSS, a opcja MSS jest często lepszą dźwignią dla TCP, bo dociera do nadawcy bez zmniejszania każdego pakietu. Przetestuj ponownie ten sam cel i ten sam transfer i zapisz liczby, na których się zatrzymałeś. Wartość tunelu działająca w jednej sieci dostępowej nie jest uniwersalną stałą, a następne miejsce będzie miało własny budżet.