Android VPN uvijek uključen: kako se prvo razrješava naziv odredišta

Telefon se ponovo pokreće, uvijek uključeno je aktivno, blokiranje veza bez VPN-a je uključeno, a tunel se nikada ne podiže. Ništa nije pogrešno konfigurisano: blokada radi svoj posao, a i klijentov vlastiti pokušaj da dosegne svoje odredište joj je podložan. Odredište se mora razriješiti prije nego tunel postoji, od strane klijenta kojem je dopušteno razgovarati s mrežom dok nijednoj drugoj aplikaciji nije. Razumijevanje koja komponenta to radi i kojim redom pretvara ovo iz misterije u pitanje konfiguracije.

Šta VPN builder zapravo traži

Android VPN aplikacija ne predaje platformi adresu servera. Ona gradi lokalno sučelje: adrese i rute za tunel, razrješivače koje aplikacije treba da koriste unutra, a zatim establish() vraća datotečni deskriptor koji aplikacija čita i piše kao sirove IP pakete. Udaljeno odredište se u tom builderu uopće ne pojavljuje.

To je ključna strukturna činjenica. Platforma stvara tun sučelje i sprovodi politiku na njemu; aplikacija implementira transport u korisničkom prostoru, što znači da sama razrješava naziv svog odredišta i otvara šifrovanu vezu. Ime hosta je zato moguće, ne zato što platforma podržava imena, nego zato što platforma nikada ne vidi odredište.

Jedno polje buildera prima adrese: DNS servere. Oni moraju biti numeričke adrese razrješivača, obično one koje operater želi da se pitaju kroz tunel. To polje opisuje gdje aplikacije šalju upite nakon što je tunel podignut. Ne govori ništa o tome kako klijent nalazi odredište, a tretiranje njih dvoje kao iste postavke je početak zabune.

Dva DNS pitanja, ne jedno

Prvo pitanje je: gdje aplikacije šalju upite nakon što je tunel podignut? Odgovor je adresa razrješivača unutar tunela, dostupna kroz tun sučelje, numerička po konstrukciji.

Drugo pitanje je: kako klijent nalazi vlastito odredište prije nego taj tunel postoji? To traženje se odvija izvan tunela, na donjoj mreži, u procesu klijenta. Može koristiti ime i mora koristiti razrješivač do kojeg uređaj dolazi bez VPN-a.

Tri faze, tri različita simptoma. Jedna poruka o grešci poput ne može se povezati ih spaja, zbog čega ljudi uređuju polje DNS servera da poprave problem koji se javlja prije nego što se to polje uopće pročita.

Zašto se bootstrap može zaglaviti

Uvijek uključeno s aktivnom 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 socketu, što ga veže na donju mrežu pa zaobilazi tunel i biva pušten. Svaki VPN klijent to mora učiniti za vlastiti transport, inače nikada ne bi dosegao server.

Zamislite sada implementaciju u kojoj je jedini razrješivač koji zna naziv odredišta sam unutar tunela. Klijentu treba tunel da razriješi ime, a ime da izgradi tunel. To je istinska kružna zavisnost i nijedna klijentska konfiguracija je ne rješava. To je greška u dizajnu, ne bug.

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

Zašto prikivanje odgovora nije popravka

Primamljiv zaobilazni put je razriješiti ime jednom i zalijepiti dobivenu adresu u numeričko polje ili je tvrdo kodirati u vlastitoj gradnji. Izgleda da radi i pretvara ime u snimak. Kada operater premjesti odredište, migracijom, anycast promjenom ili novom regionalnom adresom, klijent nastavlja birati staru i ništa u sučelju ne objašnjava zašto.

DNS zapisi nose vrijeme života upravo zato da se odgovori mogu mijenjati; keširanje je definirano tim trajanjem, a ne zauvijek. Prikivanje odgovora odbacuje mehanizam koji ime čini boljim od adrese, a zadržava operativni trošak korištenja imena.

Prikivanje često ide s drugom lošom navikom: popuštanjem provjera identiteta jer veza sada ne uspijeva drugačije. Provjera identiteta servera nije dio bootstrap problema, a njeno slabljenje mijenja DNS neugodnost za rizik presretanja.

Dizajni koji prežive ponovno pokretanje

Trajno rješenje je neefektno. Koristite klijent koji ispravno implementira zaštićene sockete i razrješava svoje odredište na donjoj mreži, i dajte mu naziv odredišta koji se razrješava javno ili kroz razrješivač dostupan prije tunela. Ostavite blokadu uključenom; potpuno je isključiti da bi DNS radio uklanja svojstvo zbog kojeg implementacija postoji.

Tamo gdje odredište mora ostati privatno, osigurajte eksplicitan bootstrap put koji platforma može koristiti, poput razrješivača dostupnog bez tunela ili upravljačke veze koju operater održava, i držite tu iznimku uskom i pod politikom, a ne pod korisničkim prekidačem. Dokumentacija Android VpnService je referenca za ono što platforma garantuje o zaštiti i životnom ciklusu, a referenca VpnService.Builder potvrđuje da DNS polje prima numeričke adrese.

Zatim provjerite u tri faze, po redu, na novoj vezi nakon ponovnog pokretanja: naziv odredišta se razrješava, tunel se uspostavlja i partner se autentifikuje, a privatno ime se razrješava kroz razrješivač tunela. Ako prva faza ne uspije, ništa kasnije ne može raditi, a popravka pripada bootstrap putu, nikada polju razrješivača.

• Razrješavanje odredišta odvija se u aplikaciji, izvan tunela, na zaštićenom socketu.
• DNS polje u builderu je za aplikacije unutar tunela, ne za klijentovo vlastito odredište.
• Razrješivač dostupan samo kroz tunel je zastoj, ne spor početak.
• Testirajte odredište, autentifikaciju i privatno traženje odvojeno nakon ponovnog pokretanja.