Blokuje ISP UDP, nebo je to aplikace uvnitř tunelu?

Někdo hlásí, že VPN „blokuje UDP“, a tato fráze skrývá dvě zcela odlišná tvrzení. Jedno se týká transportu, který vidí přístupová síť, druhé paketů aplikace poté, co byly uvnitř tunelu dešifrovány. Šifrovaný tunel lze filtrovat zvenčí bez jakéhokoli klíče a vnitřní UDP aplikace může selhat z důvodů, které s filtrováním nemají nic společného. Rozhodněte, které tvrzení testujete, než začnete shromažďovat důkazy.

Dvě hlavičky, jedno slovo

V nasazení IPsec s NAT-traversal je vnější paket UDP adresovaný mezi dvěma koncovými body VPN, obvykle na portu 4500. Uvnitř nese šifrovaný obsah vše, co tunel předává, což samo může být TCP nebo UDP. Slovo UDP se tedy objevuje dvakrát s různým významem a různou viditelností.

Mezilehlá síť vidí vnější hlavičku a z vnitřní nic. Může vnější tok povolit, tvarovat nebo zahodit a nemusí k tomu nic dešifrovat. Tato asymetrie je celým důvodem, proč se obě tvrzení pletou: stejné slovo popisuje to, co filtruje síť, i to, co posílá aplikace. Zapisujte k slovu vrstvu, kdykoli zaznamenáte zjištění, a zmatek většinou zmizí.

Vnitřní hlavička se stane viditelnou až v přijímajícím koncovém bodu, po dešifrování. Od toho okamžiku se paket předává jako každý jiný, podle tras, politiky a vlastního filtrování koncového bodu. To jsou samostatná rozhodnutí, která dělají různé prvky.

Co síť ještě vidí

Šifrování skrývá obsah a vnitřní transportní hlavičku, nikoli skutečnost, že tok existuje. Adresy koncových bodů, porty, velikosti paketů a časování zůstávají viditelné, a to stačí k heuristické klasifikaci provozu nebo k zablokování konkrétního cíle.

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

První zachycení ukazuje vnější tok na fyzickém rozhraní, druhé vnitřní tok na rozhraní tunelu. Spuštění obou najednou odpovídá na otázku přímo: pokud vnější tok existuje a vnitřní ne, aplikace do tunelu nic neposlala. Pokud existují oba a nic se nevrací, problém je za tunelem, v cíli nebo na zpětné cestě.

RFC 3948 definuje vnější UDP zapouzdření a specifikace ESP definuje chráněné uspořádání uvnitř něj. Ani jeden dokument neslibuje, že přístupová síť vnější tok propustí, a proto má smysl provést test dosažitelnosti na vnější n-tici dřív než jakoukoli teorii o vnitřní. Zablokovaná vnější n-tice vytvoří tunel, který nikdy nevznikne, ne tunel, který vznikne a pak ztratí jednu aplikaci.

Proč jedna UDP aplikace selhává uvnitř funkčního tunelu

Tunel, který přenáší webovou aplikaci, ale ne UDP aplikaci, má několik pravděpodobných vysvětlení a filtrování vnitřního protokolu ISP není první. Nejčastější je pokrytí: obě aplikace nevstupují do stejného tunelu, protože chybí trasa k cíli UDP nebo je vylučují pravidla rozděleného tunelu klienta.

Druhý je koncový bod. Server VPN, který povoluje seznam protokolů, firewall v cíli nebo služba, která nikdy neposlouchá na očekávaném portu, všechny vytvoří časový limit, který vypadá stejně jako síťové zablokování.

Třetí je velikost paketu. UDP aplikace často posílají větší datagramy než webový požadavek a zapouzdření snižuje použitelnou MTU, takže po úspěšném handshake může následovat ticho při prvním plně velkém obsahu. Tento vzorec se snadno přečte jako zablokování, protože malé pakety projdou a velké zmizí. Rychlá sonda MTU to vyřeší za méně než minutu a odpovědí bývá menší obsah nebo opravený MSS, ne síťový filtr.

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

První příkaz testuje, zda velký paket projde cestou s vypnutou fragmentací, což rychle odhalí problém s MTU. Druhý posílá malý ohraničený UDP tok a hlásí ztráty a jitter. Tok, který začne a pak se zastaví, ukazuje na velikost, ne na zablokování.

Hlaste vrstvu, ne protokol

Zapište zjištění v jedné ze tří forem: vnější doručení selhalo, vnitřní předávání selhalo, nebo aplikace selhala. Každá má jiného vlastníka a jejich smíchání pošle tiket špatnému týmu.

Změna místního portu nemůže na vzdáleném konci vytvořit odpovídající naslouchající socket, takže klientská obejití, která vypadají, že pomáhají, jsou obvykle důkazem, že původní cíl byl špatný. Stejně tak dodaný alternativní profil dokazuje něco o dosažitelnosti a nic o tom, zda je aplikace správně nastavena.

Udržujte úsudek odděleně od pozorování. Analýza provozu může naznačit, co tok je, aniž by ho dešifrovala, a to je užitečné zjištění, ale není to totéž tvrzení jako čtení vnitřní hlavičky. Uveďte, které z toho skutečně máte.