Android altyd-oan VPN: hoe’t de namme fan it einpunt earst oplost wurdt
Android blokket ferkear foardat de tunnel bestiet, mar de klient moat dochs syn einpunt oplosse. Hjir is de folchoarder, en wêr’t it fêstrint.
De telefoan start opnij, altyd-oan is ynskeakele, ferbiningen sûnder VPN blokkearje is oan, en de tunnel komt nea omheech. Neat is ferkeard konfigurearre: de blokkade docht syn wurk, en de poging fan de klient sels om syn einpunt te berikken is dêr ek oan ûnderwurpen. It einpunt moat oplost wurde foardat de tunnel bestiet, troch in klient dy’t mei it netwurk prate mei wylst gjin oare app dat mei. Begripe hokker komponint dat docht, en yn hokker folchoarder, makket fan it mystearje in konfiguraasjefraach.
Wat de VPN-bouwer eins freget
In Android VPN-app jout it platfoarm gjin serveradres. It bout in lokale ynterface: adressen en rûtes foar de tunnel, de resolvers dy’t apps binnen brûke moatte, en dan jout establish() in triedsbeskriuwer werom dy’t de app lêst en skriuwt as rauwe IP-pakketten. It fiere einpunt komt hielendal net foar yn dy bouwer.
Dat is it wichtige strukturele feit. It platfoarm makket in tun-ynterface en hanthavet dêr belied op; de app ymplemintearret it ferfier yn brûkersromte, dus de app lost sels syn einpuntnamme op en iepenet de fersifere ferbining. In hostnamme as einpunt is dêrom mooglik, net om’t it platfoarm nammen stipe, mar om’t it platfoarm it einpunt nea sjocht.
Ien fjild fan de bouwer nimt adressen: de DNS-servers. Dy moatte numerike resolveradressen wêze, meastentiids dejingen dy’t de operator troch de tunnel befrege hawwe wol. Dat fjild beskriuwt wêr’t apps har fragen hinne stjoere nei’t de tunnel omheech is. It seit neat oer hoe’t de klient it einpunt fynt, en beide as deselde ynstelling behannelje is wêr’t de betizing begjint.
Twa DNS-fragen, net ien
De earste fraach is: wêr’t apps har fragen hinne stjoere as de tunnel omheech is? It antwurd is in resolveradres binnen de tunnel, berikber fia de tun-ynterface, numerik fan natuer.
De twadde fraach is: hoe fynt de klient syn eigen einpunt foardat dy tunnel bestiet? Dy syktocht bart bûten de tunnel, op it ûnderlizzende netwurk, yn it proses fan de klient. It kin in namme brûke en moat in resolver brûke dy’t it apparaat sûnder VPN berikke kin.
| Faze | Wa~t oplost | Paad | Hoe~t in flater derút sjocht |
|---|---|---|---|
| Sykjen nei it einpunt | De VPN-app | Underlizzend netwurk, beskerme socket | Ferbine nea; gjin ferkear op de tun-ynterface |
| Autentikaasje fan de peer | Klient en server | Ferfier fan de tunnel | Ferbine en falt dan fuort; sertifikaat- of kaai-flater |
| Sykjen nei in priveenamme | Apps fia de tunnel | Resolver binnen de tun | Tunnel omheech, ynterne siden losse net op |
Trije fazen, trije ferskillende symptomen. Ien flatersberjocht as kin net ferbine smyt se op ien heap, en dêrom bewurkje minsken it DNS-serverfjild om in probleem te ferhelpen dat bart foardat dat fjild ea lêzen wurdt.
Wêrom’t de opstart fêstrinne kin
Altyd-oan mei de blokkade oan betsjut dat ferkear dat net yn de VPN sit, weilitten wurdt, ek dat fan de app dy’t de VPN hat. De útgong is eksplisyt: de app ropt protect() oan op in socket, wat it oan it ûnderlizzende netwurk bynt sadat it de tunnel omsylet en trochlit wurde mei. Eltse VPN-klient moat dit foar syn eigen ferfier dwaan, oars soe er nea in server berikke kinne.
Tink no oan in útrulling wêr’t de iennichste resolver dy’t de einpuntnamme ken sels yn de tunnel sit. De klient hat de tunnel nedich om de namme op te lossen, en de namme om de tunnel te bouwen. Dat is in echte sirkelfoarmige ôfhinklikheid, en gjin inkelde klientkonfiguraasje lost it op. It is in ûntwerpfout, gjin bug.
Tiid lit deselde ôfhinklikheid yn mildere foarmen sjen. By it opstarten foar de earste ûntsluting hat it apparaat miskien noch gjin brûkber netwurk; op in captive portal bestiet it netwurk wol, mar blokkearret alles behalve it portal; by in oergong fan Wi-Fi nei mobyl feroaret it ûnderlizzende netwurk fan de beskerme socket en moat de klient dat merke en opnij oplosse. Elk dêrfan is in opstartbarren en fertsjinnet in bewuste test ynstee fan in ûntdekking om 3 oere nachts.
Wêrom’t it antwurd fêstspikerje gjin repaasje is
It ferloklike paad is de namme ien kear op te lossen en it adres yn in numerik fjild te plakken, of it hurd te kodearjen yn in eigen bou. It liket te wurkjen, en it makket fan in namme in momintopname. As de operator it einpunt ferpleatst, troch migraasje, anycast-feroaring of in nij regionaal adres, bliuwt de klient it âlde belje en neat yn de ynterface ferklearret wêrom.
DNS-records drage in libbensdoer krekt sadat antwurden feroarje kinne; caching wurdt definiearre troch dy doer, net foar altyd. It fêstspikerjen fan in antwurd smyt it meganisme fuort dat in namme better makket as in adres, wylst de operaasjekosten fan it brûken fan in namme bliuwe.
Fêstspikerjen giet faak gear mei in twadde minne gewoante: identiteitskontrôles fersêftsje om’t de ferbining no oars mislearret. Ferifikaasje fan serveridentiteit is gjin part fan it opstartprobleem, en it ferswakjen ruilet in DNS-oerlêst foar in ûnderskeppingsrisiko.
Undwerpen dy’t in restart oerlibje
De duorsume regeling is ûnopfallend. Brûk in klient dy’t beskerme sockets goed ymplemintearret en syn einpunt op it ûnderlizzende netwurk oplost, en jou him in einpuntnamme dy’t iepenbier oplost, of fia in resolver dy’t foar de tunnel berikber is. Lit de blokkade oan; it folslein útskeakelje om DNS wurkje te litten hellet de eigenskip fuort dêr’t de útrulling foar bestiet.
Wêr’t it einpunt privee bliuwe moat, soargje foar in eksplisyt opstartpaad dat it platfoarm brûke kin, lykas in resolver dy’t sûnder de tunnel berikber is of in behearferbining dy’t de operator ûnderhâldt, en hâld dy útsûndering smel en eigendom fan belied ynstee fan fan in brûkerskakelaar. De Android VpnService-dokumintaasje is de referinsje foar wat it platfoarm garandearret oer beskerming en libbenssyklus, en de VpnService.Builder-referinsje befêstiget dat it DNS-fjild numerike adressen nimt.
Kontrolearje dan yn de trije fazen, yn folchoarder, op in frisse ferbining nei in restart: de einpuntnamme lost op, de tunnel wurdt oanlein en de peer autentisearret, en in priveenamme lost op fia de resolver fan de tunnel. As faze ien mislearret, kin neat letter wurkje.
- It oplossen fan it einpunt bart yn de app, bûten de tunnel, op in beskerme socket.
- It DNS-fjild yn de bouwer is foar apps binnen de tunnel, net foar it eigen einpunt fan de klient.
- In resolver dy’t allinnich fia de tunnel berikber is, is in deade ein, gjin stadige start.
- Test it einpunt, de autentikaasje en it privee sykjen apart nei in restart.