Androidin VPN-palvelin: root ei tee puhelimesta tavoitettavaa
Kolme erillistä ongelmaa ratkaisee, voiko puhelin palvella VPN-asiakkaita: saapuva reitti, oikeusmalli ja edelleenlähetys. Root koskee vain keskimmäistä.
Root muuttaa sitä, mitä verkkotoimintoja prosessi saa yrittää. Se ei anna puhelimelle julkisesti tavoitettavaa osoitetta, ei varaa saapuvaa operaattoritason mappausta eikä pidä daemonia elossa uudelleenkäynnistyksen jälkeen. Jos päätät, voiko Android-puhelin toimia VPN-palvelimena, erottele kolme kysymystä: voiko aiottu asiakas ylipäätään tavoittaa kuuntelijan, millaista oikeusmallia palvelintoteutus tarvitsee ja mitä on välitettävä, kun tunneli on pystyssä.
Kenen on päästävä puhelimeen ja mistä
Asiakas samassa sallitussa lähiverkossa ja asiakas matkapuhelindatassa testaavat kahta eri verkkoa. Ratkaise ensin aiottu, koska vastaukset eivät siirry. Wi-Fi-verkossa pyytämätön saapuva liikenne tarvitsee yleensä mappauksen ylävirran reitittimessä ja käyttökelpoisen julkisen reitin sen takana. Matkapuhelinverkossa carrier-grade NAT tarkoittaa, että saapuva IPv4 on usein käyttämättömissä riippumatta siitä, mitä puhelin sallii.
Juuri viimeiseen kohtaan root ei voi vaikuttaa. Puhelimen paikallinen palomuuri ja operaattorin NAT ovat eri järjestelmiä, eikä ensimmäisen muuttaminen vaikuta toiseen. Yksityinen liitäntäosoite, mobiilidatakuvake tai kuunteleva socket eivät ole todiste tavoitettavuudesta. Jos operaattorin reitti kuitenkin tarjoaa maailmanlaajuisesti reititettävän IPv6:n, tarvitset silti tarkoituksellisen kuuntelija- ja palomuurikäytännön sitä varten; osoitteen omistaminen ei ole sama kuin yhteyksien vastaanottaminen.
| 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 |
Palveleminen ja edelleenlähetys ovat kaksi eri onnistumista
Valmis VPN-kättely todistaa, että tunneli on olemassa. Se ei todista, että asiakas tavoittaa puhelimen takana olevan lähiverkon, eikä sitä, että puhelin voi toimia internetin uloskäyntinä. Ne ovat erillisiä kokoonpanoja, jotka rakentuvat sisäiselle osoitesuunnitelmalle, reiteille, paluukäyttäytymiselle ja kapeasti rajatulle edelleenlähetyskäytännölle sitä tehtävää varten, jota todella haluat.
Vikamuoto on ennustettava: kättely onnistuu, asiakas näyttää yhdistetyltä, eikä mitään lataudu. Ennen asiakkaan vianetsintää päätä, kumman kahdesta roolista rakennat. Etäkäyttö puhelimen verkossa olevaan laitteeseen ja internetin uloskäynti täydellä tunnelilla tarvitsevat erilaiset edelleenlähetyssäännöt, ja molempien myöntäminen, kun halusit yhtä, laajentaa altistusta lisäämättä pyytämääsi kykyä.
Oikeusmalli on valinta, ei root tai ei mitään
Tavanomainen ytimen TUN-laitetta käyttävä OpenVPN-daemon tarvitsee vastaavat kyvyt, pääsyn laitesolmuun ja Androidin tietoturvakäytännön yhteistyötä. Root ei ole yleinen poikkeus SELinuxista; etuoikeutettua prosessia rajoittaa yhä alustakäytäntö. Siksi Linux-palvelimella hyvin toimiva binääri voi epäonnistua puhelimessa ilman selvää virhettä käyttöoikeuksista.
Käyttäjäavaruuden yhdyskäytävätoteutuksella voi olla täysin erilainen oikeusmalli, joten väite, että jokainen Androidin VPN-palvelin tarvitsee rootin, on liian laaja. Root ostaa sinulle mahdollisuuden yrittää useampia toimintoja, ei takeita siitä, että ne sallitaan tai että tulos on tavoitettavissa.
Androidin oma VPN-palvelurekisteröinti on jälleen erillinen mekanismi. Se antaa sovellukselle hallitun asiakasliitännän määritellyllä elinkaarella; se ei ole yleinen palvelinasentaja, eikä daemonin käynnistäminen päätteestä anna sille jatkuvaa hallintaa, sovelluskohtaista käytäntöä tai omaa palautumispolkua.
Jos haluat uloskäynnin, muuta arkkitehtuuria
Kun tavoitteena on yksinkertaisesti etäinternet-uloskäynti puhelimen kautta eikä yhteensopivuus olemassa olevan OpenVPN-profiilin kanssa, tuettu overlay-verkon uloskäyntisolmu on paremmin sopiva ratkaisu. Tailscale dokumentoi Androidin uloskäyntisolmun roolin omine rekisteröinti-, valtuutus- ja asiakasvalintavaiheineen.
Vaihtokauppa on todellinen ja kannattaa sanoa suoraan: hyväksyt eri protokollan, eri luottamusmallin ja riippuvuuden tuosta tilistä ja koordinointipalvelusta. Se ei saa muuttamatonta OpenVPN-asiakasta liittymään overlay-verkkoon eikä anna sinulle OpenVPN-kuuntelijaa julkisessa osoitteessa.
Mitä käyttöönotto vielä tarvitsee
Minkä tahansa reitin valitset, operatiiviset perusteet ratkaisevat, kestääkö se viikon. Pidä palvelimen tunnistetiedot yksityisinä, myönnä erilliset asiakasidentiteetit ja suunnittele peruutus ennen kuin tarvitset sitä. Päätä, miten päivitykset saapuvat, mikä pitää palvelun käynnissä taustalla ja miten se toipuu uudelleenkäynnistyksen tai verkkomuutoksen jälkeen.
Vältä käteviltä näyttäviä oikoteitä: vanhentunut staattinen binääri, kovakoodatut liittymänimet ja käynnistysskripti, joka tyhjentää olemassa olevan palomuurikäytännön. Hyväksy tulos sitten vain konkreettisella testillä: valtuutettu etäasiakas tavoittaa aiotun resurssin, kielletyt kohteet pysyvät saavuttamattomina ja laite palaa itsestään tuetun elinkaaritapahtuman jälkeen. Root-käyttöoikeus on yksi mahdollinen ainesosa siinä tuloksessa, ja harvoin ratkaiseva.