Root mění, které síťové operace smí proces zkusit. Nedá telefonu veřejně dostupnou adresu, nezajistí příchozí mapování u operátora ani neudrží démona naživu po restartu. Pokud rozhodujete, zda Android telefon může fungovat jako VPN server, oddělte tři otázky: dokáže zamýšlený klient vůbec dosáhnout posluchače, jaký model oprávnění implementace serveru potřebuje a co se musí forwardovat, jakmile tunel běží.

Kdo se musí k telefonu dostat a odkud

Klient ve stejné povolené LAN a klient na mobilních datech testují dvě různé sítě. Nejprve rozhodněte, která je zamýšlená, protože odpovědi se nepřenášejí. Na Wi-Fi obvykle nevyžádaný příchozí provoz potřebuje mapování na nadřazeném routeru a použitelnou veřejnou cestu za ním. V mobilní síti znamená carrier-grade NAT, že příchozí IPv4 je často nedostupná, ať telefon povolí cokoli.

Právě poslední bod root neovlivní. Místní firewall telefonu a NAT operátora jsou různé systémy a změna prvního nemá na druhý vliv. Privátní adresa rozhraní, ikona mobilních dat nebo naslouchající socket nejsou důkazem dostupnosti. Pokud cesta operátora přesto nabízí globálně směrovatelnou IPv6, stále pro ni potřebujete záměrnou politiku posluchače a firewallu; mít adresu není totéž jako přijímat spojení.

Client pathWhat actually decides reachability
Same LANThe phone's listener and its local firewall
Wi-Fi, from the internetA mapping on the upstream router plus a usable public path beyond it
Cellular IPv4The carrier's NAT, which the handset does not control
Cellular IPv6Address, listener and firewall policy together

Obsluha a forwarding jsou dva různé úspěchy

Dokončený VPN handshake dokazuje, že tunel existuje. Nedokazuje, že se klient dostane do LAN za telefonem, ani že telefon může sloužit jako internetový výstup. To jsou oddělené konfigurace postavené na vnitřním plánu adres, trasách, chování při návratu a úzce vymezené politice forwardingu pro úkol, který skutečně chcete.

Selhání je předvídatelné: handshake projde, klient ukazuje připojeno a nic se nenačte. Než začnete ladit klienta, rozhodněte, kterou ze dvou rolí stavíte. Vzdálený přístup k zařízení v telefonní síti a internetový výstup přes plný tunel vyžadují různá pravidla forwardingu a povolení obou, když jste chtěli jedno, rozšiřuje expozici, aniž by přidalo schopnost, o kterou jste žádali.

Model oprávnění je volba, ne root nebo nic

Běžný démon OpenVPN používající kernelové zařízení TUN potřebuje odpovídající schopnosti, přístup k uzlu zařízení a součinnost bezpečnostní politiky Androidu. Root není plošná výjimka ze SELinuxu; privilegovaný proces je stále omezen politikou platformy. Proto binárka, která bez potíží běží na Linux serveru, může na telefonu selhat bez zjevné chyby o oprávněních.

Implementace brány v uživatelském prostoru může mít zcela jiný model oprávnění, takže rozšířené tvrzení, že každý VPN server na Androidu potřebuje root, je příliš široké. Root vám kupuje možnost zkusit více operací, ne záruku, že budou povoleny nebo že výsledek bude dostupný.

Vlastní registrace VPN služby v Androidu je opět jiný mechanismus. Dává aplikaci spravované klientské rozhraní s definovaným životním cyklem; není to univerzální instalátor serveru a spuštění démona z terminálu mu nedá správu trvalého běhu, politiku pro jednotlivé aplikace ani vlastní cestu obnovy.

Pokud chcete výstupní bod, změňte architekturu

Když je cílem prostě vzdálený internetový výstup přes telefon, nikoli kompatibilita s existujícím profilem OpenVPN, lépe odpovídá podporovaný výstupní uzel v overlay síti. Tailscale dokumentuje roli výstupního uzlu pro Android s vlastními kroky registrace, autorizace a výběru klienta.

Kompromis je skutečný a stojí za to ho říct přímo: přijímáte jiný protokol, jiný model důvěry a závislost na onom účtu a koordinační službě. Nezpůsobí, že se neupravený klient OpenVPN připojí k overlay síti, a nedá vám posluchač OpenVPN na veřejné adrese.

Co nasazení ještě potřebuje

Ať zvolíte kteroukoli cestu, provozní základy rozhodují, zda vydrží týden. Uchovávejte přihlašovací údaje serveru v soukromí, vydávejte odlišné identity klientů a plánujte odvolání dřív, než ho budete potřebovat. Rozhodněte, jak dorazí aktualizace, co drží službu běžící na pozadí a jak se zotaví po restartu nebo změně sítě.

Vyhněte se zkratkám, které vypadají pohodlně: zastaralá statická binárka, pevně zapsané názvy rozhraní a startovací skript, který smaže stávající politiku firewallu. Výsledek pak přijměte jen na základě konkrétního testu: oprávněný vzdálený klient dosáhne zamýšleného prostředku, zakázané cíle zůstanou nedostupné a zařízení se samo vrátí po podporované události životního cyklu. Root přístup je jedna z možných přísad tohoto výsledku a málokdy ta rozhodující.

Související články