Zagnieżdżone tunele VPN: dlaczego wewnętrzny zastyga na dużych pakietach

DNS się rozwiązuje, sesja SSH się trzyma, a potem duży wysyłany plik zastyga, podczas gdy ping do tego samego hosta wciąż odpowiada. Ten podział wskazuje na rozmiar pakietu, a nie na zepsuty tunel. Zagnieżdżone tunele osiągają to przy rozmiarach, których żaden z tuneli sam by nie osiągnął. Sesja wewnętrzna jest w porządku; po prostu dostaje pakiety, które już się nie mieszczą.

Dokąd naprawdę trafia MTU ścieżki

Każde enkapsulowanie zużywa bajty, zanim następna warstwa dostanie swoją kolej. Ścieżka Ethernet oferuje zewnętrznemu pakietowi 1500 bajtów, a zewnętrzny tunel bierze swoją część, zanim cokolwiek w środku da się zaadresować. Jedna zgadywana wartość narzutu będzie błędna dokładnie o tyle, ile ma znaczenie.

Wypisz warstwy po kolei: ścieżka dostępu, transport zewnętrzny, tunel zewnętrzny, transport wewnętrzny, tunel wewnętrzny, aplikacja. Policz każdy nagłówek raz i trzymaj UDP osobno od własnego nagłówka i znacznika tunelu.

Dwie warstwy WireGuard, policzone raz

Weź ścieżkę dostępu IPv4 z jednym tunelem WireGuard w drugim. Warstwa zewnętrzna kosztuje 20 bajtów IPv4, 8 UDP i 32 na nagłówek danych WireGuard plus jego znacznik uwierzytelnienia. W jej wnętrzu tunel wewnętrzny potrzebuje własnego nagłówka IPv4 o 20 bajtach i nagłówka UDP o 8 bajtach przed swoimi drugimi 32 bajtami narzutu WireGuard. To, co zostaje, mieści nagłówek IPv4, nagłówek TCP i dane. Zewnętrzna ścieżka IPv6 kosztuje 40 zamiast 20 i zostawia 1320.

Arytmetyka kończy się na 1340 bajtach. Jedna warstwa według tych samych zasad zostawia 1400 na ładunek TCP, czyli 1500 minus 20, 8, 32, 20 i 20, a różnica 60 bajtów to dokładnie wewnętrzna enkapsulacja, którą dodaje drugi tunel.

Zastosuj 1400 na zagnieżdżonej ścieżce, a wewnętrznemu tunelowi brakuje 60 bajtów, niewidocznie, dopóki pakiet nie będzie dość duży, by ich potrzebować. Dopełnienie i własna opcja fragmentacji protokołu znów przesuwają liczby, więc ufaj tabeli.

MTU, MSS i fragmentacja działają w różnych miejscach

MTU interfejsu ogranicza to, co interfejs wyśle, a zaciskanie MSS w TCP zmienia to, co partner TCP jest gotów wysłać. Zaciskanie naprawia sesje TCP i nic nie robi dla dużego datagramu UDP, dlatego poprawka wygląda na udaną dla jednej aplikacji i po cichu mija następną. Własna opcja fragmentacji protokołu to trzecia dźwignia z własnymi awariami. MTU interfejsu to zwykły pierwszy ruch i najgrubszy.

Tunele mostkowane i routowane niosą różne ramki, więc liczby z innego wdrożenia rzadko się przenoszą. Odkrywanie MTU ścieżki, opisane w RFC 8201, pomaga tylko dopóki komunikaty ICMP, od których zależy, są przepuszczane.

Znalezienie warstwy, której brakuje

Sprawdź każdy tunel osobno, zanim je zagnieździsz, jeśli wymagania pozwalają na porównanie. Sonda o stałym rozmiarze to rozstrzyga: ping -M do -s 1472 -c 3 10.8.0.1 wysyła pełny pakiet IPv4 o 1500 bajtach wewnątrz tej warstwy. Dodaj drugą warstwę i powtórz tę samą sondę, żeby każda awaria należała do znanej zmiany.

Gdy transfer się zatnie, zmieniaj jeden udokumentowany parametr naraz i zapisuj rozmiar, na którym zawodzi. Sprawdź też ścieżkę powrotną, bo zagnieżdżona rekurencja tras potrafi na tyle wiernie naśladować problem z rozmiarem pakietu, że kosztuje całe popołudnie. Przefiltrowana odpowiedź ICMP może ukryć prawdziwy limit, więc sonda jest ważniejsza niż rozumowanie.

Zapisz budżet tam, gdzie znajdzie go następna osoba

Tabela z jednym wierszem na warstwę przeżywa regułę kciuka. Trzymaj ją obok schematu tunelu, żeby nikt nie powtarzał arytmetyki pod presją.

Więcej tuneli oznacza więcej zależności, więc plan wycofania zasługuje na miejsce obok budżetu. Jeśli liczby nadal się nie zgadzają, zmierz ścieżkę zamiast znów zgadywać. Celem jest liczba, której możesz bronić, a nie taka, którą zapamiętasz.