Zergatik blokeatzen du kaptura-portalak zure VPN-a eta nola hasi saioa berriro

Sare ireki batean, zure sarbide-puntuak ez ditu paketeak internetera besterik gabe ematen. Goragoko politika-puntu batek zure gailua baimenduta dagoen egiaztatzen du, eta baimenduta egon arte, ia dena baztertzen da. Zure VPN bezeroak isiltasun hori zerbitzari hil gisa irakurtzen du. Gutxitan esaten du: WireGuardek eskuko agurra hutsunerantz errepikatzen du, OpenVPN konexioaren denbora-muga jakinarazten du, eta IKEv2k 809 errorearekin erantzuten du, erantzuten ez duen urruneko zerbitzari bati buruz.

Zer kontrolatzen duen portalak benetan

Kaptura-portala elkarri itsatsitako bi gauza dira: politika-erabakien puntua eta birbideratzailea. Zure gailua elkartzen denean eta DHCP maizterra hartzen duenean, sareak baimenaren aurreko egoeran jartzen zaitu.

Egoera hori suebakiko arau-multzo bat da. Normalean DNS baimendu eta HTTP edo HTTPS baimendu egiten ditu portalaren ostalari-zerrenda labur batera, eta gainerako guztia baztertzen du. Baimendutako zerrenda harresidun lorategia da, eta ia inoiz ez du VPN helmuga bat barne hartzen.

Bazterketa horietako bat ere ez da adeitsua. VPN zerbitzari batera zuzendutako paketeak baztertu egiten dira, ukatu beharrean, beraz bezeroak ez du ICMP unreachable ez TCP reset jasotzen, erantzunik ezaren berri bakarrik. Hornitzailearen arabera, birbideratzaileak 80 portuari erantzun diezaioke saioa hasteko orrirako birbideratze batekin, eta 443 portua baztertu edo atzeman egiten da. Birbideratzeak erraz antzematen dira HTTP erantzun soil bat daramatelako; 443 atzemateko, zure nabigatzaileak fidatzeari uko egingo dion ziurtagiri bat behar da.

Baimena bera gailuaren MAC helbideari lotuta egoten da normalean, batzuetan maiztertutako IP-ari, eta tenporizadore bat duen saio-taula batean bizi da. Saioa hasteak sarrera bat sortzen du. Zure trafikoa pasatzen uzten duen suebakiko araua sarrera hori existitzen den bitartean bakarrik existitzen da, eta horregatik itzultzen da arazo osoa geroago zure aldetik ezer aldatu gabe.

Zergatik hiltzen den VPNaren eskuko agurra hasi aurretik

Protokolo bakoitzak bere garraioa du, eta baimenaren aurreko suebakiak bakoitza modu ezberdinean hausten du. Windows eta iOSko IKEv2k UDP 500 eta UDP 4500 erabiltzen ditu; portu horietako bazterketa 809 gisa agertzen da, edo faseak bereiz jakinarazten dituzten bezeroetan izen-ebazpen motako hutsegite gisa. UDP 1194 gaineko OpenVPN konektatzeko egoeran egoten da bere denbora-muga iraungi arte. TCP 443 gaineko OpenVPN da kasu interesgarria, portalak TCP eskuko agurra osa baitezake eta gero bere birbideratze-orriarekin erantzun, beraz TLS errore bat ikusten duzu denbora-muga baten ordez.

WireGuardek mekanismoa argien erakusten du. Diseinuz UDP soila da, TCP ordezko barik, beraz UDP ezezaguna baztertzen duen suebakiak garraioa guztiz kentzen du. Bezeroak eskuko agurren hasierak bidaltzen jarraitzen du atzerapen handiagoarekin eta inoiz osatzen ez den eskuko agur baten berri ematen du. Mezu horretan ezerk ez du Wi-Fi aipatzen, eta ezerk ez du nabigatzaile bat ireki behar duzunik iradokitzen.

Plataformek zure VPNak baino lehenago nabaritu nahi izaten dute egoera. Windowsek URL ezagun bat eskatzen du saioa hasteko jakinarazpena erakutsi ala ez erabakitzeko, Androidek 204 No Content erantzun beharko lukeen helmuga bat eskatzen du, eta Apple gailuek kaptura-sarearen leiho txiki bat irekitzen dute. Zunda horiek funtzionatzen dute portalak espero den gorputzaren ordez birbideratze batekin erantzuten duelako. Portaera berak azaltzen du nola egon daitekeen portala erabat osasuntsu zure tunela hilda dagoen bitartean: zunda eta tunela arau ezberdinen arabera epaitzen dira.

Zer berrezartzen duen saioaren iraungitzeak benetan

Lekuek saioak iraungitzen dituzte zure VPN kontuarekin zerikusirik ez duten arrazoiengatik: jarduerarik ezaren denbora-muga, saioaren gehieneko iraupena, DHCP maizter berria edo beste sarbide-puntu batera berriro elkartzea. Tenporizadoreak jotzen duenean, saio-taulako sarrera desagertu egiten da eta baimenaren aurreko arau-multzoa sarrerako unean zegoen bezalaxe itzultzen da.

Ezarritako tunel bat askotan nahikoa irauten du osasuntsu emateko. Bizirik-eusteko mezuak bidaltzen jarraitzen dute, eta bezeroak nabaritzen duen ala ez erantzunik gabeko trafikoarekin nola jokatzen duen araberakoa da, beraz egoera-argia berde egon daiteke bidea desagertu ondoren. Gero tunela erortzen da eta berriro konektatzeko saio bakoitzak huts egiten du blokeatutako portu berberetan.

Une horretan, bezeroaren erroreak zein fasetan zauden esaten dizu, arretaz irakurtzen baduzu:

Xehetasun batek jendea engainatzen du: saioa MAC helbide batera lotuta dagoenean, saioa hasteko orria berriz kargatzeak agian ez du lagunduko. Elkarketa eten eta berriro sartu behar duzu, portalak iraungitako saiakera baten ordez baimen-saiakera berri bat ikus dezan.

Lehenengo hasi saioa, gero altxatu tunela

Funtzionatzen duen ordena hau da: baimendu gailua, frogatu bidea, abiarazi VPN-a, frogatu tunela, eta gero berrezarri zure ohiko blokeoa. Azken urrats hori garrantzitsua da portalera iristeko behar duzun aldi baterako egoera hain zuzen ere itzal-etengailu bat existitzen delako eragozteko.

Tunelaren kanpoaldea blokeatzeko aukera duen mahaigaineko bezero bat pausatu egin behar da portalaren orria karga dadin, eta aplikazio sentikorrak itxita mantendu beharko zenituzke tunelaren kanpoko leiho horretan; tokiko trafikoa babesik gabe irteten den tarte bakarra da. Kudeatutako beti piztuta dagoen gailu batek bere jabeak argitaratutako prozedura erabili beharko luke zuk politika kentzearen ordez. Portalak ziurtagiri-abisua erakusten badu, gelditu: onartzeak zure saioa lekuaren atzemate-proxyaren bidez bideratzen du, eta proxy horrek bidaltzen duzun guztia irakur dezake. Androidek, beti aktibatuta dagoen VPNaren pean, blokeoak trafikoa blokeatzen du tunela altxatu aurretik, eta eraikuntza batzuek ezin dute portalaren fluxua salbuetsi; zureak ezin badu, erabili lekuaren sarbide alternatiboa edo beste gailu bat blokeoa itzalita uztearen ordez. Appleen eskariko arauak tunela ukatzea idatz daitezke zunda batek arrakasta izan arte, eta hori da hotel-sareetan nahi duzun portaera.

Egiaztatu ordenan jada dituzun tresnekin. Tunela baino lehen, exekutatu zunda goiburuak eta gorputza biak ikusgai dituela, eta begiratu zure VPN garraioak erantzunik jasotzen duen:

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'

Baimena eman aurretik, portal normal batek bi erantzunetako bat ematen du: 302 bat, zeinaren Location saioa hasteko orrira seinalatzen duen, edo 200 bat HTML gorputz batekin, portalaren orria dena. Idatzi zein jaso duzun. Birbideratzea ez da hutsegite bat saioa hasi aurretik; portalak nora joan behar duzun esaten dizu. Portalak arrakasta jakinarazi ondoren, errepikatu komandoa eta itxaron 200 bat, zeinaren gorputza hitzez hitz Success hitza den. Kate horrek egiten du zunda esanguratsu. Ostalariak normaltasunez erantzuten badu inoiz saioa hasi aurretik, ez dago atzemate-portalik sare honetan. Kapturan, baimenaren aurreko bazterketa kanporako paketeak dira, eta ez da ezer itzultzen; funtzionatzen duen bideak, berriz, fluxu berari erantzuna erakusten dio segundo inguruan. Konektatu, eta gero errepikatu kaptura.

Tunelak huts egiten jarraitzen badu portalak bai esan ondoren

Saioa ondo hastea ez da garraio baimendua izatea. Leku askok portala eta nabigazio arrunta baimendu egiten dituzte UDP guztiz blokeatzen duten bitartean, eta horrek WireGuard eta UDP OpenVPN hautsita uzten ditu eta TCP 443 funtzionatzen. TCP 443 pasatzen bada eta UDP ez, hori lekuaren politika da, ez zuk gaizki konfiguratutako bezero bat, beraz aldatu garraioa edo onartu muga eta aurrera egin. Ondoren berriro konektatzeak oraindik huts egiten badu, gorde errore zehatza; harrapatuta zauden fasea izendatzen du.

Beste hutsegite batzuk gailuan bizi dira. Oraindik MAC zahar bati lotuta dagoen saio bat, bere maizter propioa duen bigarren Wi-Fi egokitzaile bat, edo portalaren ziurtagiri-salbuespena gordeta duen bezero bat: horietako bakoitzak huts egiten jarrai dezake baimen garbia berritu ondoren. Eten elkarketa, baimendu berriro, eta saiatu behin bezeroaren ezarpenak ukitu aurretik. RFC 8952 irakurtzea merezi du zaintzen ari zaren osagaien atzeko arkitektura nahi baduzu.

Portalak berak baimena emateari uko egiten badio, arazoa kontuan edo gailuen esleipenean dago eta VPN ezarpen batek ere ez du konponduko. VPNaren irteera-herrialdea aldatzeak ez du lekuaren tokiko sarbide-egoera berrezartzen; taula hori zure gailuari lotuta dago, ez aukeratzen duzun zerbitzariari. Galdetu lekuaren operadoreari eta eman denbora, saio-taula izango baita begiratuko duena.

Hurrengo bidaiaren aurretik, idatzi hiru gauza: portalaren orria zero urrats gisa, blokeoa pausatzeko urratsa daramazun gailu bakoitzerako, eta benetan probatu duzun garraio-ornu bat. Duela hamar minutu funtzionatzen zuen tunel bat berriro gelditzen denean, tratatu iraungitako baimen gisa eta egiaztatu berriro portala VPN profila ukitu aurretik.