Android always-on VPN: ako sa najprv vyrieši názov koncového bodu

Telefón sa reštartuje, always-on je zapnuté, «blokovať pripojenia bez VPN» je zapnuté a tunel nikdy nevznikne. Nič nie je zle nastavené: blokovanie robí svoju prácu a pokus samotného klienta dostať sa k svojmu koncovému bodu je mu tiež podriadený. Názov koncového bodu sa musí vyriešiť predtým, než tunel existuje, klientom, ktorý smie hovoriť so sieťou, kým všetky ostatné aplikácie nesmú. Pochopenie toho, ktorý komponent to robí a v akom poradí, mení túto záhadu na otázku konfigurácie.

Čo vlastne builder VPN žiada

Aplikácia VPN pre Android neodovzdáva platforme adresu servera. Zostavuje lokálne rozhranie: adresy a trasy pre tunel, resolvery, ktoré majú aplikácie používať v jeho vnútri, a potom establish() vráti deskriptor súboru, ktorý aplikácia číta a zapisuje ako surové IP pakety. Vzdialený koncový bod sa v tom builderi vôbec neobjavuje.

To je kľúčový štrukturálny fakt. Platforma vytvára rozhranie tun a uplatňuje na ňom politiku; aplikácia implementuje transport v používateľskom priestore, čo znamená, že sama rieši názov svojho koncového bodu a otvára šifrované spojenie. Koncový bod vo forme názvu hostiteľa je preto možný — nie preto, že platforma podporuje názvy, ale preto, že platforma koncový bod nikdy nevidí.

Jedno pole buildera však prijíma adresy: servery DNS. Musia to byť číselné adresy resolverov, zvyčajne tie, ktoré chce operátor dopytovať cez tunel. Toto pole opisuje, kam aplikácie posielajú dopyty po tom, čo tunel vznikne. Nehovorí nič o tom, ako klient nájde koncový bod, a práve zlievanie týchto dvoch nastavení je začiatok zmätku.

Dve otázky DNS, nie jedna

Prvá otázka znie: kam aplikácie posielajú dopyty, keď je tunel už hore? Odpoveďou je adresa resolvera vnútri tunela, dostupná cez rozhranie tun, a podľa konštrukcie číselná.

Druhá otázka znie: ako klient nájde svoj vlastný koncový bod skôr, než tento tunel existuje? To vyhľadávanie prebieha mimo tunela, v podkladovej sieti, v procese klienta. Môže použiť názov a musí použiť resolver, ku ktorému sa zariadenie dostane bez VPN.

Tri fázy, tri rôzne príznaky. Jedna chybová správa «nedá sa pripojiť» ich zlieva dokopy, a preto ľudia začínajú upravovať pole servera DNS, aby opravili problém, ktorý nastáva skôr, než sa toto pole vôbec prečíta.

Prečo sa bootstrap môže zaseknúť

Always-on so zapnutým blokovaním znamená, že prevádzka, ktorá nie je vo vnútri VPN, sa zahadzuje, vrátane prevádzky aplikácie, ktorej VPN patrí. Východ je výslovný: aplikácia zavolá protect() na sockete, čo ho pripne k podkladovej sieti, takže obchádza tunel a smie von. Každý klient VPN to musí robiť pre svoj vlastný transport, inak by sa nikdy nedostal k serveru.

Zvážte teraz nasadenie, v ktorom jediný resolver, ktorý pozná názov koncového bodu, je sám vo vnútri tunela. Klient potrebuje tunel, aby vyriešil názov, a názov, aby zostavil tunel. Je to skutočná kruhová závislosť a žiadna konfigurácia klienta ju nevyrieši. Je to chyba návrhu, nie chyba programu.

Čas odhaľuje tú istú závislosť v miernejších podobách. Pri štarte pred prvým odomknutím zariadenie ešte nemusí mať použiteľnú sieť; v captive portáli sieť existuje, ale blokuje všetko okrem portálu; pri prechode z Wi-Fi na mobilnú sieť sa podkladová sieť chráneného socketu mení a klient si to musí všimnúť a znova vyriešiť. Každý z týchto je bootstrap udalosť a každý stojí za to testovať zámerne, namiesto objavovania o 3 hodine ráno.

Prečo pripnutie odpovede nie je riešenie

Lákavá obchádzka je vyriešiť názov raz a výslednú adresu vložiť do číselného poľa, alebo ju natvrdo zapísať do vlastného buildu. Vyzerá, že funguje, a mení názov na snímku. Keď operátor presunie koncový bod — migrácia, zmena anycast, nová regionálna adresa — klient naďalej volá ten starý a nič v rozhraní nevysvetľuje prečo.

Záznamy DNS nesú čas života práve preto, aby sa odpovede mohli meniť; cache je definovaná týmto časom, nie navždy. Pripnutie odpovede zahadzuje mechanizmus, ktorý robí názov lepším než adresa, a pritom si ponecháva prevádzkové náklady používania názvu.

Pripínanie zvyčajne ide ruka v ruke s druhým zlým návykom: uvoľňovaním overovania identity, pretože spojenie teraz zlyháva inak. Overovanie identity servera nie je súčasťou bootstrap problému a jeho oslabenie vymieňa nepríjemnosť DNS za riziko odpočúvania.

Návrhy, ktoré prežijú reštart

Trvalé usporiadanie nie je efektné. Používajte klienta, ktorý správne implementuje chránené sockety a rieši svoj koncový bod v podkladovej sieti, a dajte mu názov koncového bodu, ktorý sa rieši verejne alebo cez resolver dostupný pred tunelom. Nechajte blokovanie zapnuté; úplné vypnutie, aby DNS fungovalo, odstraňuje vlastnosť, pre ktorú nasadenie existuje.

Tam, kde musí koncový bod zostať súkromný, poskytnite výslovnú bootstrap cestu, ktorú platforma môže použiť — resolver dostupný bez tunela alebo riadiace spojenie, ktoré udržiava operátor — a držte tú výnimku úzku a vo vlastníctve politiky, nie používateľského prepínača. Dokumentácia Android VpnService je referenciou pre to, čo platforma garantuje v oblasti ochrany a životného cyklu, a referencia VpnService.Builder potvrdzuje, že pole DNS prijíma číselné adresy.

Potom overte tri fázy v poradí na novom spojení po reštarte: názov koncového bodu sa vyrieši, tunel sa nadviaže a protistrana sa autentifikuje, a súkromný názov sa vyrieši cez resolver tunela. Ak prvá fáza zlyhá, nič nasledujúce nemôže fungovať a oprava patrí do bootstrap cesty — nikdy do poľa resolvera.

• Riešenie koncového bodu prebieha v aplikácii, mimo tunela, na chránenom sockete.
• Pole DNS v builderi je pre aplikácie vo vnútri tunela, nie pre vlastný koncový bod klienta.
• Resolver dostupný iba cez tunel je zaseknutie, nie pomalý štart.
• Po reštarte testujte koncový bod, autentifikáciu a súkromné vyhľadávanie oddelene.