Hotelako Wi-Fi: VPNak huts egiten du zerbitzarira iritsi aurretik
Tunelak huts egiten du kaptura-portalak oraindik ez zaituelako baimendu. Hasi saioa hotelaren sarean, egiaztatu HTTPS arrunta dabilela, eta gero konektatu VPN-a.
VPN bezeroa biratzen da, gero zerbitzarira iritsi ezin dela jakinarazten du, eta guztiek hotelak VPNak blokeatzen dituela ondorioztatzen dute. Normalean ez da hain gauza dramatikoa gertatu: sareak ez zaitu oraindik irtenbiderik utzi. Kaptura-portalak konexio guztiak atxikitzen ditu saioa hasi arte, eta tunelek ezin du osatu saio-hasierako orriak bere paketeak atzematen dituen bitartean. Egin saio-hasiera tunela errudun egin aurretik.
Mitioa: hotelak VPNak blokeatzen ditu
Hotel-sare gehienek ez dituzte tunelak bereziki iragazten. Web-trafikoa atzematen dute ostatuak autentifikatu arte, eta gailuak mugatu, saioak iraungi edo abiadura murriztu dezakete. Horietako bakoitzak VPN bezeroaren barrutik blokeoa dirudien hutsegitea sortzen du.
Tunela diagnostiko tresna txarra da hemen, portala baimenduta ez dagoen bitartean huts egingo duen aplikazio bakarra delako. Web-sarbide arrunta adierazle hobea da, saio-hasierako orria bera erakuts diezazukeelako.
Ordena hori beste arrazoi batengatik da garrantzitsua: geldiarazte-etengailua edo beti aktibo modua duen bezeroak portala kargatzeari uko egingo dio, eta erabiltzaileak sareak huts egin duela ondorioztatuko du, ez ezarpenak. Bi egitateak aldi berean dira egiazkoak, eta hotelen bakarra alda daiteke. Desaktibatu babesa bezeroaren kontrol propioarekin, hasi saioa eta piztu berriro. Beste edozein gauza benetako sekuentzia ezkutatzen duen saihesbidea da.
Amaitu portala lehenik, eta gero probatu HTTPS arrunta
Galdetu langileei sarearen izen ofiziala eta saio-hasierako metodoa. SSID sinesgarria ez da jabetzaren froga, eta antzeko izena duen bigarren sare bat trikimailu arrunta da leku publikoetan. Erabili sistema eragilearen saio-hasierako gonbita dagoenean, edo hotelaren dokumentatutako orria.
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/Lehen eskaerak kaptura-portalaren detekzio-puntu ezagun bat galdetzen du HTTP soilean; birbideratzeak edo gorputz ustekabekoak portaren atzean zaudela esan nahi du. Bigarrenak HTTPS gune arrunta probatzen du. Lehenak atzematea erakusten badu eta bigarrenak huts egiten badu, saio-hasiera osatugabea da eta VPNak ez du zerikusirik.
Gailu pertsonalean, beharbada geldiarazte-etengailua edo beti aktibo VPNa desaktibatu beharko da bezeroaren kontrol onartuaren bidez, portala kargatu ahal izateko. Itxi aplikazio sentikorrak tarte horretan eta piztu babesa berriro berehala. Kudeatutako gailuan, erabili administratzaileak onartutako prozedura, ez kendu politika zeuk.
Ez ezazu inoiz ziurtagiri-abisua saihestu, eta ez instalatu ziurtagiri ezezagunik edo laguntza-aplikaziorik linean sartzeko. Portalak ustekabeko zerbait eskatzen badu, egiaztatu langileekin, eta administratzailearekin gailua enpresarena bada.
Gorde jatorrizko profila eta haren errorea
Sarbide arrunta dabilela, konektatu jatorrizko profila eta idatzi errore zehatza. Autentifikazio-ukatzea kontu-arazoa da, negoziazioan zeharreko denbora-muga bide-arazoa da, eta ezartzen den baina ezer eramaten ez duen tunela bideratze edo politika arazoa da.
Horiek hirurek hurrengo urrats desberdinak behar dituzte, eta errorearen pantaila-argazkiak deskribapenak baino gehiago balio du. Idatzi ordue ere, hotelaren saio-mugak ordubetean iraungi baitaitezke eta ausazkoa dirudien hutsegitea sortu. Bezeroak erregistroa eskaintzen badu, gorde lehen hutsegitearen inguruko zatia, ez fitxategi osoa. Laburpen hori nahikoa izan ohi da profila duenarentzat fasea identifikatzeko.
Sarbide arrunta dabil eta negoziazioak oraindik denbora-muga ematen badu, galdetu hotelari trafiko hori onartzen duen, eta alderatu konfiantzazko puntu batera, gailua eta profila aldatu gabe. Puntu horretan lan egiteak hotelaren bidera eramaten du arreta, profilari buruz ezer frogatu gabe.
Erabili soilik operadoreak emaniko alternatibak
TCP profil egoki batek arrakasta izan dezake eskainitako UDP bideak huts egiten duenean, baina zerbitzariak garraio eta ataka horretan benetan entzuten badu soilik. TCP 443 ataka ez da automatikoki HTTPS arrunt gisa hartzen, eta ez da sare murriztaile bat zeharkatzeko bermea.
sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4
Emaniko profila zehaztasun handiagoz exekutatzeak lehen errore baliagarria ikusgai mantentzen du, hutsegite-elkarrizketa orokor batean zapaldu ordez. Erabili operadoreak emandako fitxategia, eta ez aldatu atakak edo protokoloak zeuk, tokiko aldaketak ezin baitu beste aldean entzule egokirik sortu.
Tunela behin eta berriro berrezartzen bada, begiratu portala berriz agertzen den edo tokiko seinalea jaisten den, eta jarraitu egonkortasun-egiaztapenak, hainbat protokolo batera aldatu ordez. Gero probatu benetan behar duzun aplikazioa eta berrezarri pribatutasun-kontrol arruntak. Gune bat eramaten duen baina beste bat ez duen konexioa bideratze edo politika kontua da, ez portalarena.
Azkenik, egiaztatu berreskuratzea eramangarria lo egon ondoren. Portalaren baimena tuneletik independenteki iraungi daiteke, beraz automatikoki berriz konektatzen den gailua dagoeneko ahaztu duen sare batera itzul daiteke. Portal-orria berriz irekitzea urrats arrunta da, ez VPNa hautsi den seinale.