Blochează ISP-ul UDP sau este aplicația din interiorul tunelului?

Cineva raportează că VPN-ul „blochează UDP“, iar această frază ascunde două afirmații complet diferite. Una privește transportul pe care îl vede rețeaua de acces, cealaltă pachetele unei aplicații după ce au fost decriptate în interiorul tunelului. Un tunel criptat poate fi filtrat din exterior fără nicio cheie, iar o aplicație UDP internă poate eșua din motive care nu au nimic de-a face cu filtrarea. Decide ce afirmație testezi înainte de a aduna dovezi.

Două anteturi, un singur cuvânt

Într-o implementare IPsec cu NAT-traversal, pachetul exterior este UDP, adresat între cele două capete ale VPN-ului, de obicei pe portul 4500. În interiorul lui, încărcătura criptată transportă tot ce transmite tunelul, iar aceasta poate fi ea însăși TCP sau UDP. Cuvântul UDP apare deci de două ori, cu sens și vizibilitate diferite.

O rețea intermediară vede antetul exterior și nimic din cel interior. Poate permite, modela sau elimina fluxul exterior și nu trebuie să decripteze nimic pentru asta. Această asimetrie este întregul motiv pentru care cele două afirmații se confundă: același cuvânt descrie ce filtrează rețeaua și ce trimite aplicația. Notează stratul lângă cuvânt ori de câte ori înregistrezi o constatare, iar confuzia dispare în mare parte.

Antetul interior devine vizibil doar la capătul receptor, după decriptare. Din acel moment pachetul este transferat ca oricare altul, în funcție de rute, politică și filtrarea proprie a capătului. Sunt decizii separate luate de echipamente diferite.

Ce mai poate vedea rețeaua

Criptarea ascunde încărcătura și antetul de transport interior, nu faptul că există un flux. Adresele capetelor, porturile, dimensiunile pachetelor și momentul rămân vizibile, iar acestea sunt suficiente pentru a clasifica traficul euristic sau pentru a bloca o destinație anume.

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

Prima captură arată fluxul exterior pe interfața fizică, iar a doua arată fluxul interior pe interfața tunelului. Rularea ambelor simultan răspunde direct la întrebare: dacă fluxul exterior există și cel interior nu, aplicația nu a trimis niciodată nimic în tunel. Dacă ambele există și nimic nu se întoarce, problema este dincolo de tunel, la destinație sau pe calea de întoarcere.

RFC 3948 definește încapsularea UDP exterioară, iar specificația ESP definește dispunerea protejată din interiorul ei. Niciunul dintre cele două documente nu promite că o rețea de acces va lăsa fluxul exterior să treacă, de aceea merită rulat un test de accesibilitate pe tuplul exterior înainte de orice teorie despre cel interior. Un tuplu exterior blocat produce un tunel care nu se formează niciodată, nu un tunel care se formează și apoi pierde o aplicație.

De ce o aplicație UDP eșuează într-un tunel funcțional

Un tunel care transportă o aplicație web dar nu o aplicație UDP are mai multe explicații plauzibile, iar filtrarea protocolului interior de către ISP nu este prima. Cea mai frecventă este acoperirea: cele două aplicații nu intră amândouă în același tunel, pentru că lipsește ruta către destinația UDP sau regulile de tunel divizat ale clientului o exclud.

A doua este capătul. Un server VPN care permite o listă de protocoale, un firewall la destinație sau un serviciu care nu ascultă niciodată pe portul așteptat vor produce toate un timeout care arată identic cu un blocaj de rețea.

A treia este dimensiunea pachetului. Aplicațiile UDP trimit adesea datagrame mai mari decât o cerere web, iar încapsularea reduce MTU-ul utilizabil, așa că după un handshake reușit poate urma liniște la prima încărcătură de dimensiune completă. Acest model este ușor de citit greșit ca blocaj, pentru că pachetele mici trec și cele mari dispar. O sondă rapidă MTU lămurește lucrurile în mai puțin de un minut, iar răspunsul este de obicei o încărcătură mai mică sau un MSS corectat, nu un filtru de rețea.

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

Prima comandă testează dacă un pachet mare supraviețuiește pe traseu cu fragmentarea dezactivată, ceea ce expune rapid o problemă de MTU. A doua trimite un flux UDP mic și limitat și raportează pierderi și jitter. Un flux care începe și apoi se oprește indică dimensiunea, nu un blocaj.

Raportează stratul, nu protocolul

Scrie constatarea într-una din trei forme: livrarea exterioară a eșuat, transferul intern a eșuat sau aplicația a eșuat. Fiecare are alt responsabil, iar amestecarea lor trimite tichetul la echipa greșită.

Schimbarea unui port local nu poate crea un ascultător potrivit la capătul îndepărtat, așa că o soluție ocolitoare pe partea clientului care pare să ajute este de obicei dovada că destinația inițială era greșită. La fel, un profil alternativ furnizat dovedește ceva despre accesibilitate și nimic despre dacă aplicația este configurată corect.

Ține inferența separată de observație. Analiza traficului poate sugera ce este un flux fără a-l decripta, iar aceasta este o constatare utilă, dar nu este aceeași afirmație cu citirea antetului interior. Precizează pe care dintre ele o ai de fapt.