VPN i bllokuar në një rrjet vetëm web? Punoni shtresat

Një rrjet kampusi ose hoteli ku shfletuesi punon dhe çdo tunel vdes nuk është një problem, janë katër të mbivendosur. Rruga mund të lejojë vetëm TCP 443, të kërkojë një proxy të vërtetuar, të inspektojë shtrëngimin e duarve ose thjesht të ndalojë aksesin në distancë me politikë. Përpunimi i tyre me radhë ju shmang nga blerja e një klienti të ri për të rregulluar një rregull rrjeti. Udhëzuesi më poshtë merr rreth dhjetë minuta dhe përfundon me një përgjigje të shkruar se cila shtresë ju refuzoi.

Vërtetoni cila shtresë e refuzon lidhjen

Mos filloni me klientin VPN. Filloni me një kërkesë të thjeshtë HTTPS drejt të njëjtit host dhe lexoni fazat e kohës, sepse faza që dështon ju thotë cili pajisje është përgjegjëse:

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

Pa përgjigje dhe pa kohë connect do të thotë që TCP nuk përfundoi kurrë, ndaj në lojë është një mur zjarri, një kërkesë proxy ose një destinacion i gabuar. Koha connect pa kohë tls do të thotë që diçka në mes e pranoi lidhjen dhe më pas e ndaloi shtrëngimin e duarve, dhe kështu duket një proxy inspektues nga ana e klientit.

Tani inspektoni certifikatën që merrni vërtet. Ky është mënyra më e shpejtë për të zbuluar nëse po flisni me serverin apo me një kuti të ndërmjetme që e nënshkroi sesionin përsëri:

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

Lexoni rreshtin e lëshuesit. CA-ja juaj do të thotë që arritët shërbimin; një lëshues korporativ ose pajisjeje do të thotë që një filtër e përfundoi lidhjen dhe po vendos çfarë ndodh më pas. Regjistroni të dyja daljet me vulë kohore, sepse i njëjti test një orë më vonë në rrjetin e mysafirëve mund të japë një përgjigje tjetër.

Një klient i vetëdijshëm për proxy-n ndryshon paketën e parë, jo politikën

Nëse rrjeti kërkon CONNECT përmes një proxy të vërtetuar, klienti VPN duhet të informohet, përndryshe do të përpiqet të hapë një socket drejt një adrese që nuk mund ta rutojë. Testoni proxy-në veçmas nga klienti, që dështimi të ketë një shpjegim:

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

Komanda e parë vërteton që proxy-ja do të mbajë destinacionin. E dyta i kërkon klientit të përdorë TCP në 443, i vetmi transport që shumica e rrugëve vetëm web e kalojnë fare. Nëse e para ka sukses dhe e dyta dështon ende, proxy-ja nuk është pengesa.

Disa klientë lexojnë proxy-në e sistemit operativ në vend të një zëvendësimi, dhe disa nuk lexojnë asnjërën. Kontrolloni dokumentacionin e aplikacionit përpara se të supozoni se një cilësim i sistemit zbatohet. Një klient që e zgjidh pikën fundore përmes një zgjidhësi që proxy-ja nuk e shërben do të dështojë edhe këtu, dhe për këtë arsye një ndryshim DNS mund të duket si rregullim kur është vetëm një devijim.

Vini re edhe modelin e drejtimit. Një rrjet i filtruar mund t'i përgjigjet emrit të hostit të zbulimit të një furnizuesi me diçka të vetën, gjë që ndryshon cilin profil proxy zgjedh klienti. Mos ndërtoni një proces rreth asaj veçantie. Ajo ndryshon sipas vendit, ndryshon pa njoftim dhe nuk është diçka që mund ta mbështesni për dikë tjetër.

Porta 443 është e arritshme, jo e lejuar

Mbështjellja e një tuneli në TLS në 443 zgjidh arritshmërinë dhe asgjë tjetër. Një filtër që kontrollon portën do ta lërë të kalojë; një filtër që merr gjurmën e shtrëngimit të duarve nuk do ta lërë, dhe përshëndetja e kriptuar e klientit e fsheh emrin e serverit vetëm kur të dy skajet e mbështesin. Ekzekutoni testin dhe zbuloni pas çfarë lloj filtri jeni në vend që të shpresoni.

Ka edhe një kosto performance që njerëzit e zbulojnë më vonë. Një transport i besueshëm brenda një transporti të besueshëm amplifikon humbjen, sepse stiva e brendshme ritransmeton segmente që stiva e jashtme i ka ritransmetuar tashmë. Në një lidhje të pastër askush nuk e vë re. Në një rrjet pa tela kampusi të mbingarkuar tuneli bëhet i papërdorshëm pikërisht kur ju nevojitet, dhe grafiku duket si humbje paketash edhe pse asgjë nuk hidhet poshtë me qëllim.

UDP është zakonisht viktima e parë, dhe ia vlen ta konfirmoni në vend që ta hamendësoni. Nëse WireGuard ose OpenVPN i parazgjedhur nuk e përfundon kurrë shtrëngimin e duarve ndërsa TCP 443 punon, rrjeti po i hedh UDP-në, dhe asnjë rigjenerim çelësash nuk do ta ndryshojë këtë:

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

Një vulë kohore e zbrazët e shtrëngimit të duarve pranë një partneri që punonte dje është përgjigjja e UDP-së. Dy pyetjet DNS i përgjigjen një pyetjeje tjetër: nëse zgjidhësi lokal dhe një zgjidhës publik nuk bien dakord për adresën e pikës fundore, ju po drejtoheni dhe argumenti i transportit është i gabuari.

Verifikoni çfarë la vërtet makina

Regjistrat e klientit përshkruajnë atë që klienti beson. Një kapje përshkruan atë që pa rrjeti, dhe ndryshimi mes të dyjave është vendi ku zgjidhet shumica e këtyre rasteve:

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

Nëse shihni paketa SYN dhe asnjë SYN-ACK, bllokimi është më lart dhe klienti është i pafajshëm. Nëse shihni një shtrëngim duarsh të përfunduar drejt një adrese që nuk është e serverit, po flisni me një proxy ose një përgjues. Nëse nuk shihni asgjë, kontrolloni se kapët në ndërfaqen e duhur përpara se të nxirrni ndonjë përfundim.

Lista e socket-ëve kap një rast më delikat: një tunel i dytë që mban tashmë rrugën e parazgjedhur. Dy klientë që zihen për tabelën e rrugëtimit prodhojnë dështime të herëpashershme që duken saktësisht si një rrjet i bllokuar, dhe kapja do të tregojë trafik që del përmes një ndërfaqeje që nuk e prisnit.

Kthimi pas dhe shënimi që ia vlen të mbahet

Zhbëni ndryshimet në rendin e kundërt të atij në të cilin i bëtë. Hiqni variablat e proxy-së, ndaloni klientin që e nisët me dorë dhe hiqni çdo zëvendësim rruge ose zgjidhësi që shtuat:

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

Lënia e një klienti të nisur me dorë në punë është mënyra se si një laptop përfundon me rrjet të prishur në vizitën tjetër në zyrë. Variablat e proxy-së të lëna në një profil shell prishin mjete të palidhura javë më vonë, dhe personi që i korrigjon nuk do t'i lidhë dy ngjarjet.

Më pas shkruani katër rreshta: rrjeti, vula kohore, faza që dështoi dhe lëshuesi që patë. Një rrugë që punon në një kampus dhe dështon në tjetrin është normale, dhe personi tjetër duhet të dijë nëse ndryshimi ishte proxy-ja, zgjidhësi apo filtri. Nëse përgjigjja është se rrjeti ndalon aksesin në distancë, ndaloni aty dhe pyesni administratorin për rrugën e mbështetur në vend që të mbani një devijim në një politikë që nuk e keni lexuar.