Naka-block ang VPN sa web-only na network? Isa-isahin ang mga layer

Ang campus o hotel network kung saan gumagana ang browser at namamatay ang bawat tunnel ay hindi isang problema, apat na nakapatong. Maaaring pinapayagan lang ng landas ang TCP 443, humihingi ng authenticated na proxy, sinusuri ang handshake, o basta ipinagbabawal ng patakaran ang malayong pag-access. Ang pagsunod-sunod sa kanila ay pumipigil sa iyo na bumili ng bagong client para ayusin ang isang tuntunin ng network. Ang gabay sa ibaba ay tumatagal ng mga sampung minuto at nagtatapos sa nakasulat na sagot kung aling layer ang tumanggi sa iyo.

Patunayan kung aling layer ang tumatanggi sa koneksyon

Huwag magsimula sa VPN client. Magsimula sa payak na HTTPS request sa parehong host at basahin ang mga timing phase, dahil ang phase na nabibigo ang nagsasabi kung aling device ang responsable:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Walang tugon at walang connect time ay nangangahulugang hindi kailanman natapos ang TCP, kaya may firewall, pangangailangan sa proxy o maling destinasyon sa laro. May connect time nang walang tls time ay nangangahulugang may tumanggap ng koneksyon sa gitna at pagkatapos ay hininto ang handshake, at ganyan ang hitsura ng inspecting proxy mula sa panig ng client.

Ngayon suriin ang certificate na talagang natatanggap mo. Ito ang pinakamabilis na paraan para malaman kung kausap mo ang server o isang gitnang kahon na muling pumirma sa session:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Basahin ang linya ng issuer. Ang sarili mong CA ay nangangahulugang naabot mo ang serbisyo; ang corporate o device issuer ay nangangahulugang tinapos ng filter ang koneksyon at ito ang nagpapasya kung ano ang susunod. I-record ang parehong output na may timestamp, dahil ang parehong pagsubok makalipas ang isang oras sa guest network ay maaaring magbigay ng ibang sagot.

Ang client na may kamalayan sa proxy ay nagbabago ng unang packet, hindi ang patakaran

Kung kailangan ng network ang CONNECT sa pamamagitan ng authenticated na proxy, dapat sabihin sa VPN client, kung hindi ay susubukan nitong magbukas ng socket sa address na hindi nito kayang i-route. Subukan ang proxy nang hiwalay sa client, upang ang kabiguan ay may isang paliwanag:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Pinatutunayan ng unang utos na dadalhin ng proxy ang destinasyon. Hinihiling ng pangalawa sa client na gumamit ng TCP sa 443, ito lang ang transport na ipinapasa ng karamihan ng web-only na landas. Kung nagtagumpay ang una at nabigo pa rin ang pangalawa, hindi ang proxy ang hadlang.

May mga client na binabasa ang proxy ng operating system sa halip na override, at may hindi binabasa ang alinman. Suriin ang dokumentasyon ng application bago ipagpalagay na nalalapat ang system-wide na setting. Ang client na nagre-resolve ng endpoint sa pamamagitan ng resolver na hindi pinaglilingkuran ng proxy ay mabibigo rin dito, kaya ang pagbabago ng DNS ay maaaring magmukhang pag-aayos kapag ito ay liko lamang.

Pansinin din ang pattern ng pag-steer. Ang na-filter na network ay maaaring tumugon sa detection hostname ng vendor ng sarili nitong bagay, na nagbabago kung aling proxy profile ang pipiliin ng client. Huwag magtayo ng proseso sa paligid ng kakaibang iyon. Nag-iiba ito sa bawat site, nagbabago nang walang abiso, at hindi ito isang bagay na maaari mong suportahan para sa ibang tao.

Ang port 443 ay naaabot, hindi pinapayagan

Ang pagbabalot ng tunnel sa TLS sa 443 ay nag-aayos ng pagkaaabot at wala nang iba. Ang filter na nagsusuri ng port ay palalampasin ito; ang filter na kumukuha ng fingerprint ng handshake ay hindi, at ang encrypted na client hello ay nagtatago ng pangalan ng server lamang kapag sinusuportahan ito ng magkabilang dulo. Patakbuhin ang pagsubok at alamin kung anong uri ng filter ang nasa likuran mo sa halip na umasa.

Mayroon ding gastos sa performance na natutuklasan ng mga tao mamaya. Ang maaasahang transport sa loob ng maaasahang transport ay nagpapalaki ng pagkawala, dahil ang panloob na stack ay muling nagpapadala ng mga segment na naipadala na ng panlabas na stack. Sa malinis na link walang nakakapansin. Sa siksikang campus wireless, nagiging walang silbi ang tunnel sa eksaktong sandaling kailangan mo ito, at ang graph ay mukhang packet loss kahit walang sadyang itinatapon.

Ang UDP ay karaniwang unang biktima, at sulit itong kumpirmahin sa halip na hulaan. Kung ang WireGuard o default na OpenVPN ay hindi kailanman nagtatapos ng handshake habang gumagana ang TCP 443, ibinabagsak ng network ang UDP, at walang muling pagbuo ng key ang makakabago niyon:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Ang walang laman na timestamp ng handshake sa tabi ng peer na gumana kahapon ay ang sagot ng UDP. Ang dalawang DNS query ay sumasagot sa ibang tanong: kung hindi magkasundo ang lokal na resolver at pampublikong resolver tungkol sa address ng endpoint, ginagabayan ka at mali ang argumento tungkol sa transport.

I-verify kung ano talaga ang umalis sa makina

Inilalarawan ng mga log ng client kung ano ang pinaniniwalaan ng client. Inilalarawan ng capture kung ano ang nakita ng network, at ang pagkakaiba ng dalawa ang lugar kung saan nalulutas ang karamihan sa mga kasong ito:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Kung nakakita ka ng SYN packets at walang SYN-ACK, nasa upstream ang block at inosente ang client. Kung nakakita ka ng kumpletong handshake sa address na hindi sa server, kausap mo ang proxy o interceptor. Kung wala kang makita, tingnan kung nakakuha ka sa tamang interface bago maghinuha ng anuman.

Nahuhuli ng socket list ang mas banayad na kaso: isang pangalawang tunnel na may hawak na ng default route. Ang dalawang client na nag-aagawan sa routing table ay gumagawa ng pasulpot-sulpot na kabiguan na eksaktong mukhang naka-block na network, at ang capture ay magpapakita ng trapikong lumalabas sa interface na hindi mo inaasahan.

Pag-rollback, at ang tala na sulit itago

Ibalik ang mga pagbabago sa kabaligtarang pagkakasunod-sunod ng ginawa mo. Alisin ang mga proxy variable, itigil ang client na sinimulan mo nang manwal, at alisin ang anumang route o resolver override na idinagdag mo:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Ang pag-iwan sa client na sinimulan nang manwal na tumatakbo ay kung paano nauuwi ang laptop na may sirang network sa susunod na pagbisita sa opisina. Ang mga proxy variable na naiwan sa shell profile ay sisira ng walang kaugnayang tool pagkalipas ng mga linggo, at ang taong nagde-debug sa mga ito ay hindi maiuugnay ang dalawang pangyayari.

Pagkatapos ay sumulat ng apat na linya: ang network, ang timestamp, ang phase na nabigo, at ang issuer na nakita mo. Ang landas na gumagana sa isang campus at nabibigo sa susunod ay normal, at ang susunod na tao ay kailangang malaman kung ang pagkakaiba ay ang proxy, ang resolver o ang filter. Kung ang sagot ay ipinagbabawal ng network ang malayong pag-access, huminto doon at tanungin ang administrator tungkol sa sinusuportahang ruta sa halip na magdala ng liko sa isang patakarang hindi mo pa nabasa.