Android VPN vždy zapnutá: jak se nejdřív vyřeší název koncového bodu

Telefon se restartuje, vždy zapnutá je aktivní, blokovat připojení bez VPN je zapnuté a tunel se nikdy nezvedne. Nic není špatně nastaveno: blok dělá svou práci a klientův vlastní pokus dostat se ke svému koncovému bodu mu také podléhá. Koncový bod se musí vyřešit dřív, než tunel existuje, a to klientem, který smí mluvit se sítí, zatímco žádná jiná aplikace nesmí. Pochopení, která část to dělá a v jakém pořadí, mění záhadu v otázku nastavení.

Co builder VPN skutečně žádá

Aplikace VPN pro Android nedává platformě adresu serveru. Sestaví místní rozhraní: adresy a trasy pro tunel, překladače, které mají aplikace uvnitř používat, a pak establish() vrátí deskriptor souboru, který aplikace čte a zapisuje jako surové IP pakety. Vzdálený koncový bod se v tom builderu vůbec neobjevuje.

To je klíčový strukturální fakt. Platforma vytvoří rozhraní tun a vynucuje na něm politiku; aplikace implementuje transport v uživatelském prostoru, takže sama překládá název svého koncového bodu a otevírá šifrované spojení. Hostname jako koncový bod je proto možný, ne protože platforma podporuje názvy, ale protože platforma koncový bod nikdy nevidí.

Jedno pole builderu přebírá adresy: servery DNS. Musí to být číselné adresy překladačů, obvykle ty, které chce operátor dotazovat tunelem. Toto pole popisuje, kam aplikace posílají dotazy poté, co tunel stojí. Neříká nic o tom, jak klient najde koncový bod, a považovat obojí za stejné nastavení je začátek zmatku.

Dvě otázky DNS, ne jedna

První otázka zní: kam aplikace posílají dotazy, když tunel stojí? Odpověď je adresa překladače uvnitř tunelu, dosažitelná přes rozhraní tun, číselná už z podstaty.

Druhá otázka zní: jak klient najde svůj vlastní koncový bod, než ten tunel existuje? To hledání probíhá mimo tunel, v podkladové síti, v procesu klienta. Může použít název a musí použít překladač, ke kterému se zařízení dostane bez VPN.

Tři fáze, tři různé příznaky. Jediná chybová zpráva typu nelze se připojit je spojí, a proto lidé upravují pole serveru DNS, aby opravili problém, který nastane dřív, než se to pole vůbec přečte.

Proč se start může zablokovat

Vždy zapnutá s aktivním blokem znamená, že provoz, který není uvnitř VPN, se zahazuje, včetně provozu aplikace, která VPN vlastní. Východisko je výslovné: aplikace zavolá protect() na socketu, což ho připoutá k podkladové síti, takže obejde tunel a je puštěn ven. Každý klient VPN to musí udělat pro svůj transport, jinak by se k serveru nikdy nedostal.

Představte si nasazení, kde jediný překladač, který zná název koncového bodu, je sám uvnitř tunelu. Klient potřebuje tunel, aby přeložil název, a název, aby postavil tunel. To je skutečná kruhová závislost a žádné nastavení klienta ji neřeší. Je to chyba návrhu, ne chyba programu.

Čas ukazuje stejnou závislost v mírnější podobě. Při startu před prvním odemčením nemusí mít zařízení ještě použitelnou síť; na zajatém portálu síť existuje, ale blokuje vše kromě portálu; při přechodu z Wi-Fi na mobilní síť se podkladová síť chráněného socketu změní a klient si toho musí všimnout a znovu přeložit. Každý z nich je startovní událost a stojí za cílený test, místo aby byl objeven ve 3 hodiny ráno.

Proč přibití odpovědi není oprava

Lákavá zkratka je přeložit název jednou a výslednou adresu vložit do číselného pole, nebo ji natvrdo zadrátovat ve vlastním buildu. Vypadá, že to funguje, a mění název ve snímek. Když operátor koncový bod přesune, migrací, změnou anycastu nebo novou regionální adresou, klient dál volá starou a nic v rozhraní nevysvětluje proč.

Záznamy DNS nesou dobu života právě proto, aby se odpovědi mohly měnit; kešování je definováno tou dobou, ne navždy. Přibití odpovědi zahazuje mechanismus, který dělá název lepším než adresa, a přitom si ponechává provozní cenu použití názvu.

Přibití často jde s druhým zlozvykem: povolením kontrol identity, protože spojení teď selhává jinak. Ověřování identity serveru není součástí startovního problému a jeho oslabení mění nepříjemnost s DNS za riziko odposlechu.

Návrhy, které přežijí restart

Trvanlivé uspořádání je neokázalé. Použijte klienta, který správně implementuje chráněné sockety a překládá svůj koncový bod v podkladové síti, a dejte mu název koncového bodu, který se překládá veřejně nebo přes překladač dosažitelný před tunelem. Nechte blok zapnutý; vypnout ho úplně, aby DNS fungovalo, odstraní vlastnost, kvůli které nasazení existuje.

Kde musí koncový bod zůstat soukromý, poskytněte výslovnou startovní cestu, kterou platforma může použít, například překladač dosažitelný bez tunelu nebo správní spojení udržované operátorem, a držte tu výjimku úzkou a vlastněnou politikou, ne uživatelským přepínačem. Dokumentace Android VpnService je referencí pro to, co platforma garantuje o ochraně a životním cyklu, a reference VpnService.Builder potvrzuje, že pole DNS přebírá číselné adresy.

Pak ověřte ve třech fázích, v pořadí, na novém spojení po restartu: název koncového bodu se přeloží, tunel se naváže a protějšek se ověří a soukromý název se přeloží přes překladač tunelu. Když první fáze selže, nic dalšího nemůže fungovat a oprava patří do startovní cesty, nikdy do pole překladače.

• Překlad koncového bodu probíhá v aplikaci, mimo tunel, na chráněném socketu.
• Pole DNS v builderu je pro aplikace uvnitř tunelu, ne pro vlastní koncový bod klienta.
• Překladač dosažitelný jen tunelem je slepá ulička, ne pomalý start.
• Testujte koncový bod, ověření a soukromé hledání po restartu odděleně.