Hotspot bezeroentzako tunel zatitua ez da aplikazioen araberako bazterketa
Aplikazio bat VPNtik kanporatzeak telefonoa baino ez du aldatzen. Konektatutako ordenagailu eramangarriak bere aurreratze araua behar du, iturburua, helburua eta NATen parekatuta.
Berdin diruditen bi baldintza ez dira berdinak: «baztertu aplikazio hau VPNtik» eta «bidali helburu hau VPNtik kanpo nire hotspoteko ordenagailu eramangarriarentzat». Lehenengoak aldatzen du nola telefono bateko socket batek sare bat aukeratzen duen. Bigarrenak aurreratze erabaki bat aldatu behar du telefonoak jada onartu ondoren beste gailu batetik iritsitako pakete batentzat. Bien nahasketa da hotspot bezero bat telefonoaren beraren nabigatzaileari soilik inoiz aplikatu zitzaion salbuespen batekin amaitzen duen modua.
Bi azpisistemak dira bi galderen jabe
Androidek aplikazioen sareak eta tetheringa bereizita uzten ditu. Aplikazioen socketak konektibitate pilak sare batera esleitzen ditu, eta VPN aplikazio batek erabakitzen du zein socket sartzen diren tunelera. Konektatutako bezero baten aurreratutako paketeak tethering azpisistemak kudeatzen ditu, eta horrek netdri eskatzen dizkio ibilbideak, politika arauak eta itzulpena beherako interfazean.
Aplikazioen araberako bazterketa aplikazio batek socket bat irekitzen duenean ebaluatzen da. Aurreratutako pakete bat ez da inoiz iristen egiaztapen horretara, ez baita gailu honetako aplikazio socket batetik sortu. Hori da bi ezarpenek elkar ordezkatu ezin duten arrazoi osoa, eta ez da bien akats bat.
Zer aldatzen duen aplikazioen araberako bazterketak benetan
VpnService baten eraikitzaileak tunelatik kanpo geratzen diren paketeak izenda ditzake addDisallowedApplication erabiliz, edo barruan baimendutako pakete bakarrak izenda ditzake addAllowedApplication erabiliz. Aplikazio horiek azpiko sarean socketak irekitzen dituzte orduan, eta VPNak gainerako guztiarentzako ibilbide lehenetsia izaten jarraitzen du.
Esparrua zehatza da: paketearen socket propioak, gailu honetan, tunela altxatuta dagoen bitartean. Ez du ezer esaten aurreratutako trafikoaz, ez bigarren gailu bati buruz, ez sistemak tetheringaren izenean bidaltzen dituen paketeez.
Ez da helburu kontrol bat ere. Nabigatzaile bat baztertzeak nabigatzaile horrek iristen duen helbide guztiak baztertzen ditu, tunelaren barruan eduki nahi zenuena barne. Baldintzak helburu bat aplikazio bat beharrean aipatzen duenean, aplikazio hautatzailea eraikuntzaz okerreko tresna da.
Nolakoa da tetheratutako pakete bat telefonorentzat
Bezeroaren paketea hotspot interfazera iristen da telefonak esleitutako iturburu helbide pribatu batekin, esan 192.168.43.20, eta helburu publiko batekin. Aurreratzeko, telefonak goiko estekarako ibilbide bat behar du eta itzulpen arau bat, erantzunek bidea itzuli ahal izan dezaten, bezeroaren helbide pribatuak ez baitu esanahirik sare zelularrean.
Androidek politika arauekin adierazten du hori, bideratze taula bat hautatzen dutenak, eta netdek taula eta arau horiek berreraikitzen ditu sareak eta VPNak aldatzen direnean. Foro mezu batetik edo modelo beraren bertsio zaharrago batetik kopiatutako taula zenbaki batek, arau lehentasun batek edo interfaze izen batek ez du jabego iraunkorrik ezartzen. Berreraikuntza hori da, halaber, eskuz idatzitako arau batek ordubetez lan egin eta hurrengo birkonexioaren ondoren geldi daitekeen arrazoia.
Hotspot salbuespen batek benetan behar duen politika
Idatzi erabakia iturburu, helburu eta asmo den bide gisa arau bat ukitu aurretik. Onartutako helburu batentzako gutxieneko forma horrela dago:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Bi norabideak osatuak egon behar dute. Adar zuzenak oraingoa den esteka zelularraren bidezko ibilbide erabilgarri bat behar du; VPN adarrak tunelaren ibilbidea eta aurreratzeko baimena behar ditu. Edozein iturburu itzulpenek aukeratu duzun irteerarekin bat etorri behar du, tunel interfaze batean aplikatutako NATek tunelaren helbidea erakusten baitu, eta ez zelularra, eta hala itzulera bideak ez du bat egiten joateko bidearekin.
Erantzunek beheko bezero berera iritsi behar dute jarraitutako egoeraren edo bide esplizitu baten bidez, eta irteten diren paketeen kontagailu batek ez du horietako ezer frogatzen. Eutsi VPNaren kanpoko garraio propioari salbuespenaren esparrutik kanpo ere, bestela tunelaren eramaile paketeek bezero baten web eskaerarako idatzitako politika heredatuko dute.
Harrapatutako helbide bat ez da helburu bat
Nabigatzaile batetik irakurritako IPv4 helbide bakar bat argazki bat da. Zerbitzu handiek anycast-etik edo ertz helbide multzo birakor batetik erantzuten dute, asko pila bikoitzekoak dira, eta saioa hasteko fluxuak orriak inoiz erakusten ez dituen autentifikazio eta telemetria ostalariak uki ditzake. Kasualitatez ikusi duzun helbidearen inguruan eraikitako salbuespena zerbitzuak hurrengo aldiz orekatzen duenean apurtzen da.
Erabili zerbitzuaren jabearen helbide dokumentatuak edo hark argitaratzen duen barruti bat, eta kontuan hartu helbide familia biak. Baldintza multzo egonkor gisa adieraz ezin bada, ziurrenik zerbitzuarentzako politika kontua da, ez telefonoko bideratze trikimailu bat.
Egiaztatu beheko aldetik
Hiru egiaztatze, ordena honetan: ordenagailu eramangarritik hautatutako zerbitzua, VPNaren barruan geratu behar duen xede arrunta, eta ukitu gabeko telefono aplikazio bat. Ondoren errepikatu birkonexio baten ondoren eta goiko esteka aldatu ondoren, orduan berreraikitzen baitira politika taulek.
Telefonoaren partekatze inplementazioak ezin badu kontratu hori birkonexio batean zehar eutsi, eraman politika hautakorra onartutako beheko bideratzaile batera, eta ez bildu root arauak eskuan. Bideratzaile batek iturburu eta helburu parekatzea jabe egonkor batekin adieraz dezake, eta tethering moduluaren dokumentazioa da telefonoak benetan egiten duenaren erreferentzia zuzena.