Android VPN-kiszolgáló: a root nem teszi elérhetővé a telefont
Három külön probléma dönti el, szolgálhat-e egy telefon VPN-klienseket: a bejövő útvonal, a jogosultsági modell és a továbbítás. A root csak a középsőt érinti.
A root megváltoztatja, milyen hálózati műveleteket kísérelhet meg egy folyamat. Nem ad a telefonnak nyilvánosan elérhető címet, nem foglal bejövő leképezést a szolgáltatónál, és nem tart életben egy démont újraindítás után. Ha arról dönt, szolgálhat-e egy Android-telefon VPN-kiszolgálóként, válasszon szét három kérdést: elérheti-e egyáltalán a szándékolt kliens a figyelőt, milyen jogosultsági modellre van szüksége a kiszolgáló implementációjának, és mit kell továbbítani, amikor az alagút áll.
Kinek kell elérnie a telefont, és honnan
Egy kliens ugyanazon az engedélyezett LAN-on és egy kliens mobiladaton két különböző hálózatot tesztel. Először a szándékoltat döntse el, mert a válaszok nem vihetők át. Wi-Fi-n a kéretlen bejövő forgalomhoz általában leképezés kell a felső routeren, és azon túl egy használható nyilvános útvonal. Mobilhálózaton a carrier-grade NAT azt jelenti, hogy a bejövő IPv4 gyakran nem érhető el, akármit engedélyez a telefon.
Pontosan az utolsó pont az, amit a root nem tud érinteni. A telefon helyi tűzfala és a szolgáltató NAT-ja különböző rendszerek, és az első megváltoztatása nincs hatással a másodikra. Egy privát interfészcím, egy mobiladatok ikon vagy egy figyelő socket nem bizonyíték az elérhetőségre. Ha a szolgáltató útvonala mégis globálisan útvonalazható IPv6-ot kínál, ahhoz is tudatos figyelő- és tűzfalszabályzat kell; címmel rendelkezni nem ugyanaz, mint kapcsolatokat fogadni.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
A szolgálat és a továbbítás két különböző siker
Egy befejezett VPN-kézfogás bizonyítja, hogy létezik az alagút. Nem bizonyítja, hogy a kliens eléri a telefon mögötti LAN-t, és nem bizonyítja, hogy a telefon internetes kijáratként működhet. Ezek külön konfigurációk, amelyek a belső címterven, az útvonalakon, a visszatérési viselkedésen és a ténylegesen kívánt feladathoz szabott, szűk továbbítási szabályzaton épülnek fel.
A hibamód kiszámítható: a kézfogás sikerül, a kliens kapcsolódottnak látszik, és semmi nem töltődik be. Mielőtt a klienst hibakeresné, döntse el, melyik két szerep közül épít. A telefon hálózatán lévő eszközhöz való távoli hozzáférés és a teljes alagútas internetes kijárat különböző továbbítási szabályokat igényel, és mindkettőt megadni, amikor egyet akart, növeli a kitettséget anélkül, hogy hozzáadná a kért képességet.
A jogosultsági modell választás, nem root vagy semmi
Egy hagyományos, kernel TUN-eszközt használó OpenVPN-démonnak megfelelő képességekre, hozzáférésre az eszközcsomóponthoz és az Android biztonsági szabályzatának együttműködésére van szüksége. A root nem általános mentesség a SELinux alól; a kiemelt folyamatot továbbra is korlátozza a platform szabályzata. Ezért egy Linux-kiszolgálón gond nélkül futó bináris egy telefonon nyilvánvaló engedélyezési hiba nélkül is elbukhat.
Egy felhasználói térben futó átjáró implementációjának teljesen más jogosultsági modellje lehet, ezért az a közkeletű állítás, hogy minden Android VPN-kiszolgálónak root kell, túl széles. A root azt vásárolja meg, hogy több műveletet kísérelhessen meg, nem azt garantálja, hogy engedélyezik őket, vagy hogy az eredmény elérhető.
Az Android saját VPN-szolgáltatás-regisztrációja megint más mechanizmus. Kezelt kliensfelületet ad az alkalmazásnak meghatározott életciklussal; nem általános kiszolgálótelepítő, és egy démon terminálból való indítása nem ad neki állandó felügyeletet, alkalmazásonkénti szabályzatot vagy saját helyreállítási útvonalat.
Ha kilépési pontot akar, változtassa meg az architektúrát
Amikor a cél egyszerűen távoli internetes kijárat a telefonon keresztül, nem pedig egy meglévő OpenVPN-profillal való kompatibilitás, a jobban illeszkedő tervezés egy támogatott overlay-kimeneti csomópont. A Tailscale dokumentálja az Android kimeneti csomópont szerepét saját regisztrációs, engedélyezési és kliensválasztási lépéseivel.
A csere valódi, és érdemes nyíltan kimondani: más protokollt, más bizalmi modellt és az adott fióktól és koordinációs szolgáltatástól való függést fogad el. Nem éri el, hogy egy változatlan OpenVPN-kliens csatlakozzon az overlay-hálózathoz, és nem ad OpenVPN-figyelőt nyilvános címen.
Mire van még szüksége a telepítésnek
Bármelyik utat választja, az üzemeltetési alapok döntik el, kibír-e egy hetet. Tartsa privátan a kiszolgáló hitelesítő adatait, adjon ki különböző kliensidentitásokat, és tervezze meg a visszavonást, mielőtt szüksége lenne rá. Döntse el, hogyan érkeznek a frissítések, mi tartja futva a szolgáltatást a háttérben, és hogyan áll helyre újraindítás vagy hálózatváltás után.
Kerülje a kényelmesnek tűnő rövidítéseket: az elavult statikus binárist, a keményen kódolt interfészneveket és a meglévő tűzfalszabályzatot törlő indítószkriptet. Utána csak konkrét teszt alapján fogadja el az eredményt: egy engedélyezett távoli kliens eléri a szándékolt erőforrást, a tiltott célok elérhetetlenek maradnak, és az eszköz magától visszatér a támogatott életciklus-esemény után. A root-hozzáférés ennek az eredménynek egy lehetséges összetevője, és ritkán a döntő.