OpenVPN sa 443 naka-block pa rin? Tingnan kung ano ang iniinspeksyon ng network

Kumokonekta ang tunnel mula sa linyang pantahanan at natigil sa network ng hotel o opisina, at walang nabago nang ilipat ang server sa port 443. Karaniwan na ang resultang iyon para magkaroon ng hugis: ang port ang madaling bahagi, at ang natitirang desisyon ay pag-aari ng lahat ng nasa pagitan ng client at server. Dalawang tanong ang nagtatapos sa karamihan ng kaso, at wala sa kanila ang tungkol sa cipher. Tumatanggap ba ang network ng TLS handshake papunta sa address na iyon, at pinapanatili ba ng client ang ruta patungo sa sarili nitong pambalot habang nakaangat ang tunnel?

Ibinubunyag ng handshake ang higit sa numero

Ang katutubong tagapakinig ng VPN sa TCP 443 ay nagsasalita ng sarili nitong protocol mula sa unang packet. May field ng bersyon, random na halaga, at listahan ng extension ang ClientHello, at ang device na nagbabasa ng ilang daang byte ay nakikita ang pagkakaiba nang walang idinidiskaril. Murang bigyang-kasiyahan ang mga numero ng port, at ang hugis ng protocol ang talagang sinusuri ng filter. Karaniwang isinusulat din ang mga patakaran ayon sa protocol, kaya ang patakarang nag-iinspeksyon ng TLS ay walang sinasabi tungkol sa UDP.

Ang transparent na proxy na nagpipilit ng valid na TLS session ay bumababa sa koneksyon habang nagse-set up, madalas pagkatapos matapos ang TCP handshake. Mahalaga ang detalyeng iyon mamaya, dahil nangangahulugan itong humihinto ang log ng client pagkatapos maitatag ang socket.

Ang pagbabalot ng daloy ay lumilikha ng dalawang punto ng kabiguan

Ang TLS wrapper tulad ng stunnel ay nagbabalik ng inaasahang hugis: kumokonekta ang client sa lokal na tagapakinig, binubuksan ng wrapper ang tunay na TLS session patungo sa server sa 443, at ang pangalawang wrapper sa server ay nagpapasa ng na-decrypt na byte sa daemon ng VPN. Ang panlabas na session ay mukhang anumang ibang koneksyong HTTPS. Dapat makinig ang daemon ng VPN sa server sa loopback lamang, dahil walang nasa labas ng wrapper ang kailangang makarating dito.

Tatlong magkakaibang bagay ang dapat magtugma para sa disenyong iyon. Itinuturo ng profile ng client ang lokal na tagapakinig, tumutugma ang sertipiko ng server sa pangalang binibigyang-katunayan ng client, at ang pagpapasa sa panig ng server ay naka-target sa port na talagang ginagamit ng daemon. Magkamali sa alinman sa mga ito at namamatay ang koneksyon bago maabot ang antas ng VPN. Lumilitaw noon ang pagkakaiba ng sertipiko bilang error ng wrapper at hindi bilang error ng VPN, at kaya sulit basahin ang dalawang log nang magkatabi.

Ang ruta patungo sa pambalot ay ang bitag

Kapag umangat ang tunnel, ang default na ruta ay tumuturo papasok dito, at ang panlabas na TLS session ay kailangan ng landas na hindi pumapasok sa tunnel na dinadala nito. Ang ordinaryong client ng VPN ay nagpoprotekta sa address na tinatawagan nito; ang nakabalot na client ay tumatawag sa sarili nitong loopback, kaya ang address ng destinasyon ng wrapper ay hindi nakikita ng proteksyong iyon.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Ikaw ang maglalagay ng eksaktong address, at dapat na umiral ang ruta sa buong buhay ng koneksyon, hindi lang sa pagsisimula. Ang maliit na script ng wrapper na nagdadagdag ng ruta bago ang client at nag-aalis nito pagkatapos ay mas maaasahan kaysa sa isang command na naaalala.

Sa Android, ang katumbas ng pagbubukod na iyon ay isang setting sa bawat app: ibukod ang app ng wrapper mula sa tunnel upang lumabas ang sarili nitong trapiko sa koneksyong mobile. Kung walang pagbubukod, ang wrapper ay iruruta papasok sa tunnel na sinusubukan nitong itayo, at ang loop ng muling pagkonekta ay mukhang problema ng server.

Basahin ang tiyempo bago magbago ng anuman

Ang session na namamatay pagkatapos ng parehong agwat sa bawat pagkakataon ay lagda ng patakaran at hindi pagkabigo ng kriptograpiya, at ang pangmatagalang limitasyon ng daloy ay gumagawa ng eksaktong ganoong pattern. Ang koneksyong nire-reset kaagad pagkatapos ng handshake ay nagmumungkahi ng proxy na hindi nagustuhan ang kadena ng sertipiko.

Ihambing ang nagbigay ng sertipiko ng isang ordinaryong HTTPS site mula sa dalawang network. Kung iba ang nagbigay sa pinaghihigpitang network, may isang bagay na tinatapos ang TLS sa gitna, at walang wrapper na makakaligtas sa panghihimasok na iyon nang walang pagbabago. Sinasabi rin ng parehong paghahambing kung ang pagharang ay naka-target sa pangalan ng iyong server o sa bawat TLS session sa address na iyon.

Isulat ang naobserbahang pag-uugali: gaano katagal ang session, bumukas ba ang socket, nag-log ba ang wrapper ng handshake. Ang bawat isa ay nagpapaliit sa susunod na pagsubok.

Subukan ang isang variable sa isang pagkakataon

Suriin muna ang UDP, dahil itinatapon ito ng ilang network nang buo at walang sinasabi ang kabiguan ng UDP tungkol sa 443. Pagkatapos subukan ang TCP 443 na walang wrapper, at pagkatapos ang wrapper sa 443. Basahin ang log ng client sa bawat hakbang at huminto sa sandaling magbago ang pag-uugali.

Baguhin ang isang elemento sa bawat pagtatangka. Ang bagong port, bagong wrapper, at bagong cipher sa isang takbo ay nag-iiwan sa iyong hindi masabi kung alin sa tatlo ang mahalaga.