Wi-Fi i hotelit: VPN dështon përpara se të arrijë te serveri
Tuneli dështon sepse portali i kapjes nuk ju ka autorizuar ende. Hyni në rrjetin e hotelit, konfirmoni se HTTPS i zakonshëm funksionon dhe më pas lidhni VPN.
Klienti VPN rrotullohet, më pas raporton se nuk mund të arrijë te serveri, dhe të gjithë përfundojnë se hoteli bllokon VPN-të. Zakonisht nuk ka ndodhur asgjë kaq dramatike: rrjeti nuk ju ka lënë ende të dilni. Një portal kapjeje mban çdo lidhje derisa të hyni, dhe një tunel nuk mund të përfundojë ndërsa një faqe hyrjeje përgjon paketat e tij. Kaloni hyrjen përpara se të fajësoni tunelin.
Miti: hoteli bllokon VPN-të
Shumica e rrjeteve të hoteleve nuk i filtrojnë tunelët në mënyrë të veçantë. Ata përgjojnë trafikun e uebit derisa mysafiri të autentifikohet, dhe mund të kufizojnë pajisjet, të mbyllin sesionet ose të ulin shpejtësinë. Secili prej tyre prodhon një defekt që nga brenda një klienti VPN duket si bllokim.
Tuneli është këtu një mjet i dobët diagnostikimi, sepse është aplikacioni i vetëm që dështon me siguri ndërsa portali nuk është i autorizuar. Qasja normale në ueb është treguesi më i mirë, sepse mund t'ju tregojë vetë faqen e hyrjes.
Ky rend ka rëndësi edhe për një arsye tjetër: një klient me çelës ndalimi ose modalitet gjithmonë aktiv do të refuzojë të ngarkojë portalin, dhe përdoruesi do të përfundojë se është prishur rrjeti, jo cilësimi. Të dyja faktet janë të vërteta njëkohësisht, dhe vetëm njëra mund të ndryshohet në hotel. Fikni mbrojtjen përmes kontrollit të vetë klientit, hyni dhe më pas riaktivizojeni. Çdo gjë tjetër është një shmangie që fsheh sekuencën reale.
Përfundoni së pari portalin, pastaj provoni HTTPS normal
Pyetni stafin për emrin zyrtar të rrjetit dhe metodën e hyrjes. Një SSID bindës nuk është provë pronësie, dhe një rrjet i dytë me emër të ngjashëm është një mashtrim i zakonshëm në vendet publike. Përdorni kërkesën e hyrjes të vetë sistemit operativ kur ofrohet, ose faqen e dokumentuar të hotelit.
curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/Kërkesa e parë pyet një pikë të njohur zbulimi të portalit të kapjes përmes HTTP të thjeshtë; një ridrejtim ose trup i papritur do të thotë se jeni ende pas portalit. E dyta teston një sajt normal HTTPS. Nëse e para tregon përgjim dhe e dyta dështon, hyrja është e paplotë dhe VPN nuk ka të bëjë fare.
Në një pajisje personale mund të duhet të fikni çelësin e ndalimit ose VPN-në gjithmonë aktive përmes kontrollit të mbështetur të klientit që portali të mund të ngarkohet. Mbyllni aplikacionet e ndjeshme në atë interval dhe riaktivizoni mbrojtjen menjëherë pas. Në një pajisje të menaxhuar, ndiqni procedurën e miratuar nga administratori në vend që të hiqni vetë një politikë.
Kurrë mos anashkaloni një paralajmërim certifikate dhe mos instaloni një certifikatë të panjohur ose aplikacion ndihmës për të shkuar online. Nëse portali kërkon diçka të papritur, konfirmojeni me stafin, dhe me administratorin nëse pajisja i përket një punëdhënësi.
Ruani profilin origjinal dhe gabimin e tij
Pasi qasja normale të funksionojë, lidhni profilin origjinal dhe shënoni gabimin e saktë. Refuzimi i autentikimit është problem llogarie, skadimi i kohës gjatë negociimit është problem rruge, dhe një tunel që vendoset por nuk transporton asgjë është problem rrugëtimi ose politike.
Këto të tre kërkojnë hapa të ndryshëm, dhe një pamje ekrani e gabimit vlen më shumë se një përshkrim. Shënoni edhe orën, sepse kufijtë e sesionit të hotelit mund të skadojnë brenda një ore dhe të prodhojnë një defekt që duket i rastësishëm. Nëse klienti ofron një regjistër, mbani pjesën rreth defektit të parë dhe jo të gjithë skedarin. Ai fragment zakonisht mjafton për pronarin e profilit për të identifikuar fazën.
Nëse qasja normale funksionon dhe negociimi ende skadon, pyetni hotelin nëse e mbështet atë trafik, dhe krahasoni me një hotspot të besuar duke mbajtur pajisjen dhe profilin të pandryshuar. Puna në hotspot e përqendron vëmendjen te rruga e hotelit pa provuar asgjë për profilin.
Përdorni vetëm alternativat që ofron operatori
Një profil TCP përputhës mund të ketë sukses aty ku rruga UDP e ofruar nuk funksionon, por vetëm nëse serveri vërtet dëgjon në atë transport dhe portë. Porta TCP 443 nuk trajtohet automatikisht si HTTPS normal, dhe nuk është garanci kalimi përmes një rrjeti kufizues.
sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4
Ekzekutimi i profilit të furnizuar me më shumë detaje e mban gabimin e parë të dobishëm të dukshëm në vend që ta shtypë në një dialog të përgjithshëm dështimi. Përdorni skedarin që dha operatori në vend që të modifikoni vetë portat ose protokollet, sepse një ndryshim lokal nuk mund të krijojë një dëgjues përputhës në anën tjetër.
Nëse tuneli ristartohet vazhdimisht, shënoni nëse portali rishfaqet ose sinjali lokal bie, dhe ndiqni kontrollet e stabilitetit në vend që të ndërroni disa protokolle njëherësh. Pastaj provoni aplikacionin që ju nevojitet vërtet dhe rivendosni kontrollet normale të privatësisë. Një lidhje që transporton një sajt por jo një tjetër është çështje rrugëtimi ose politike, jo e portalit.
Së fundi, kontrolloni rikuperimin pasi laptopi fle. Autorizimi i portalit mund të skadojë pavarësisht nga tuneli, kështu që një pajisje që rilidhet automatikisht mund të kthehet në një rrjet që e ka harruar tashmë. Rihapja e faqes së portalit është një hap normal, jo shenjë se VPN është prishur.