Android VPN-servilo: root ne igas la telefonon atingebla
Tri apartaj problemoj decidas ĉu telefono povas servi VPN-klientojn: la enira vojo, la privilegia modelo kaj la plusendado. Root tuŝas nur la mezan.
Root ŝanĝas, kiujn retajn operaciojn procezo rajtas provi. Ĝi ne donas al la telefono publike atingeblan adreson, ne rezervas eniran mapadon ĉe la operatoro kaj ne tenas demonon viva post restartigo. Se vi decidas, ĉu Android-telefono povas funkcii kiel VPN-servilo, apartigu tri demandojn: ĉu la celita kliento entute povas atingi la aŭskultanton, kiun privilegian modelon bezonas la servila efektivigo, kaj kio devas esti plusendata post kiam la tunelo staras.
Kiu devas atingi la telefonon, kaj de kie
Kliento en la sama permesita LAN kaj kliento sur poŝtelefonaj datumoj testas du malsamajn retojn. Unue decidiĝu pri la celita, ĉar la respondoj ne transiĝas. Ĉe Wi-Fi, nesolicitita enira trafiko kutime bezonas mapadon ĉe la supra enkursigilo kaj uzeblan publikan vojon preter ĝi. Ĉe la poŝtelefona reto, carrier-grade NAT signifas, ke enira IPv4 ofte ne disponeblas, kion ajn la telefono permesas.
Ĝuste tiun lastan punkton root ne povas tuŝi. La loka fajroŝirmilo de la telefono kaj la NAT de la operatoro estas malsamaj sistemoj, kaj ŝanĝi la unuan havas neniun efikon al la dua. Privata interfaca adreso, poŝtelefona-datuma ikono aŭ aŭskultanta soketo ne estas pruvo de atingeblo. Se la operatora vojo tamen ofertas tutmonde enkursigeblan IPv6, vi ankoraŭ bezonas intencan aŭskultantan kaj fajroŝirmilan politikon por ĝi; posedi adreson ne samas al akcepti konektojn.
| 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 |
Servado kaj plusendado estas du malsamaj sukcesoj
Kompletigita VPN-manpremo pruvas, ke la tunelo ekzistas. Ĝi ne pruvas, ke la kliento povas atingi LAN malantaŭ la telefono, nek ke la telefono povas funkcii kiel interreta eliro. Tiuj estas apartaj agordoj konstruitaj sur la interna adresplano, la itineroj, la revena konduto kaj strikte limigita plusenda politiko por la tasko, kiun vi vere volas.
La fiaskmaniero estas antaŭvidebla: la manpremo sukcesas, la kliento montras sin konektita, kaj nenio ŝargiĝas. Antaŭ ol sencimigi la klienton, decidu, kiun el la du roloj vi konstruas. Fora aliro al aparato en la reto de la telefono kaj interreta eliro tra plena tunelo bezonas malsamajn plusendajn regulojn, kaj doni ambaŭ kiam vi volis unu plilarĝigas la eksponon sen aldoni la kapablon, kiun vi petis.
La privilegia modelo estas elekto, ne root aŭ nenio
Konvencia OpenVPN-demono uzanta kernan TUN-aparaton bezonas la respondajn kapablojn, aliron al la aparata nodo kaj kunlaboron de la sekureca politiko de Android. Root ne estas ĝenerala escepto de SELinux; privilegia procezo ankoraŭ estas limigita de la platforma politiko. Tial duumaĵo, kiu komforte funkcias sur Linux-servilo, povas fiaski sur telefono sen evidenta eraro pri permesoj.
Uzantspaca porda efektivigo povas havi tute alian privilegian modelon, do la ofta aserto, ke ĉiu VPN-servilo en Android bezonas root, estas tro larĝa. Kion root aĉetas al vi estas la kapablo provi pli da operacioj, ne garantio ke ili estos permesitaj aŭ ke la rezulto estos atingebla.
La propra VPN-servoregistrado de Android estas ankoraŭ alia mekanismo. Ĝi donas al aplikaĵo administritan klientan interfacon kun difinita vivociklo; ĝi ne estas ĝenerala servila instalilo, kaj startigi demonon el terminalo ne donas al ĝi ĉiaman administradon, politikon laŭ aplikaĵo aŭ propran riparvojon.
Se vi volas elirpunkton, ŝanĝu la arkitekturon
Kiam la celo estas simple fora interreta eliro tra la telefono anstataŭ kongrueco kun ekzistanta OpenVPN-profilo, subtenata elirnodo en tega reto estas la pli taŭga dezajno. Tailscale dokumentas rolon de Android-elirnodo kun propraj paŝoj por registrado, rajtigo kaj klienta elekto.
La interŝanĝo estas reala kaj indas diri ĝin klare: vi akceptas alian protokolon, alian fido-modelon kaj dependecon de tiu konto kaj kunordiga servo. Ĝi ne igas neŝanĝitan OpenVPN-klienton aliĝi al la tega reto, kaj ĝi ne donas al vi OpenVPN-aŭskultanton sur publika adreso.
Kion la deplojo ankoraŭ bezonas
Kiun ajn vojon vi elektos, la operaciaj bazoj decidas ĉu ĝi pluvivos semajnon. Tenu la servilajn akreditaĵojn privataj, eldonu malsamajn klientajn identecojn kaj planu revokadon antaŭ ol vi bezonos ĝin. Decidu, kiel alvenas ĝisdatigoj, kio tenas la servon funkcianta fone kaj kiel ĝi resaniĝas post restartigo aŭ reta ŝanĝo.
Evitu la ŝparvojojn, kiuj aspektas oportunaj: eksmodan statikan duumaĵon, malmole koditajn interfacajn nomojn kaj startigan skripton, kiu forviŝas la ekzistantan fajroŝirmilan politikon. Poste akceptu la rezulton nur kontraŭ konkreta testo: rajtigita fora kliento atingas la celitan rimedon, malpermesitaj celoj restas neatingeblaj kaj la aparato revenas per si mem post la subtenata vivocikla evento. Root-aliro estas unu ebla ingredienco en tiu rezulto, kaj malofte la decida.