Czy to ISP blokuje UDP, czy aplikacja w tunelu?

Ktoś zgłasza, że VPN „blokuje UDP“, a to zdanie ukrywa dwa zupełnie różne twierdzenia. Jedno dotyczy transportu, który widzi sieć dostępowa, drugie pakietów aplikacji po ich odszyfrowaniu wewnątrz tunelu. Zaszyfrowany tunel można filtrować z zewnątrz bez żadnego klucza, a wewnętrzna aplikacja UDP może zawieść z powodów, które nie mają nic wspólnego z filtrowaniem. Zdecyduj, które twierdzenie testujesz, zanim zaczniesz zbierać dowody.

Dwa nagłówki, jedno słowo

We wdrożeniu IPsec z NAT-traversal zewnętrzny pakiet to UDP zaadresowany między dwoma punktami końcowymi VPN, zwykle na porcie 4500. W jego wnętrzu zaszyfrowany ładunek niesie wszystko, co tunel przekazuje, a to samo może być TCP lub UDP. Słowo UDP pojawia się więc dwukrotnie, z różnym znaczeniem i różną widocznością.

Sieć pośrednia widzi nagłówek zewnętrzny i nic z wewnętrznego. Może zezwolić, ukształtować lub odrzucić zewnętrzny przepływ, i nie musi do tego niczego odszyfrowywać. Ta asymetria jest całym powodem mylenia obu twierdzeń: to samo słowo opisuje to, co filtruje sieć, i to, co wysyła aplikacja. Zapisuj warstwę obok słowa za każdym razem, gdy rejestrujesz ustalenie, a zamieszanie w większości znika.

Nagłówek wewnętrzny staje się widoczny dopiero w punkcie końcowym odbiorcy, po odszyfrowaniu. Od tego momentu pakiet jest przekazywany jak każdy inny, zgodnie z trasami, polityką i własnym filtrowaniem punktu końcowego. To odrębne decyzje podejmowane przez różne urządzenia.

Co sieć nadal może zobaczyć

Szyfrowanie ukrywa ładunek i wewnętrzny nagłówek transportowy, a nie fakt istnienia przepływu. Adresy punktów końcowych, porty, rozmiary pakietów i czasy pozostają widoczne, i to wystarcza, by heurystycznie klasyfikować ruch lub blokować konkretne miejsce docelowe.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Pierwsze przechwycenie pokazuje przepływ zewnętrzny na interfejsie fizycznym, a drugie przepływ wewnętrzny na interfejsie tunelu. Uruchomienie obu naraz odpowiada na pytanie wprost: jeśli przepływ zewnętrzny istnieje, a wewnętrzny nie, aplikacja nigdy nic nie wysłała do tunelu. Jeśli istnieją oba i nic nie wraca, problem jest poza tunelem, w miejscu docelowym lub na drodze powrotnej.

RFC 3948 definiuje zewnętrzną enkapsulację UDP, a specyfikacja ESP definiuje chroniony układ w jej wnętrzu. Żaden z tych dokumentów nie obiecuje, że sieć dostępowa przepuści zewnętrzny przepływ, dlatego warto wykonać test osiągalności na zewnętrznej krotce, zanim powstanie jakakolwiek teoria o wewnętrznej. Zablokowana zewnętrzna krotka daje tunel, który nigdy nie powstaje, a nie tunel, który powstaje i potem traci jedną aplikację.

Dlaczego jedna aplikacja UDP zawodzi w działającym tunelu

Tunel, który przenosi aplikację webową, ale nie aplikację UDP, ma kilka prawdopodobnych wyjaśnień, a filtrowanie wewnętrznego protokołu przez ISP nie jest pierwszym. Najczęstsze to pokrycie: obie aplikacje nie wchodzą do tego samego tunelu, bo brakuje trasy do celu UDP albo wykluczają go reguły tunelu dzielonego klienta.

Drugie to punkt końcowy. Serwer VPN zezwalający na listę protokołów, zapora w miejscu docelowym albo usługa, która nigdy nie nasłuchuje na oczekiwanym porcie, dadzą limit czasu wyglądający identycznie jak blokada sieciowa.

Trzecie to rozmiar pakietu. Aplikacje UDP często wysyłają większe datagramy niż żądanie webowe, a enkapsulacja zmniejsza użyteczne MTU, więc po udanym uścisku dłoni może nastąpić cisza przy pierwszym pełnowymiarowym ładunku. Ten wzorzec łatwo odczytać jako blokadę, bo małe pakiety przechodzą, a duże znikają. Szybka próba MTU rozstrzyga to w mniej niż minutę, a odpowiedzią jest zwykle mniejszy ładunek lub poprawiony MSS, a nie filtr sieciowy.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Pierwsze polecenie sprawdza, czy duży pakiet przechodzi przez ścieżkę przy wyłączonej fragmentacji, co szybko ujawnia problem z MTU. Drugie wysyła mały, ograniczony strumień UDP i raportuje straty oraz jitter. Strumień, który zaczyna się i potem zanika, wskazuje na rozmiar, a nie na blokadę.

Zgłaszaj warstwę, nie protokół

Zapisz ustalenie w jednej z trzech form: dostarczanie zewnętrzne nie powiodło się, przekazywanie wewnętrzne nie powiodło się albo aplikacja zawiodła. Każda ma innego właściciela, a mieszanie ich wysyła zgłoszenie do niewłaściwego zespołu.

Zmiana lokalnego portu nie może utworzyć pasującego nasłuchu na drugim końcu, więc obejście po stronie klienta, które wydaje się pomagać, jest zwykle dowodem, że pierwotny cel był błędny. Podobnie dostarczony profil alternatywny dowodzi czegoś o osiągalności i niczego o tym, czy aplikacja jest poprawnie skonfigurowana.

Utrzymuj wnioskowanie osobno od obserwacji. Analiza ruchu może sugerować, czym jest przepływ, bez jego odszyfrowywania, i jest to przydatne ustalenie, ale nie jest to samo twierdzenie co odczyt nagłówka wewnętrznego. Wskaż, które z nich naprawdę masz.