Android always-on VPN: hogyan oldódik fel először a végpont neve

Újraindul a telefon, az always-on be van kapcsolva, a „block connections without VPN” aktív, és a tunel mégsem jön létre. Semmi nincs rosszul beállítva: a blokk teszi a dolgát, és a kliens saját próbálkozása a végpont elérésére ugyanennek van alávetve. A végpont nevét még a tunel létezése előtt fel kell oldani, méghozzá egy olyan kliensnek, amely beszélhet a hálózattal, miközben minden más alkalmazás nem. Ha megértjük, melyik komponens teszi ezt, és milyen sorrendben, a rejtélyből konfigurációs kérdés lesz.

Mit is kér valójában a VPN-építő

Az Android VPN-alkalmazás nem kiszolgáló-címet ad át a platformnak. Helyi interfészt épít: a tunel címeit és útvonalait, a benne használandó feloldókat, majd az establish() egy fájlleírót ad vissza, amelyet az alkalmazás nyers IP-csomagokként olvas és ír. A távoli végpont ebben az építőben egyáltalán nem jelenik meg.

Ez a kulcsfontosságú strukturális tény. A platform létrehoz egy tun interfészt, és házirendet érvényesít rajta; az alkalmazás felhasználói térben valósítja meg a szállítást, vagyis maga oldja fel a végpont nevét, és maga nyitja meg a titkosított kapcsolatot. A hosztnévként megadott végpont tehát lehetséges — nem azért, mert a platform támogatja a neveket, hanem mert a platform soha nem látja a végpontot.

Egyetlen építőmező azért címeket vesz át: a DNS-kiszolgálók. Ezeknek numerikus feloldócímeknek kell lenniük, általában olyanoknak, amelyeket az üzemeltető a tunelen keresztül akar lekérdezni. Ez a mező azt írja le, hova küldenek lekérdezéseket az alkalmazások a tunel létrejötte után. Semmit nem mond arról, hogyan találja meg a kliens a végpontot, és a két beállítás összemosása az, ahol a zavar kezdődik.

Két DNS-kérdés, nem egy

Az első kérdés: hova küldenek lekérdezéseket az alkalmazások, amikor a tunel már áll? A válasz egy feloldócím a tunelen belül, amely a tun interfészen keresztül érhető el, és konstrukciójából adódóan numerikus.

A második kérdés: hogyan találja meg a kliens a saját végpontját, mielőtt ez a tunel létezne? Ez a keresés a tunelen kívül, a mögöttes hálózaton, a kliens folyamatában történik. Használhat nevet, és olyan feloldót kell használnia, amelyet az eszköz VPN nélkül is elér.

Három szakasz, három különböző tünet. Egyetlen hibaüzenet, amely azt mondja, hogy „nem lehet csatlakozni”, összemossa őket, ezért kezdik az emberek a DNS-kiszolgáló mezőjét szerkeszteni egy olyan probléma megoldására, amely még azelőtt jelentkezik, hogy azt a mezőt egyáltalán megnéznék.

Miért akadhat meg a bootstrap

Az always-on bekapcsolt blokkolással azt jelenti, hogy a VPN-en kívüli forgalom eldobódik, beleértve a VPN-t birtokló alkalmazás forgalmát is. A kijárat kifejezett: az alkalmazás meghívja a protect() hívást egy socketen, ami a mögöttes hálózathoz köti, így megkerüli a tunelt, és engedélyt kap a kijutásra. Minden VPN-kliensnek ezt kell tennie a saját szállításához, különben soha nem érné el a kiszolgálót.

Vegyünk most egy olyan telepítést, ahol az egyetlen feloldó, amely ismeri a végpont nevét, maga is a tunelen belül van. A kliensnek tunelre van szüksége a név feloldásához, és névre a tunel felépítéséhez. Ez valódi körkörös függőség, és semmilyen klienskonfiguráció nem oldja fel. Tervezési hiba, nem programhiba.

Az időzítés ugyanezt a függőséget mutatja enyhébb formákban. Indításkor, az első feloldás előtt az eszköznek még nem lehet használható hálózata; egy captive portalon a hálózat létezik, de mindent blokkol, kivéve a portált; Wi-Fi-ről mobilhálózatra váltáskor a védett socket mögöttes hálózata megváltozik, és a kliensnek észre kell vennie, majd újra fel kell oldania. Mindegyik bootstrap-esemény, és mindegyiket érdemes szándékosan tesztelni, nem pedig hajnali 3 órakor felfedezni.

Miért nem megoldás a válasz rögzítése

A csábító kerülőút: egyszer feloldjuk a nevet, és a kapott címet beillesztjük egy numerikus mezőbe, vagy bedrótozzuk egy egyedi buildbe. Úgy tűnik, működik, és közben egy nevet pillanatképpé alakít. Amikor az üzemeltető áthelyezi a végpontot — költözés, anycast-változás, új regionális cím —, a kliens továbbra is a régit hívja, és semmi a felületen nem magyarázza meg, miért.

A DNS-rekordok élettartamot hordoznak éppen azért, hogy a válaszok változhassanak; a gyorsítótárazás ezzel az élettartammal van definiálva, nem az örökkévalósággal. Egy válasz rögzítése eldobja azt a mechanizmust, amely a nevet jobbá teszi egy címnél, miközben megtartja a névhasználat üzemeltetési költségét.

A rögzítés általában egy második rossz szokással is jár: az identitásellenőrzés lazításával, mert a kapcsolat most másképp hibázik. A kiszolgáló identitásának ellenőrzése nem része a bootstrap-problémának, és a gyengítése egy DNS-kellemetlenséget cserél le egy lehallgatási kockázatra.

Újraindítást túlélő megoldások

A tartós elrendezés nem látványos. Olyan klienst használj, amely helyesen valósítja meg a védett socketeket, és a mögöttes hálózaton oldja fel a végpontját, és adj neki olyan végpontnevet, amely nyilvánosan, vagy a tunel előtt elérhető feloldón keresztül oldódik fel. Tartsd bekapcsolva a blokkolást; a teljes kikapcsolás, hogy a DNS működjön, eltávolítja azt a tulajdonságot, amiért a telepítés létezik.

Ahol a végpontnak privátnak kell maradnia, biztosíts a platform számára használható, kifejezett bootstrap-útvonalat — a tunel nélkül elérhető feloldót vagy az üzemeltető által fenntartott kezelési kapcsolatot —, és tartsd ezt a kivételt szűken, házirendhez rendelve, ne felhasználói kapcsolóhoz. Az Android VpnService dokumentációja a referencia arról, mit garantál a platform a védelemről és az életciklusról, és a VpnService.Builder referenciája megerősíti, hogy a DNS-mező numerikus címeket vesz át.

Utána egy újraindítás utáni friss kapcsolaton, sorrendben ellenőrizd a három szakaszt: a végpont neve feloldódik, a tunel létrejön és a partner hitelesít, majd egy privát név feloldódik a tunel feloldóján keresztül. Ha az első szakasz elbukik, semmi későbbi nem működhet, és a javítás a bootstrap-útvonalba való — soha nem a feloldó mezőjébe.

• A végpont feloldása az alkalmazásban, a tunelen kívül, védett socketen történik.
• Az építő DNS-mezője a tunelen belüli alkalmazásoknak szól, nem a kliens saját végpontjának.
• A csak a tunelen keresztül elérhető feloldó zsákutca, nem lassú indulás.
• A végpontot, a hitelesítést és a privát névfeloldást külön teszteld újraindítás után.