Android always-on VPN: kako se ime krajnje tačke prvo razrješava

Telefon se ponovo pokreće, always-on je uključen, «blokiraj veze bez VPN-a» je uključeno, a tunel nikada ne ustaje. Ništa nije pogrešno konfigurisano: blokada radi svoj posao, a pokušaj samog klijenta da dosegne svoju krajnju tačku joj je takođe podložan. Ime krajnje tačke mora se razriješiti prije nego što tunel postoji, od strane klijenta kojem je dozvoljeno da razgovara s mrežom dok ostalim aplikacijama nije. Razumijevanje toga koji komponent to radi i u kojem redoslijedu pretvara ovu misteriju u pitanje konfiguracije.

Šta graditelj VPN-a zapravo traži

Android VPN aplikacija ne predaje platformi adresu servera. Ona gradi lokalni interfejs: adrese i rute za tunel, rezolvere koje aplikacije treba da koriste unutar njega, a zatim establish() vraća datotečni deskriptor koji aplikacija čita i piše kao sirove IP pakete. Udaljena krajnja tačka se u tom graditelju uopšte ne pojavljuje.

To je ključna strukturna činjenica. Platforma stvara tun interfejs i primjenjuje politiku na njega; aplikacija implementira transport u korisničkom prostoru, što znači da sama razrješava ime svoje krajnje tačke i otvara šifrovanu vezu. Krajnja tačka u obliku imena hosta je zato moguća — ne zato što platforma podržava imena, nego zato što platforma nikada ne vidi krajnju tačku.

Jedno polje graditelja ipak prima adrese: DNS servere. Oni moraju biti numeričke adrese rezolvera, obično one koje operater želi da se pitaju kroz tunel. To polje opisuje gdje aplikacije šalju upite nakon što tunel ustane. Ne govori ništa o tome kako klijent nalazi krajnju tačku, i upravo izjednačavanje tih dviju postavki je početak zabune.

Dva DNS pitanja, ne jedno

Prvo pitanje je: gdje aplikacije šalju upite kada je tunel već podignut? Odgovor je adresa rezolvera unutar tunela, dostupna kroz tun interfejs, i po konstrukciji numerička.

Drugo pitanje je: kako klijent nalazi sopstvenu krajnju tačku prije nego što taj tunel postoji? To traženje se odvija izvan tunela, na osnovnoj mreži, u procesu klijenta. Može koristiti ime i mora koristiti rezolver koji uređaj može dosegnuti bez VPN-a.

Tri faze, tri različita simptoma. Jedna poruka o grešci koja kaže «nije moguće povezati» sliva ih zajedno, i zato ljudi počinju da uređuju polje DNS servera kako bi popravili problem koji nastaje prije nego što to polje uopšte bude pročitano.

Zašto bootstrap može da se zaglavi

Always-on sa uključenom blokadom znači da se saobraćaj koji nije unutar VPN-a odbacuje, uključujući saobraćaj aplikacije koja posjeduje VPN. Izlaz je eksplicitan: aplikacija poziva protect() na soketu, što ga veže za osnovnu mrežu, pa on zaobilazi tunel i dobija dozvolu da izađe. Svaki VPN klijent mora to da uradi za svoj transport, inače nikada ne bi stigao do servera.

Razmotrimo sada postavljanje u kojem se jedini rezolver koji zna ime krajnje tačke i sam nalazi unutar tunela. Klijentu je potreban tunel da razriješi ime, i ime da izgradi tunel. To je stvarna kružna zavisnost, i nijedna konfiguracija klijenta je ne rješava. To je greška u dizajnu, a ne bug.

Vrijeme otkriva istu zavisnost u blažim oblicima. Pri pokretanju prije prvog otključavanja uređaj možda još nema upotrebljivu mrežu; na captive portalu mreža postoji, ali blokira sve osim portala; pri prelasku sa Wi-Fi na mobilnu mrežu osnovna mreža zaštićenog soketa se mijenja i klijent to mora primijetiti i ponovo razriješiti. Svaki od tih je bootstrap događaj, i svaki vrijedi namjerno testirati umjesto otkriti u 3 sata ujutro.

Zašto fiksiranje odgovora nije rješenje

Primamljiv zaobilazni put je razriješiti ime jednom i zalijepiti dobijenu adresu u numeričko polje, ili je tvrdo kodirati u sopstvenu gradnju. Izgleda da radi, i pretvara ime u snimak. Kada operater premjesti krajnju tačku — migracija, anycast promjena, nova regionalna adresa — klijent nastavlja da poziva staru i ništa u interfejsu ne objašnjava zašto.

DNS zapisi nose vrijeme života upravo zato da bi odgovori mogli da se mijenjaju; keširanje je definisano tim rokom, a ne zauvijek. Fiksiranje odgovora odbacuje mehanizam koji ime čini boljim od adrese, dok istovremeno zadržava operativni trošak korišćenja imena.

Fiksiranje obično ide zajedno sa drugom lošom navikom: popuštanjem provjere identiteta jer veza sada ne uspijeva drugačije. Provjera identiteta servera nije dio bootstrap problema, i njeno slabljenje mijenja DNS neugodnost za rizik presretanja.

Dizajni koji preživljavaju restart

Trajno rješenje nije atraktivno. Koristite klijent koji ispravno implementira zaštićene sokete i razrješava svoju krajnju tačku na osnovnoj mreži, i dajte mu ime krajnje tačke koje se razrješava javno, ili kroz rezolver dostupan prije tunela. Ostavite blokadu uključenu; njeno potpuno isključivanje da bi DNS radio uklanja svojstvo zbog kojeg postavljanje i postoji.

Gdje krajnja tačka mora ostati privatna, obezbijedite eksplicitan bootstrap put koji platforma može koristiti — rezolver dostupan bez tunela, ili upravljačku vezu koju operater održava — i držite tu iznimku uskom i u vlasništvu politike, a ne korisničkog prekidača. Android VpnService dokumentacija je referenca za ono što platforma garantuje u pogledu zaštite i životnog ciklusa, a referenca za VpnService.Builder potvrđuje da DNS polje prima numeričke adrese.

Zatim provjerite tri faze, po redu, na novoj vezi nakon restarta: ime krajnje tačke se razrješava, tunel se uspostavlja i partner se autentifikuje, a privatno ime se razrješava kroz rezolver tunela. Ako prva faza ne uspije, ništa kasnije ne može raditi, i ispravka pripada bootstrap putu — nikada polju rezolvera.

• Razrješavanje krajnje tačke odvija se u aplikaciji, izvan tunela, na zaštićenom soketu.
• DNS polje u graditelju je za aplikacije unutar tunela, ne za sopstvenu krajnju tačku klijenta.
• Rezolver dostupan samo kroz tunel je zaglavljivanje, a ne spor start.
• Testirajte krajnju tačku, autentifikaciju i privatno traženje odvojeno nakon restarta.