Hinaharang ba ng ISP ang UDP, o ang app sa loob ng tunnel?

May nag-uulat na ang VPN ay „naghaharang ng UDP“, at ang pariralang ito ay nagtatago ng dalawang ganap na magkaibang pahayag. Ang isa ay tungkol sa transport na nakikita ng access network, ang isa ay tungkol sa mga packet ng app pagkatapos ma-decrypt sa loob ng tunnel. Ang naka-encrypt na tunnel ay maaaring i-filter mula sa labas nang walang anumang key, at ang panloob na app na UDP ay maaaring mabigo dahil sa mga dahilang walang kinalaman sa pag-filter. Magpasya kung aling pahayag ang sinusubukan mo bago mangolekta ng ebidensya.

Dalawang header, isang salita

Sa isang deployment ng IPsec na may NAT-traversal, ang panlabas na packet ay UDP na naka-address sa pagitan ng dalawang endpoint ng VPN, karaniwang sa port 4500. Sa loob nito, dinadala ng naka-encrypt na payload ang lahat ng ipinapasa ng tunnel, na maaaring TCP o UDP din. Kaya ang salitang UDP ay lumilitaw nang dalawang beses, na may magkaibang kahulugan at magkaibang visibility.

Nakikita ng intermediate network ang panlabas na header at wala sa panloob. Maaari nitong payagan, hubugin o itapon ang panlabas na daloy, at hindi nito kailangang mag-decrypt ng anuman para gawin iyon. Ang asimetriyang iyon ang buong dahilan kung bakit nagkakalito ang dalawang pahayag: ang parehong salita ay naglalarawan sa sinasala ng network at sa ipinapadala ng app. Isulat ang layer sa tabi ng salita sa tuwing nagtatala ka ng natuklasan, at halos nawawala ang kalituhan.

Ang panloob na header ay nagiging nakikita lamang sa tumatanggap na endpoint, pagkatapos ng decryption. Mula sa puntong iyon ang packet ay ipinapasa tulad ng iba pa, alinsunod sa mga ruta, patakaran at sariling pag-filter ng endpoint. Ito ay magkakahiwalay na desisyon na ginagawa ng magkaibang aparato.

Ano ang nakikita pa ng network

Itinatago ng encryption ang payload at ang panloob na transport header, hindi ang katotohanang may daloy. Ang mga address ng endpoint, port, laki ng packet at oras ay nananatiling nakikita, at sapat na iyon upang uriin ang trapiko nang heuristiko o harangin ang isang partikular na destinasyon.

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

Ipinapakita ng unang capture ang panlabas na daloy sa pisikal na interface, at ng pangalawa ang panloob na daloy sa interface ng tunnel. Ang pagpapatakbo ng pareho nang sabay ay direktang sumasagot sa tanong: kung may panlabas na daloy at wala ang panloob, hindi kailanman nagpadala ang app ng anuman sa tunnel. Kung may pareho at walang bumabalik, ang problema ay lampas sa tunnel, sa destinasyon o sa daan pabalik.

RFC 3948 tinutukoy ang panlabas na UDP encapsulation, at tinutukoy ng ESP specification ang protektadong layout sa loob nito. Wala sa dalawang dokumento ang nangangako na papayagan ng access network ang panlabas na daloy, kaya sulit na magpatakbo ng pagsubok sa maabot sa panlabas na tuple bago ang anumang teorya tungkol sa panloob. Ang naharang na panlabas na tuple ay gumagawa ng tunnel na hindi kailanman nabubuo, hindi tunnel na nabubuo at pagkatapos ay nawawalan ng isang app.

Bakit nabigo ang isang UDP app sa loob ng gumaganang tunnel

Ang tunnel na nagdadala ng web app ngunit hindi ng UDP app ay may ilang kapani-paniwalang paliwanag, at ang pag-filter ng panloob na protocol ng ISP ay hindi ang una. Ang pinakakaraniwan ay saklaw: hindi pareho pumapasok ang dalawang app sa isang tunnel, dahil nawawala ang ruta patungo sa destinasyong UDP o ibinubukod ito ng mga patakaran ng split tunnel ng kliyente.

Ang pangalawa ay ang endpoint. Ang VPN server na pumapayag sa listahan ng protocol, firewall sa destinasyon, o serbisyong hindi kailanman nakikinig sa inaasahang port, lahat ay gagawa ng timeout na mukhang katulad ng harang sa network.

Ang pangatlo ay ang laki ng packet. Ang mga UDP app ay madalas magpadala ng mas malaking datagram kaysa sa web request, at binabawasan ng encapsulation ang magagamit na MTU, kaya pagkatapos ng matagumpay na handshake ay maaaring sumunod ang katahimikan sa unang buong-laki na payload. Madaling mabasa nang mali ang pattern na ito bilang harang, dahil pumapasa ang maliliit na packet at nawawala ang malalaki. Ang mabilis na pagsubok sa MTU ay nagtatakda nito sa wala pang isang minuto, at ang sagot ay karaniwang mas maliit na payload o itinamang MSS, hindi filter ng network.

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

Sinusubukan ng unang utos kung nakakalampas ang malaking packet sa daan nang patay ang fragmentation, na mabilis na naglalantad ng problema sa MTU. Ang pangalawa ay nagpapadala ng maliit at limitadong UDP stream at nag-uulat ng pagkawala at jitter. Ang stream na nagsisimula at pagkatapos ay tumitigil ay tumutukoy sa laki, hindi sa harang.

Iulat ang layer, hindi ang protocol

Isulat ang natuklasan sa isa sa tatlong anyo: nabigo ang panlabas na paghahatid, nabigo ang panloob na pagpapasa, o nabigo ang app. Bawat isa ay may magkaibang may-ari, at ang paghahalo sa kanila ay nagpapadala ng ticket sa maling team.

Ang pagpapalit ng lokal na port ay hindi makakagawa ng tugmang listener sa dulong dulo, kaya ang workaround sa panig ng kliyente na tila tumutulong ay karaniwang ebidensya na mali ang orihinal na destinasyon. Gayundin, ang ibinigay na alternatibong profile ay nagpapatunay ng isang bagay tungkol sa maabot at wala tungkol sa kung wasto ang pagkaka-configure ng app.

Ihiwalay ang hinuha sa obserbasyon. Maaaring magmungkahi ang pagsusuri ng trapiko kung ano ang isang daloy nang hindi ito dine-decrypt, at kapaki-pakinabang na natuklasan iyon, ngunit hindi ito ang parehong pahayag sa pagbasa ng panloob na header. Sabihin kung alin sa dalawa ang talagang mayroon ka.