Jumbo frames nie sprawiają, że ścieżka VPN przenosi pakiety 9000 bajtów
Duży MTU to lokalna umowa łącza. Odejmij narzut tunelu od najmniejszego łącza na trasie, zanim podniesiesz wewnętrzny interfejs.
Włączyłeś ramki 9000 bajtów w sieci LAN i oczekiwałeś, że VPN przyspieszy. Stał się wolniejszy albo całkowicie przestał przepuszczać duże transfery. Ramki jumbo to lokalna umowa łącza; nie poszerzają ścieżki, którą przechodzi tunel.
Dostępny budżet wyznacza najmniejsza granica na trasie, łącznie z enkapsulacją, którą dodaje tunel.
Co naprawdę zmieniają ramki jumbo
MTU to właściwość jednego interfejsu. Podniesienie go na serwerze i jego przełączniku oznacza, że te dwa mogą wymieniać większe ramki bez fragmentacji. Nie mówi nic o routerze za przełącznikiem, o dostawcy ani o drugiej stronie tunelu. Te urządzenia mają własne limity, a pakiet, który przekroczy któryś z nich, jest odrzucany lub fragmentowany według reguł, których nie ustawiłeś.
Lokalna umowa, globalne skutki. Na tym polega całe zamieszanie.
Podatek od enkapsulacji
Tunel owija twój pakiet w inny. WireGuard przez IPv4 UDP dodaje około 60 bajtów narzutu; tryb UDP OpenVPN mieści się w tym samym zakresie, a IPsec zmienia się w zależności od trybu i algorytmów. Te bajty pochodzą z budżetu zewnętrznej ścieżki, a nie znikąd.
Zewnętrzne łącze 1500 bajtów nie może więc przenosić wewnętrznego pakietu 1500 bajtów po dodaniu nagłówka tunelu.
Warto raz wykonać tę arytmetykę. Na ścieżce 1500 bajtów interfejs WireGuard chce MTU około 1420, aby zapakowany pakiet się zmieścił. Ustaw wewnętrzny interfejs na 9000, a każdy duży pakiet będzie wymagał fragmentacji, której tunel nie potrafi wykonać, albo zostanie odrzucony.
Znajdź najmniejsze łącze na ścieżce
Przejdź trasę i znajdź najniższy MTU. LAN to zwykle 1500 lub 9000, WAN zwykle 1500, a łącze mobilne lub PPP może być jeszcze niższe. Potem odejmij narzut tunelu. Jeśli wynik jest mniejszy niż MTU wewnętrznego interfejsu, masz odpowiedź. Odkrywanie MTU ścieżki potrafi znaleźć to automatycznie, ale tylko gdy przepuszczane są komunikaty ICMP, od których to zależy.
Filtrowany ICMP to klasyczny powód, dla którego duży transfer wisi, a małe żądania działają dobrze.
Sprawdź zależność od rozmiaru, nie rozszerzając zmiany
Użyj reprezentatywnego transferu i zachowaj oryginalne wartości, aby móc je przywrócić. ping -M do -s 1472 sprawdza pakiet 1500 bajtów z ustawionym bitem DF; zmniejszaj rozmiar, aż przejdzie. Jeśli zawodzą tylko duże pakiety, masz problem z rozmiarem, a nie z routingiem.
Uważaj na offload po stronie hosta przy czytaniu przechwyceń. Offload segmentacji może pokazywać ramki znacznie większe niż to, co naprawdę przeszło przez przewód, przez co działająca ścieżka wygląda na zepsutą, a zepsuta na dobrą.
Kiedy duży MTU jest właściwym projektem
Kontrolowana sieć prywatna może legalnie prowadzić większe ramki od końca do końca, pod warunkiem że każde urządzenie na ścieżce się zgadza i narzut tunelu jest uwzględniony. To skoordynowany projekt z udokumentowaną wartością na łącze, a nie jedna duża liczba wpisana do klienta.
Dla zwykłego publicznego wyjścia przyjmij 1500 lub mniej i pozwól tunelowi wybrać bezpieczny wewnętrzny MTU. RFC 8201 omawia odkrywanie MTU ścieżki dla przypadku IPv6 i jest użytecznym źródłem o tym, jak powinno działać sprzężenie zwrotne.