Ĉu la ISP blokas UDP, aŭ ĉu estas la aplikaĵo ene de la tunelo?

Iu raportas, ke la VPN „blokas UDP“, kaj tiu frazo kaŝas du tute malsamajn asertojn. Unu temas pri la transporto, kiun la alira reto povas vidi, la alia pri la pakaĵoj de aplikaĵo post kiam ili estas malĉifritaj ene de la tunelo. Ĉifrita tunelo povas esti filtrita de ekstere sen ajna ŝlosilo, kaj interna UDP-aplikaĵo povas malsukcesi pro kialoj tute ne rilataj al filtrado. Decidu, kiun aserton vi testas, antaŭ ol kolekti pruvojn.

Du kaplinioj, unu vorto

En IPsec-aranĝo kun NAT-traversal, la ekstera pakaĵo estas UDP, adresita inter la du VPN-finpunktoj, kutime sur pordo 4500. Ene de ĝi, la ĉifrita utilaĵo portas ĉion, kion la tunelo plusendas, kio mem povas esti TCP aŭ UDP. La vorto UDP do aperas dufoje, kun malsama signifo kaj malsama videbleco.

Intera reto vidas la eksteran kaplinion kaj nenion de la interna. Ĝi povas permesi, formi aŭ forĵeti la eksteran fluon, kaj ĝi ne bezonas malĉifri ion ajn por fari tion. Tiu malsimetrio estas la tuta kialo, kial la du asertoj konfuziĝas: la sama vorto priskribas tion, kion la reto filtras, kaj tion, kion la aplikaĵo sendas. Skribu la tavolon apud la vorto ĉiam, kiam vi registras trovanton, kaj la konfuzo plejparte malaperas.

La interna kaplinio videblas nur ĉe la ricevanta finpunkto, post malĉifrado. De tiu punkto la pakaĵo estas plusendata kiel ĉiu alia, laŭ itineroj, politiko kaj la propra filtrado de la finpunkto. Tiuj estas apartaj decidoj faritaj de malsamaj aparatoj.

Kion la reto ankoraŭ povas vidi

Ĉifrado kaŝas la utilaĵon kaj la internan transportan kaplinion, ne la fakton, ke fluo ekzistas. Finpunktaj adresoj, pordoj, pakaĵgrandoj kaj tempo restas videblaj, kaj tio sufiĉas por heŭristike klasifiki trafikon aŭ bloki specifan celon.

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

La unua kapto montras la eksteran fluon sur la fizika interfaco, kaj la dua montras la internan fluon sur la tunela interfaco. Ruli ambaŭ samtempe respondas la demandon rekte: se la ekstera fluo ekzistas kaj la interna ne, la aplikaĵo neniam sendis ion en la tunelon. Se ambaŭ ekzistas kaj nenio revenas, la problemo estas preter la tunelo, ĉe la celo aŭ sur la revena vojo.

RFC 3948 difinas la eksteran UDP-enkapsuligon, kaj la ESP-specifikaĵo difinas la protektitan aranĝon ene de ĝi. Neniu el la du dokumentoj promesas, ke alira reto trapasigos la eksteran fluon, kaj tial indas ruli atingoprovon sur la ekstera opo antaŭ ol havi ajnan teorion pri la interna. Blokita ekstera opo produktas tunelon, kiu neniam formiĝas, ne tunelon, kiu formiĝas kaj poste perdas unu aplikaĵon.

Kial unu UDP-aplikaĵo malsukcesas ene de funkcianta tunelo

Tunelo, kiu portas retejan aplikaĵon sed ne UDP-aplikaĵon, havas plurajn kredindajn klarigojn, kaj filtrado de la interna protokolo fare de la ISP ne estas la unua. La plej ofta estas kovrado: la du aplikaĵoj ne ambaŭ eniras la saman tunelon, ĉar la itinero al la UDP-celo mankas aŭ la reguloj de dividita tunelo de la kliento ekskludas ĝin.

La dua estas la finpunkto. VPN-servilo, kiu permesas protokololiston, fajroŝirmilo ĉe la celo, aŭ servo, kiu neniam aŭskultas sur la atendata pordo, ĉiuj produktos tempolimon, kiu aspektas idente al reta blokado.

La tria estas pakaĵgrandeco. UDP-aplikaĵoj ofte sendas pli grandajn datagramojn ol reteja peto, kaj enkapsuligo malpliigas la uzeblan MTU, do post sukcesa manpremo povas sekvi silento ĉe la unua plengranda utilaĵo. Tiu ŝablono facile mislegiĝas kiel blokado, ĉar la malgrandaj pakaĵoj sukcesas kaj la grandaj malaperas. Rapida MTU-provo solvas tion en malpli ol minuto, kaj la respondo kutime estas pli malgranda utilaĵo aŭ korektita MSS, ne reta filtro.

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

La unua komando testas, ĉu granda pakaĵo postvivas la vojon kun fragmentado malŝaltita, kio rapide malkaŝas MTU-problemon. La dua sendas malgrandan, limigitan UDP-fluon kaj raportas perdon kaj ĵiteron. Fluo, kiu komenciĝas kaj poste haltas, indikas grandon, ne blokadon.

Raportu la tavolon, ne la protokolon

Skribu la trovanton en unu el tri formoj: ekstera liverado malsukcesis, interna plusendado malsukcesis, aŭ la aplikaĵo malsukcesis. Ĉiu havas malsaman posedanton, kaj miksado sendas la bileton al la malĝusta teamo.

Ŝanĝi lokan pordon ne povas krei kongruan aŭskultanton ĉe la malproksima fino, do klientflanka solvo, kiu ŝajne helpas, kutime estas pruvo, ke la origina celo estis malĝusta. Same, liverita alternativa profilo pruvas ion pri atingeblo kaj nenion pri tio, ĉu la aplikaĵo estas ĝuste agordita.

Tenu inferencon aparte de observado. Trafika analizo povas sugesti, kio estas fluo, sen malĉifri ĝin, kaj tio estas utila trovanto, sed ĝi ne estas la sama aserto kiel legi la internan kaplinion. Deklaru, kiun vi efektive havas.