Blokuje ISP UDP, alebo je to aplikácia vnútri tunela?

Niekto hlási, že VPN „blokuje UDP“, a táto fráza skrýva dve úplne odlišné tvrdenia. Jedno sa týka transportu, ktorý vidí prístupová sieť, druhé paketov aplikácie po ich dešifrovaní vnútri tunela. Šifrovaný tunel možno filtrovať zvonku bez akéhokoľvek kľúča a vnútorná UDP aplikácia môže zlyhať z dôvodov, ktoré s filtrovaním nemajú nič spoločné. Rozhodnite, ktoré tvrdenie testujete, skôr než začnete zhromažďovať dôkazy.

Dve hlavičky, jedno slovo

V nasadení IPsec s NAT-traversal je vonkajší paket UDP adresovaný medzi dvoma koncovými bodmi VPN, zvyčajne na porte 4500. Vnútri nesie šifrovaný obsah všetko, čo tunel preposiela, a to samo môže byť TCP alebo UDP. Slovo UDP sa teda objavuje dvakrát, s rôznym významom a rôznou viditeľnosťou.

Medzisieti vidí vonkajšiu hlavičku a z vnútornej nič. Môže vonkajší tok povoliť, tvarovať alebo zahodiť a nemusí na to nič dešifrovať. Táto asymetria je celým dôvodom, prečo sa obe tvrdenia pletú: to isté slovo opisuje to, čo filtruje sieť, aj to, čo posiela aplikácia. Zapisujte k slovu vrstvu vždy, keď zaznamenáte zistenie, a zmätok väčšinou zmizne.

Vnútorná hlavička sa stane viditeľnou až v prijímajúcom koncovom bode, po dešifrovaní. Od tohto okamihu sa paket preposiela ako každý iný, podľa trás, politiky a vlastného filtrovania koncového bodu. To sú samostatné rozhodnutia, ktoré robia rôzne zariadenia.

Čo sieť ešte vidí

Šifrovanie skrýva obsah a vnútornú transportnú hlavičku, nie skutočnosť, že tok existuje. Adresy koncových bodov, porty, veľkosti paketov a časovanie zostávajú viditeľné, a to stačí na heuristickú klasifikáciu prevádzky alebo na zablokovanie konkrétneho cieľa.

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

Prvé zachytenie ukazuje vonkajší tok na fyzickom rozhraní, druhé vnútorný tok na rozhraní tunela. Spustenie oboch naraz odpovedá na otázku priamo: ak vonkajší tok existuje a vnútorný nie, aplikácia do tunela nič neposlala. Ak existujú oba a nič sa nevracia, problém je za tunelom, v cieli alebo na spiatočnej ceste.

RFC 3948 definuje vonkajšie UDP zapuzdrenie a špecifikácia ESP definuje chránené usporiadanie vnútri neho. Ani jeden z dokumentov nesľubuje, že prístupová sieť prepustí vonkajší tok, preto má zmysel vykonať test dosiahnuteľnosti na vonkajšej n-tici pred akoukoľvek teóriou o vnútornej. Zablokovaná vonkajšia n-tica vytvorí tunel, ktorý nikdy nevznikne, nie tunel, ktorý vznikne a potom stratí jednu aplikáciu.

Prečo jedna UDP aplikácia zlyhá vnútri funkčného tunela

Tunel, ktorý prenáša webovú aplikáciu, ale nie UDP aplikáciu, má niekoľko pravdepodobných vysvetlení a filtrovanie vnútorného protokolu ISP nie je prvé. Najčastejšie je to pokrytie: obe aplikácie nevstupujú do toho istého tunela, pretože chýba trasa k cieľu UDP alebo ich vylučujú pravidlá rozdeleného tunela klienta.

Druhý je koncový bod. Server VPN, ktorý povoľuje zoznam protokolov, firewall v cieli alebo služba, ktorá nikdy nepočúva na očakávanom porte, všetky vytvoria časový limit, ktorý vyzerá rovnako ako sieťové zablokovanie.

Tretí je veľkosť paketu. UDP aplikácie často posielajú väčšie datagramy než webová požiadavka a zapuzdrenie zmenšuje použiteľnú MTU, takže po úspešnom handshake môže nasledovať ticho pri prvom plnom obsahu. Tento vzor sa dá ľahko prečítať ako zablokovanie, pretože malé pakety prejdú a veľké zmiznú. Rýchla sonda MTU to vyrieši za menej ako minútu a odpoveďou býva menší obsah alebo opravený MSS, nie sieťový filter.

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

Prvý príkaz testuje, či veľký paket prejde cestou s vypnutou fragmentáciou, čo rýchlo odhalí problém s MTU. Druhý posiela malý ohraničený UDP tok a hlási straty a jitter. Tok, ktorý začne a potom sa zastaví, ukazuje na veľkosť, nie na zablokovanie.

Hlásenie vrstvy, nie protokolu

Zapíšte zistenie v jednej z troch foriem: vonkajšie doručenie zlyhalo, vnútorné preposielanie zlyhalo alebo aplikácia zlyhala. Každá má iného vlastníka a ich zmiešanie pošle tiket nesprávnemu tímu.

Zmena miestneho portu nemôže na vzdialenom konci vytvoriť zodpovedajúci naslúchajúci socket, takže klientske obchádzanie, ktoré vyzerá, že pomáha, je zvyčajne dôkazom, že pôvodný cieľ bol nesprávny. Rovnako dodaný alternatívny profil dokazuje niečo o dosiahnuteľnosti a nič o tom, či je aplikácia správne nastavená.

Udržujte úsudok oddelene od pozorovania. Analýza prevádzky môže naznačiť, čo tok je, bez toho, aby ho dešifrovala, a to je užitočné zistenie, ale nie je to to isté tvrdenie ako čítanie vnútornej hlavičky. Uveďte, ktoré z toho skutočne máte.