Android-altyd-aan-VPN: hoe die eindpuntnaam eerste opgelos word
Android blokkeer verkeer voordat die tonnel bestaan, maar die kliënt moet steeds sy eindpunt oplos. Hier is die volgorde, en waar dit vasloop.
Die foon herbegin, altyd-aan is geaktiveer, blokkeer verbindings sonder VPN is aan, en die tonnel kom nooit op nie. Niks is verkeerd opgestel nie: die blok doen sy werk, en die kliënt se eie poging om sy eindpunt te bereik is daaraan onderworpe. Die eindpunt moet opgelos word voordat die tonnel bestaan, deur ’n kliënt wat met die netwerk mag praat terwyl elke ander app dit nie mag nie. Om te verstaan watter komponent dit doen, en in watter volgorde, maak uit ’n raaisel ’n opstellingsvraag.
Wat die VPN-bouer werklik vra
’n Android-VPN-app gee nie vir die platform ’n bedieneradres nie. Dit bou ’n plaaslike koppelvlak: adresse en roetes vir die tonnel, die oplossers wat apps daarbinne moet gebruik, en dan gee establish() ’n lêerbeskrywer terug wat die app as rou IP-pakkette lees en skryf. Die afgeleë eindpunt verskyn glad nie in daardie bouer nie.
Dit is die belangrikste strukturele feit. Die platform skep ’n tun-koppelvlak en handhaaf beleid daarop; die app implementeer die vervoer in gebruikersruimte, wat beteken die app los self sy eindpuntnaam op en maak die geënkripteerde verbinding oop. ’n gasheernaam as eindpunt is dus moontlik, nie omdat die platform name ondersteun nie, maar omdat die platform die eindpunt nooit sien nie.
Een veld van die bouer neem adresse: die DNS-bediener. Dit moet numeriese oplosseradresse wees, gewoonlik die wat die operateur deur die tonnel wil laat navraag. Daardie veld beskryf waarheen apps navrae stuur nadat die tonnel op is. Dit sê niks oor hoe die kliënt die eindpunt vind nie, en om die twee as dieselfde instelling te behandel, is waar die verwarring begin.
Twee DNS-vrae, nie een nie
Die eerste vraag is: waarheen stuur apps navrae sodra die tonnel op is? Die antwoord is ’n oplosseradres binne die tonnel, bereikbaar deur die tun-koppelvlak, numeries van aard.
Die tweede vraag is: hoe vind die kliënt sy eie eindpunt voordat daardie tonnel bestaan? Daardie opsoeking gebeur buite die tonnel, op die onderliggende netwerk, in die kliënt se proses. Dit kan ’n naam gebruik, en dit moet ’n oplosser gebruik wat die toestel sonder die VPN kan bereik.
| Fase | Wie los op | Pad | So lyk ’n fout |
|---|---|---|---|
| Eindpunt-soektog | Die VPN-app | Onderliggende netwerk, beskermde socket | Verbind nooit; geen verkeer op die tonnelkoppelvlak |
| Eweneen-verifikasie | Kliënt en bediener | Tonnelvervoer | Verbind dan val weg; sertifikaat- of sleutfout |
| Privaat naamopsoeking | Apps deur die tonnel | Oplosser binne die tun | Tonnel op, interne werwe los nie op nie |
Drie fases, drie verskillende simptome. ’n Enkele foutboodskap soos kan nie verbind nie gooi hulle saam, en daarom eindig mense met die redigering van die DNS-bedienerveld om ’n probleem op te los wat gebeur voordat daardie veld ooit gelees word.
Waarom die selflaai kan vasloop
Altyd-aan met die blok geaktiveer beteken verkeer wat nie binne die VPN is nie, word laat val, insluitend verkeer van die app wat die VPN besit. Die ontsnapping is uitdruklik: die app roep protect() op ’n socket, wat dit aan die onderliggende netwerk bind sodat dit die tonnel omseil en toegelaat word. Elke VPN-kliënt moet dit vir sy eie vervoer doen, anders sou hy nooit ’n bediener kon bereik nie.
Oorweeg nou ’n ontplooiing waar die enigste oplosser wat die eindpuntnaam ken, self binne die tonnel is. Die kliënt het die tonnel nodig om die naam op te los, en die naam om die tonnel te bou. Dit is ’n egte kringafhanklikheid, en geen kliëntopstelling los dit op nie. Dit is ’n ontwerpfout, nie ’n gogga nie.
Tyd bloot ’n dieselfde afhanklikheid in sagter vorm. By selflaai voor die eerste ontsluiting het die toestel dalk nog geen bruikbare netwerk nie; op ’n vasgevangde portaal bestaan die netwerk, maar blokkeer alles behalwe die portaal; by ’n oorskakeling van Wi-Fi na selfoon verander die beskermde socket se onderliggende netwerk en die kliënt moet dit raaksien en weer oplos. Elkeen is ’n selflaai-gebeurtenis, en elkeen is werd om doelbewus te toets eerder as om dit om 3 vm. te ontdek.
Waarom die antwoord vaspen nie ’n oplossing is nie
Die versoeking is om die naam een keer op te los en die adres in ’n numeriese veld te plak, of dit in ’n pasgemaakte bou te hardkodeer. Dit lyk of dit werk, en dit verander ’n naam in ’n momentopname. Wanneer die operateur die eindpunt verskuif, deur migrasie, ’n anycast-verandering of ’n nuwe streekadres, bly die kliënt die oue skakel en niks in die koppelvlak verduidelik waarom nie.
DNS-rekords dra ’n tyd-tot-lewe juis sodat antwoorde kan verander; kasberging word oor daardie leeftyd gedefinieer, nie vir ewig nie. Om ’n antwoord vas te pen, gooi die meganisme weg wat ’n naam beter maak as ’n adres, terwyl die bedryfskoste van naamgebruik behou word.
Vaspen gaan ook dikwels saam met ’n tweede slegte gewoonte: om identiteitskontroles te verslap omdat die verbinding nou anders misluk. Verifikasie van die bediener se identiteit is nie deel van die selflaai-probleem nie, en om dit te verswak ruil ’n DNS-ongerief vir ’n onderskeprisiko.
Ontwerpe wat ’n herbegin oorleef
Die duursame reëling is onopvallend. Gebruik ’n kliënt wat beskermde sockets korrek implementeer en sy eindpunt op die onderliggende netwerk oplos, en gee hom ’n eindpuntnaam wat publiek oplos, of deur ’n oplosser wat voor die tonnel bereikbaar is. Hou die blok geaktiveer; om dit heeltemal af te skakel sodat DNS werk, verwyder die eienskap waarvoor die ontplooiing bestaan.
Waar die eindpunt privaat moet bly, voorsien ’n uitdruklike selflaai-pad wat die platform kan gebruik, soos ’n oplosser wat sonder die tonnel bereikbaar is, of ’n bestuursverbinding wat die operateur onderhou, en hou daardie uitsondering smal en deur beleid besit eerder as deur ’n gebruiker-skuif. Die Android VpnService-dokumentasie is die verwysing vir wat die platform oor beskerming en lewensiklus waarborg, en die VpnService.Builder-verwysing bevestig dat die DNS-veld numeriese adresse neem.
Verifieer dan in die drie fases, in volgorde, op ’n vars verbinding na ’n herbegin: die eindpuntnaam los op, die tonnel vestig en die eweknie verifieer, en ’n private naam los op deur die tonnel se oplosser. As fase een misluk, kan niks later werk nie, en die regstelling hoort in die selflaai-pad, nooit in die oplosserveld nie.
- Eindpuntopsporing gebeur in die app, buite die tonnel, op ’n beskermde socket.
- Die DNS-veld in die bouer is vir apps binne die tonnel, nie vir die kliënt se eie eindpunt nie.
- ’n Oplosser wat net deur die tonnel bereikbaar is, is ’n dooie punt, nie ’n stadige begin nie.
- Toets eindpunt, verifikasi en private opsoeking afsonderlik na ’n herbegin.