Android always-on VPN: kako se najprej razreši ime končne točke

Telefon se znova zažene, always-on je vklopljen, «blokiraj povezave brez VPN» je vklopljeno, tunel pa se nikoli ne dvigne. Nič ni napačno nastavljeno: blokada opravlja svoje delo in tudi poskus samega klienta, da doseže svojo končno točko, je ji podrejen. Ime končne točke je treba razrešiti, preden tunel obstaja, s strani klienta, ki se sme pogovarjati z omrežjem, medtem ko vse druge aplikacije ne smejo. Razumevanje, kateri del to počne in v kakšnem vrstnem redu, spremeni to uganko v vprašanje konfiguracije.

Kaj graditelj VPN pravzaprav zahteva

Aplikacija VPN za Android platformi ne preda naslova strežnika. Zgradi lokalni vmesnik: naslove in poti za tunel, razreševalnike, ki naj jih aplikacije uporabljajo v njem, nato pa establish() vrne opisnik datoteke, ki ga aplikacija bere in piše kot surove pakete IP. Oddaljena končna točka se v tem graditelju sploh ne pojavi.

To je ključno strukturno dejstvo. Platforma ustvari vmesnik tun in na njem uveljavlja politiko; aplikacija izvaja prenos v uporabniškem prostoru, kar pomeni, da sama razreši ime svoje končne točke in odpre šifrirano povezavo. Končna točka v obliki imena gostitelja je zato mogoča — ne zato, ker platforma podpira imena, ampak zato, ker platforma končne točke nikoli ne vidi.

Eno polje graditelja pa sprejema naslove: strežniki DNS. Ti morajo biti številčni naslovi razreševalnikov, običajno tisti, ki jih operater želi poizvedovati skozi tunel. To polje opisuje, kam aplikacije pošiljajo poizvedbe, potem ko je tunel dvignjen. Ne pove nič o tem, kako klient najde končno točko, in prav enačenje teh dveh nastavitev je začetek zmede.

Dve vprašanji DNS, ne eno

Prvo vprašanje je: kam aplikacije pošiljajo poizvedbe, ko je tunel že dvignjen? Odgovor je naslov razreševalnika znotraj tunela, dosegljiv prek vmesnika tun in po zgradbi številčen.

Drugo vprašanje je: kako klient najde svojo lastno končno točko, preden ta tunel obstaja? To iskanje poteka zunaj tunela, v osnovnem omrežju, v procesu klienta. Lahko uporabi ime in mora uporabiti razreševalnik, ki ga naprava doseže brez VPN.

Tri faze, tri različni simptomi. Eno samo sporočilo o napaki «ni se mogoče povezati» jih zlije skupaj, in zato ljudje začnejo urejati polje strežnika DNS, da bi odpravili težavo, ki nastane, preden je to polje sploh prebrano.

Zakaj se bootstrap lahko zatakne

Always-on z vklopljeno blokado pomeni, da se promet, ki ni znotraj VPN, zavrže, vključno s prometom aplikacije, ki ima VPN. Izhod je izrecen: aplikacija pokliče protect() na vtičnici, kar jo veže na osnovno omrežje, tako da obide tunel in sme ven. Vsak klient VPN mora to storiti za svoj prenos, sicer nikoli ne bi dosegel strežnika.

Poglejmo zdaj postavitev, v kateri je edini razreševalnik, ki pozna ime končne točke, sam znotraj tunela. Klient potrebuje tunel, da razreši ime, in ime, da zgradi tunel. To je resnična krožna odvisnost in nobena konfiguracija klienta je ne razreši. To je napaka v zasnovi, ne hrošč.

Čas razkrije isto odvisnost v blažjih oblikah. Ob zagonu pred prvim odklepom naprava morda še nima uporabnega omrežja; na captive portalu omrežje obstaja, a blokira vse razen portala; pri prehodu z Wi-Fi na mobilno omrežje se osnovno omrežje zaščitene vtičnice spremeni in klient mora to opaziti ter znova razrešiti. Vsak od teh je dogodek bootstrap in vsakega je vredno namerno testirati, namesto da ga odkrijete ob 3 uri zjutraj.

Zakaj pripetje odgovora ni rešitev

Zapeljiv ovinek je, da ime razrešite enkrat in dobljeni naslov prilepite v številčno polje ali ga trdo zapišete v lastno gradnjo. Videti je, da deluje, in ime spremeni v posnetek. Ko operater premakne končno točko — selitev, sprememba anycast, nov regionalni naslov — klient še naprej kliče starega in nič v vmesniku ne pojasni, zakaj.

Zapisi DNS nosijo čas življenja prav zato, da se odgovori lahko spreminjajo; predpomnjenje je opredeljeno s tem časom, ne za vedno. Pripetje odgovora zavrže mehanizem, zaradi katerega je ime boljše od naslova, hkrati pa obdrži obratovalne stroške uporabe imena.

Pripetje običajno gre z roko v roki z drugo slabo navado: popuščanjem preverjanja identitete, ker povezava zdaj spodleti drugače. Preverjanje identitete strežnika ni del težave bootstrap, in njegovo slabitev zamenja neprijetnost DNS za tveganje prestrezanja.

Zasnove, ki preživijo ponovni zagon

Trajna ureditev ni privlačna. Uporabite klienta, ki pravilno izvaja zaščitene vtičnice in razreši svojo končno točko v osnovnem omrežju, in mu dajte ime končne točke, ki se razreši javno ali prek razreševalnika, dosegljivega pred tunelom. Pustite blokado vklopljeno; popolna izključitev, da bi DNS deloval, odstrani lastnost, zaradi katere postavitev obstaja.

Kjer mora končna točka ostati zasebna, zagotovite izrecno pot bootstrap, ki jo platforma lahko uporabi — razreševalnik, dosegljiv brez tunela, ali upravljalno povezavo, ki jo vzdržuje operater — in to izjemo držite ozko ter v lasti politike, ne uporabniškega stikala. Dokumentacija Android VpnService je referenca za to, kaj platforma zagotavlja glede zaščite in življenjskega cikla, in referenca VpnService.Builder potrjuje, da polje DNS sprejema številčne naslove.

Nato preverite tri faze po vrstnem redu na novi povezavi po ponovnem zagonu: ime končne točke se razreši, tunel se vzpostavi in partner se overi, zasebno ime pa se razreši prek razreševalnika tunela. Če prva faza spodleti, nič poznejše ne more delovati, in popravek spada na pot bootstrap — nikoli v polje razreševalnika.

• Razreševanje končne točke poteka v aplikaciji, zunaj tunela, na zaščiteni vtičnici.
• Polje DNS v graditelju je za aplikacije znotraj tunela, ne za lastno končno točko klienta.
• Razreševalnik, dosegljiv samo skozi tunel, je zataknitev, ne počasen zagon.
• Po ponovnem zagonu preizkusite končno točko, overjanje in zasebno iskanje ločeno.