Pse portali i kapjes bllokon VPN-në tuaj dhe si të hyni përsëri

Në një rrjet të hapur, pika e aksesit nuk i dorëzon thjesht paketat internetit. Një pikë politike më lart verifikon nëse pajisja është autorizuar tashmë, dhe derisa të jetë, pothuajse gjithçka hidhet. Klienti juaj VPN e lexon atë heshtje si një server të vdekur. Rrallë e thotë: WireGuard përsërit një shtrëngim duarsh në zbrazëti, OpenVPN raporton një skadim kohe të lidhjes dhe IKEv2 kthehet si gabim 809 për një server të largët që nuk përgjigjet.

Çfarë kontrollon vërtet portali

Një portal kapjeje janë dy gjëra të ngjitura bashkë: një pikë vendimi politike dhe një ridrejtues. Kur pajisja juaj asociohet dhe merr një qira DHCP, rrjeti ju vendos në një gjendje përpara autorizimit.

Ajo gjendje është një grup rregullash të firewall-it. Zakonisht lejon DNS dhe lejon HTTP ose HTTPS drejt një liste të shkurtër hostesh të portalit, dhe hedh çdo gjë tjetër. Lista e lejuar është kopshti i rrethuar me mure dhe pothuajse kurrë nuk përfshin pikën fundore të VPN-së.

Asnjë nga këto hedhje nuk është e sjellshme. Paketat drejt një serveri VPN hidhen në vend që të refuzohen, kështu që klienti nuk merr as ICMP unreachable as TCP reset, vetëm mungesën e përgjigjes. Në varësi të prodhuesit, ridrejtuesi mund të përgjigjet në portën 80 me një ridrejtim drejt faqes së hyrjes, ndërsa porta 443 hidhet ose përgjohet. Ridrejtimet njihen lehtë sepse mbajnë një përgjigje të thjeshtë HTTP; përgjimi në 443 kërkon një certifikatë që shfletuesi juaj do të refuzojë ta besojë.

Vetë autorizimi zakonisht lidhet me adresën MAC të pajisjes, ndonjëherë me IP-në e marrë me qira, dhe jeton në një tabelë sesionesh me një kohëmatës. Hyrja krijon një zë. Rregulli i firewall-it që lejon trafikun tuaj të kalojë ekziston vetëm sa ekziston ai zë, dhe për këtë arsye i gjithë problemi kthehet më vonë pa ndryshuar asgjë nga ana juaj.

Pse shtrëngimi i duarve i VPN-së vdes përpara se të fillojë

Secili protokoll ka transportin e vet, dhe firewall-i përpara autorizimit e prish secilin ndryshe. IKEv2 në Windows dhe iOS shkon mbi UDP 500 dhe UDP 4500; hedhja në ato porta shfaqet si 809, ose si një dështim i tipit zgjidhje emrash te klientët që raportojnë fazat veçmas. OpenVPN mbi UDP 1194 mbetet në gjendje lidhjeje derisa t'i skadojë koha. OpenVPN mbi TCP 443 është rasti interesant, sepse portali mund të përfundojë shtrëngimin TCP dhe pastaj të përgjigjet me faqen e tij të ridrejtimit, kështu që shihni një gabim TLS në vend të skadimit të kohës.

WireGuard e tregon mekanizmin më qartë. Është vetëm UDP nga ndërtimi, pa alternativë TCP, kështu që një firewall që hedh UDP të panjohur e heq transportin plotësisht. Klienti vazhdon të dërgojë nisje shtrëngimi me pauzë në rritje dhe raporton një shtrëngim që nuk përfundon kurrë. Asgjë në atë mesazh nuk përmend Wi-Fi dhe asgjë në të nuk sugjeron të hapni një shfletues.

Platformat përpiqen ta vënë re gjendjen përpara VPN-së tuaj. Windows merr një URL të njohur për të vendosur nëse shfaq njoftimin e hyrjes, Android kërkon një pikë fundore që duhet të përgjigjet 204 No Content, dhe pajisjet Apple hapin një dritare të vogël të rrjetit të kapjes. Këto sonda funksionojnë sepse portali përgjigjet me një ridrejtim në vend të trupit të pritur. E njëjta sjellje shpjegon si një portal mund të duket plotësisht i shëndetshëm ndërsa tuneli juaj është i vdekur: sonda dhe tuneli gjykohen sipas rregullave të ndryshme.

Çfarë rivendos vërtet skadimi i sesionit

Vendet i mbyllin sesionet për arsye që nuk lidhen me llogarinë tuaj VPN: një skadim kohe pasiviteti, një gjatësi maksimale sesioni, një qira e re DHCP ose një riasocim me një pikë tjetër aksesi. Kur kohëmatësi nis, zëri në tabelën e sesioneve zhduket dhe grupi i rregullave përpara autorizimit kthehet saktësisht siç ishte në regjistrim.

Një tunel i vendosur shpesh mbijeton mjaft gjatë për të dukur i shëndetshëm. Mesazhet e mbajtjes gjallë vazhdojnë të dalin, dhe nëse klienti i vë re varet nga mënyra si trajton trafikun pa përgjigje, kështu që drita e statusit mund të mbetet jeshile edhe për një kohë pasi rruga është zhdukur. Pastaj tuneli bie dhe çdo përpjekje rilidhjeje dështon në të njëjtat porta të bllokuara.

Në atë moment gabimi i klientit ju thotë në çfarë faze jeni, nëse e lexoni me kujdes:

Një detaj i mashtron njerëzit: kur sesioni është i lidhur me një adresë MAC, ringarkimi i faqes së hyrjes mund të mos ndihmojë. Duhet të lini asocimin dhe të ribashkoheni, që portali të shohë një përpjekje të re autorizimi në vend të një të skaduar.

Hyni së pari, pastaj ngrini tunelin

Radha që funksionon është: autorizoni pajisjen, vërtetoni rrugën, nisni VPN-në, vërtetoni tunelin dhe pastaj rivendosni bllokimin tuaj të zakonshëm. Ai hapi i fundit është i rëndësishëm sepse gjendja e përkohshme që ju nevojitet për të arritur portalin është pikërisht gjendja që ekziston një çelës sigurie për ta parandaluar.

Një klient desktopi me mundësinë për të bllokuar jashtë tunelit duhet të ndalet që faqja e portalit të ngarkohet, dhe aplikacionet e ndjeshme duhen mbajtur të mbyllura në atë dritare jashtë tunelit; është intervali i vetëm kur trafiku lokal del pa mbrojtje. Një pajisje e administruar gjithmonë e ndezur duhet të përdorë procedurën e publikuar nga pronari në vend që të hiqni ju politikën. Nëse portali shfaq një paralajmërim certifikate, ndaloni: pranimi i saj e kalon sesionin tuaj përmes përfaqësuesit përgjues të vendit, dhe ai përfaqësues mund të lexojë gjithçka që dërgoni. Në Android, bllokimi nën VPN gjithmonë aktive e ndal trafikun përpara se tuneli të ngrihet, dhe disa ndërtime nuk mund të përjashtojnë rrjedhën e portalit; nëse e juaja nuk mundet, përdorni aksesin alternativ të vendit ose një pajisje tjetër në vend që ta lini bllokimin të fikur. Rregullat on-demand të Apple mund të shkruhen për të refuzuar tunelin derisa një sondë të ketë sukses, dhe kjo është sjellja që dëshironi në rrjetet e hoteleve.

Verifikoni me radhë me mjetet që keni tashmë. Përpara tunelit ekzekutoni sondën me titujt dhe trupi të dy të dukshëm, dhe shikoni nëse transporti juaj VPN merr ndonjë përgjigje:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Përpara autorizimit, një portal normal jep një nga dy përgjigje: një 302, Location e të cilit tregon faqen e hyrjes, ose një 200 me një trup HTML që është faqja e portalit. Shënoni cilën morët. Një ridrejtim përpara hyrjes nuk është dështim; portali po ju thotë ku të shkoni. Pasi portali raporton sukses, përsëritni komandën dhe prisni një 200, trupi i të cilit është fjalë për fjalë fjala Success. Ai varg është ai që e bën sondën kuptimplotë. Nëse hosti përgjigjet normalisht përpara se të keni hyrë ndonjëherë, në këtë rrjet nuk ka portal përgjimi. Në kapje, hedhja përpara autorizimit janë paketa dalëse nga të cilat nuk kthehet asgjë, ndërsa një rrugë që funksionon tregon një përgjigje për të njëjtën rrjedhë brenda rreth një sekonde. Lidhuni dhe pastaj përsëritni kapjen.

Nëse tuneli vazhdon të dështojë pasi portali thotë po

Suksesi i hyrjes nuk është i njëjtë me transportin e lejuar. Shumë vende lejojnë portalin dhe shfletimin normal por bllokojnë plotësisht UDP, gjë që i lë WireGuard dhe OpenVPN mbi UDP të prishur dhe TCP 443 funksionon. Nëse TCP 443 kalon dhe UDP nuk kalon, është politika e vendit dhe jo një klient i konfiguruar gabimisht nga ju, kështu që ndryshoni transportin ose pranoni kufizimin dhe vazhdoni. Nëse një rilidhje vazhdon të dështojë pas kësaj, ruani gabimin e saktë; ai emërton fazën ku jeni bllokuar.

Dështimet e tjera jetojnë në pajisje. Një sesion ende i lidhur me një MAC të vjetër, një përshtatës i dytë Wi-Fi me qiranë e vet, ose një klient që ka ruajtur përjashtimin e certifikatës së portalit mund të vazhdojnë të dështojnë pas një riautorizimi të pastër. Lini asocimin, autorizoni përsëri dhe provoni një herë përpara se të prekni cilësimet e klientit. RFC 8952 ia vlen të lexohet nëse dëshironi arkitekturën pas komponentëve që vëzhgoni.

Nëse vetë portali refuzon të autorizojë, problemi është në llogari ose në ndarjen e pajisjes dhe asnjë cilësim VPN nuk e rregullon. Ndryshimi i vendit të daljes së VPN-së nuk e rivendos gjendjen lokale të aksesit të vendit; ajo tabelë lidhet me pajisjen tuaj, jo me serverin që zgjidhni. Pyetni operatorin e vendit dhe jepini kohë, sepse tabela e sesioneve është ajo që do të shikojë.

Përpara udhëtimit të radhës shënoni tri gjëra: faqen e portalit si hapin zero, hapin e ndalimit të bllokimit për secilën pajisje që merrni me vete, dhe një transport rezervë që e keni provuar vërtet. Kur një tunel që funksiononte dhjetë minuta më parë ndalon përsëri, trajtojeni si një autorizim të skaduar dhe kontrolloni portalin përsëri përpara se të prekni profilin VPN.