Root mijenja koje mrežne operacije proces smije pokušati. Ne daje telefonu javno dostupnu adresu, ne rezerviše dolazno mapiranje kod operatera i ne održava demon živim nakon restarta. Ako odlučujete može li Android telefon djelovati kao VPN server, razdvojite tri pitanja: može li predviđeni klijent uopšte doći do slušaoca, koji model privilegija treba implementaciji servera i šta se mora prosljeđivati kad je tunel podignut.

Ko mora doći do telefona i odakle

Klijent na istoj dozvoljenoj LAN mreži i klijent na mobilnim podacima testiraju dvije različite mreže. Prvo riješite koju namjeravate, jer se odgovori ne prenose. Na Wi-Fi mreži neželjeni dolazni saobraćaj obično traži mapiranje na uzvodnom ruteru i upotrebljiv javni put iza njega. Na mobilnoj mreži carrier-grade NAT znači da je dolazni IPv4 često nedostupan, bez obzira šta telefon dozvoljava.

Ta posljednja tačka je ona koju root ne može dotaknuti. Lokalni firewall telefona i NAT operatera su različiti sistemi, a promjena prvog ne utiče na drugi. Privatna adresa interfejsa, ikona mobilnih podataka ili socket koji sluša nisu dokaz dostupnosti. Ako put preko operatera ipak nudi globalno rutabilan IPv6, i dalje vam treba namjerna politika slušaoca i firewalla za njega; imati adresu nije isto što i prihvatati veze.

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

Posluživanje i prosljeđivanje su dva različita uspjeha

Završen VPN handshake dokazuje da tunel postoji. Ne dokazuje da klijent može doći do LAN mreže iza telefona, niti da telefon može služiti kao izlaz u internet. To su odvojene konfiguracije izgrađene na unutrašnjem planu adresa, rutama, ponašanju pri povratku i usko ograničenoj politici prosljeđivanja za zadatak koji zaista želite.

Način neuspjeha je predvidiv: handshake prođe, klijent pokaže povezanost, a ništa se ne učita. Prije nego što otklanjate greške na klijentu, odlučite koju od dvije uloge gradite. Daljinski pristup uređaju na telefonovoj mreži i izlaz u internet kroz puni tunel traže različita pravila prosljeđivanja, a odobravanje oba kada ste htjeli jedno širi izloženost bez dodavanja mogućnosti koju ste tražili.

Model privilegija je izbor, a ne root ili ništa

Konvencionalni OpenVPN demon koji koristi kernel TUN uređaj treba odgovarajuće sposobnosti, pristup čvoru uređaja i saradnju Androidove sigurnosne politike. Root nije sveobuhvatno izuzeće od SELinuxa; privilegovani proces je i dalje ograničen politikom platforme. Zato binarni program koji mirno radi na Linux serveru može pasti na telefonu bez očigledne greške o dozvolama.

Implementacija gatewaya u korisničkom prostoru može imati sasvim drugačiji model privilegija, pa je uvriježena tvrdnja da svaki VPN server na Androidu treba root preširoka. Root vam kupuje mogućnost da pokušate više operacija, ne garanciju da će biti dozvoljene ili da je rezultat dostupan.

Androidova vlastita registracija VPN usluge je opet odvojen mehanizam. Aplikaciji daje upravljani klijentski interfejs s definisanim životnim ciklusom; to nije univerzalni instalater servera, a pokretanje demona iz terminala ne daje mu upravljanje stalnog rada, politiku po aplikaciji ni vlastiti put oporavka.

Ako želite izlaznu tačku, promijenite arhitekturu

Kada je cilj jednostavno daljinski izlaz u internet kroz telefon, a ne kompatibilnost s postojećim OpenVPN profilom, bolje odgovara podržani izlazni čvor u overlay mreži. Tailscale dokumentuje ulogu Android izlaznog čvora s vlastitim koracima registracije, autorizacije i odabira klijenta.

Kompromis je stvaran i vrijedi ga jasno reći: prihvatate drugačiji protokol, drugačiji model povjerenja i zavisnost od tog računa i usluge koordinacije. To ne čini da se neizmijenjeni OpenVPN klijent pridruži overlay mreži i ne daje vam OpenVPN slušaoca na javnoj adresi.

Šta implementaciji još treba

Koji god put odabrali, operativne osnove odlučuju hoće li izdržati sedmicu. Čuvajte vjerodajnice servera privatnim, izdajte različite identitete klijenata i planirajte opoziv prije nego što vam zatreba. Odlučite kako stižu ažuriranja, šta održava uslugu pokrenutom u pozadini i kako se oporavlja nakon restarta ili promjene mreže.

Izbjegavajte prečice koje izgledaju zgodno: zastario statični binarni program, tvrdo kodirana imena interfejsa i startnu skriptu koja briše postojeću firewall politiku. Zatim prihvatite rezultat samo uz konkretan test: ovlašteni daljinski klijent dolazi do željenog resursa, zabranjena odredišta ostaju nedostupna, a uređaj se sam vraća nakon podržanog događaja životnog ciklusa. Root pristup je jedan mogući sastojak tog ishoda i rijetko odlučujući.

Povezani članci