Androiden beti aktibatuta VPN: nola ebazten den lehenengo muturreko izena
Androidek trafikoa blokeatzen du tunela existitu aurretik, baina bezeroak bere muturra ebatzi behar du. Hemen dago ordena eta non blokeatzen den.
Telefonoa berrabiarazten da, beti aktibatuta dago, VPNik gabeko konexioak blokeatzea piztuta dago, eta tunela ez da inoiz altxatzen. Ezer ez dago gaizki konfiguratuta: blokeoak bere lana egiten du, eta bezeroaren beraren muturrera iristeko saiakerak ere hari lotuta daude. Muturra tunela existitu aurretik ebatzi behar da, sarearekin hitz egiteko baimena duen bezero batek, beste edozein aplikaziok ez duen bitartean. Zein osagai arduratzen den eta zer ordutan ulertzeak misterioa konfigurazio galdera bihurtzen du.
Zer eskatzen duen VPN eraikitzaileak benetan
Android VPN aplikazio batek ez dio plataformari zerbitzari helbiderik ematen. Tokiko interfaze bat eraikitzen du: tuneleko helbideak eta ibilbideak, aplikazioek barruan erabili beharreko ebazleak, eta gero establish() fitxategi deskribatzaile bat itzultzen du, aplikazioak IP pakete gordin gisa irakurtzen eta idazten duena. Urruneko muturra ez da inoiz agertzen eraikitzaile horretan.
Hori da funtsezko egitura egitatea. Plataformak tun interfazea sortzen du eta politikak ezartzen ditu hortik; aplikazioak garraioa erabiltzaile espazioan inplementatzen du, hau da, aplikazioak berak ebazten du bere muturreko izena eta konexio zifratua irekitzen du. Ostalari izena duen muturra posible da, ez plataformak izenak onartzen dituelako, baizik eta plataformak ez duelako muturra inoiz ikusten.
Eraikitzaileko eremu batek helbideak onartzen ditu: DNS zerbitzariak. Ebazle helbide numerikoak izan behar dute, normalean operadoreak tuneletik kontsultatzea nahi dituenak. Eremu horrek deskribatzen du non bidaltzen dituzten aplikazioek kontsultak tunela altxatu ondoren. Ez du ezer esaten bezeroak muturra nola aurkitzen duen, eta biak konfigurazio bera balira bezala tratatzea da nahastearen hasiera.
Bi DNS galdera, ez bat
Lehenengo galdera hau da: non bidaltzen dituzten aplikazioek kontsultak tunela altxatu ondoren? Erantzuna tuneleko ebazle helbide bat da, tun interfazearen bidez irisgarria, eraikuntzaz numerikoa.
Bigarren galdera hau da: nola aurkitzen du bezeroak bere muturra tunel hori existitu aurretik? Bilaketa hori tunelaren kanpoan gertatzen da, azpiko sarean, bezeroaren prozesuan. Izena erabil dezake eta VPNik gabe gailuak irits dezakeen ebazlea erabili behar du.
| Fasea | Nork ebazten du | Bidea | Nola ikusten den hutsegitea |
|---|---|---|---|
| Muturraren bilaketa | VPN aplikazioa | Azpiko sarea, socket babestua | Ez da inoiz konektatzen; trafikorik ez tun interfazean |
| Bikotearen autentifikazioa | Bezeroa eta zerbitzaria | Tunelaren garraioa | Konektatu eta erori; ziurtagiri edo gako errorea |
| Izen pribatuaren bilaketa | Aplikazioak tuneletik | Ebazlea tun barruan | Tunela altxatuta, barruko guneak ez dira ebazten |
Hiru fase, hiru sintoma desberdin. Ezin da konektatu bezalako errore mezu batek bateratzen ditu, eta horregatik jendeak DNS zerbitzariaren eremua editatzen du eremu hori irakurri aurretik gertatzen den arazoa konpontzeko.
Zergatik blokea daitekeen abiaraztea
Beti aktibatuta blokeoa piztuta egoteak esan nahi du VPN barruan ez dagoen trafikoa baztertzen dela, VPNaren jabe den aplikazioaren trafikoa barne. Irteera esplizitua da: aplikazioak protect() deitzen du socket batean, eta horrek azpiko sarera lotzen du, tunela saihestu eta irteten uzteko. VPN bezero bakoitzak hori egin behar du bere garraiorako, bestela ez litzateke inoiz zerbitzari batera iritsiko.
Pentsa ezazu muturreko izena ezagutzen duen ebazle bakarra tunelaren barruan dagoen hedapen bat. Bezeroak tunela behar du izena ebazteko, eta izena tunela eraikitzeko. Benetako mendekotasun zirkularra da, eta inongo bezero konfiguraziok ez du konpontzen. Diseinu errorea da, ez programa errorea.
Denborak mendekotasun bera erakusten du modu leunagoetan. Lehen desblokeoa baino lehen abiaraztean gailuak agian ez du sare erabilgarririk; captive portal batean sarea badago baina portala ez den guztia blokeatzen du; Wi-Fi-tik mugikorrera pasatzean socket babestuaren azpiko sarea aldatzen da eta bezeroak hori nabaritu eta berriro ebatzi behar du. Horietako bakoitza abiarazte gertaera da eta nahita probatzea merezi du, goizeko 3etan aurkitu beharrean.
Zergatik ez den erantzuna finkatzea konponbidea
Bide tentagarria izena behin ebatzi eta lortutako helbidea eremu numeriko batean itsastea da, edo eraikuntza propioan gogor kodetzea. Badirudi funtzionatzen duela, eta izena argazki bihurtzen du. Operadoreak muturra mugitzen duenean, migrazioz, anycast aldaketaz edo eskualde helbide berri batez, bezeroak zaharrari deitzen jarraitzen du eta interfazean ezerk ez du arrazoia azaltzen.
DNS erregistroek bizitza denbora daramate erantzunak alda daitezen; cachea bizitza horren arabera definitzen da, ez betiko. Erantzuna finkatzeak izena helbidea baino hobea egiten duen mekanismoa baztertzen du, izena erabiltzearen kostu operatiboa mantenduz.
Finkatzeak bigarren ohitura txar batekin joan ohi da: identitate egiaztapenak lasaitzea, konexioak orain beste modu batean huts egiten duelako. Zerbitzariaren identitatea egiaztatzea ez da abiarazte arazoaren parte, eta ahultzeak DNS eragozpena eten arriskuagatik trukatzen du.
Berrabiaraztea gainditzen duten diseinuak
Konponketa iraunkorra ez da distiratsua. Erabili socket babestuak behar bezala inplementatzen dituen eta bere muturra azpiko sarean ebazten duen bezero bat, eta eman tuneleko aurretik publikoki edo irisgarri den ebazle baten bidez ebazten den muturreko izena. Utzi blokeoa piztuta; DNS funtziona dezan guztiz desaktibatzeak hedapena existitzen den propietatea kentzen du.
Muturra pribatu mantendu behar denean, eman plataformak erabil dezakeen abiarazte bide esplizitu bat, adibidez tunelik gabe irisgarri den ebazle bat edo operadoreak mantentzen duen kudeaketa konexio bat, eta mantendu salbuespen hori estua eta politikak gobernatua, erabiltzaile etengailu batek baino. Android VpnService dokumentazioa da plataformak babesari eta bizi zikloari buruz zer bermatzen duen erreferentzia, eta VpnService.Builder erreferentzia berresten du DNS eremuak helbide numerikoak onartzen dituela.
Gero egiaztatu hiru faseetan, ordenan, berrabiarazi ondoko konexio berri batean: muturreko izena ebazten da, tunela ezartzen da eta bikotea autentifikatzen da, eta izen pribatu bat tunelaren ebazlearen bidez ebazten da. Lehen faseak huts egiten badu, ondorengo ezerk ezin du funtzionatu.
- Muturraren ebazpena aplikazioan gertatzen da, tunelaren kanpoan, socket babestu batean.
- Eraikitzailearen DNS eremua tunelaren barruko aplikazioentzat da, ez bezeroaren beraren muturrerako.
- Tuneletik bakarrik irisgarri den ebazlea blokeoa da, ez abiarazte motela.
- Probatu muturra, autentifikazioa eta bilaketa pribatua bereizita berrabiarazi ondoren.