VPN server sa Android: hindi ginagawang maabot ang telepono ng root
Tatlong magkakahiwalay na problema ang nagtatakda kung makapaglilingkod ang telepono sa mga VPN client: ang papasok na landas, ang modelo ng pribilehiyo at ang pagpapasa. Ang root ay humahawak lamang sa gitna.
Binabago ng root kung aling mga operasyon sa network ang maaaring subukan ng isang proseso. Hindi nito binibigyan ang telepono ng address na maabot ng publiko, hindi ito nagrereserba ng papasok na mapping sa carrier, at hindi nito pinananatiling buhay ang isang daemon pagkatapos ng reboot. Kung nagpapasya ka kung maaaring gumana ang isang Android phone bilang VPN server, paghiwalayin ang tatlong tanong: maaabot ba ng nilalayong client ang listener, anong modelo ng pribilehiyo ang kailangan ng implementasyon ng server, at ano ang kailangang ipasa kapag nakatayo na ang tunnel.
Sino at saan galing ang dapat makarating sa telepono
Ang client sa parehong pinapayagang LAN at ang client sa mobile data ay sumusubok ng dalawang magkaibang network. Unahing pasyahan ang nilalayon, dahil hindi naglilipat ang mga sagot. Sa Wi-Fi, ang hindi hinihinging papasok na trapiko ay karaniwang nangangailangan ng mapping sa upstream router at ng magagamit na pampublikong landas sa kabila nito. Sa cellular, ang carrier-grade NAT ay nangangahulugang ang papasok na IPv4 ay madalas na hindi available, anuman ang payagan ng telepono.
Iyon ding huling punto ang hindi kayang hawakan ng root. Ang lokal na firewall ng telepono at ang NAT ng carrier ay magkaibang sistema, at ang pagbabago sa una ay walang epekto sa pangalawa. Ang pribadong address ng interface, icon ng mobile data o socket na nakikinig ay hindi patunay ng pagiging maabot. Kung ang landas ng carrier ay nag-aalok pa rin ng globally routable IPv6, kailangan mo pa rin ng sinadyang patakaran sa listener at firewall para dito; ang pagkakaroon ng address ay hindi katulad ng pagtanggap ng mga koneksyon.
| 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 |
Ang pagseserbisyo at pagpapasa ay dalawang magkaibang tagumpay
Ang nakumpletong VPN handshake ay nagpapatunay na may tunnel. Hindi nito pinapatunayan na maaabot ng client ang LAN sa likod ng telepono, ni na maaaring magsilbing internet exit ang telepono. Ang mga iyon ay magkakahiwalay na configuration na itinayo sa panloob na plano ng address, mga ruta, pag-uugali sa pagbabalik at makitid na patakaran sa pagpapasa para sa gawaing talagang gusto mo.
Ang paraan ng pagpalya ay mahuhulaan: nagtagumpay ang handshake, nagpapakita ng konektado ang client, at walang naglo-load. Bago i-debug ang client, pasyahan kung alin sa dalawang papel ang ginagawa mo. Ang malayuang pag-access sa device sa network ng telepono at ang internet exit sa buong tunnel ay nangangailangan ng magkaibang panuntunan sa pagpapasa, at ang pagbibigay ng dalawa kapag isa ang gusto mo ay nagpapalawak ng pagkakalantad nang hindi nagdadagdag ng kakayahang hiniling mo.
Ang modelo ng pribilehiyo ay pagpili, hindi root o wala
Ang karaniwang OpenVPN daemon na gumagamit ng kernel TUN device ay nangangailangan ng kaukulang kakayahan, access sa node ng device at pakikipagtulungan ng patakaran sa seguridad ng Android. Ang root ay hindi isang pangkalahatang pagbubukod mula sa SELinux; ang isang pribilehiyadong proseso ay nakagapos pa rin ng patakaran ng platform. Iyon ang dahilan kung bakit ang isang binary na maayos na tumatakbo sa Linux server ay maaaring mabigo sa telepono nang walang malinaw na error tungkol sa mga pahintulot.
Ang implementasyon ng gateway sa user space ay maaaring may ganap na ibang modelo ng pribilehiyo, kaya ang karaniwang pahayag na bawat VPN server sa Android ay nangangailangan ng root ay masyadong malawak. Ang binibili ng root para sa iyo ay ang kakayahang subukan ang mas maraming operasyon, hindi ang garantiya na papayagan ang mga ito o maaabot ang resulta.
Ang sariling pagpaparehistro ng serbisyo ng VPN ng Android ay isa na namang hiwalay na mekanismo. Nagbibigay ito sa app ng pinamamahalaang interface ng client na may tinukoy na lifecycle; hindi ito pangkalahatang installer ng server, at ang pagsisimula ng daemon mula sa terminal ay hindi nagbibigay nito ng palagiang pamamahala, patakaran sa bawat app o sariling landas ng pagbawi.
Kung gusto mo ng exit point, baguhin ang arkitektura
Kapag ang layunin ay simpleng malayuang internet exit sa pamamagitan ng telepono at hindi pagkakatugma sa umiiral na profile ng OpenVPN, ang sinusuportahang exit node sa overlay network ang mas angkop na disenyo. Idinodokumento ng Tailscale ang papel ng exit node para sa Android kasama ang sarili nitong mga hakbang sa pagpaparehistro, pagpapahintulot at pagpili ng client.
Ang palitan ay totoo at dapat sabihin nang malinaw: tinatanggap mo ang ibang protocol, ibang modelo ng tiwala at pag-asa sa account at serbisyo ng koordinasyong iyon. Hindi nito napapasali ang hindi binagong OpenVPN client sa overlay network, at hindi ka nito binibigyan ng OpenVPN listener sa pampublikong address.
Ano pa ang kailangan ng deployment
Anuman ang landas na piliin mo, ang mga pangunahing operasyonal ang nagtatakda kung tatagal ito ng isang linggo. Panatilihing pribado ang mga kredensyal ng server, maglabas ng magkaibang pagkakakilanlan ng client, at planuhin ang pagpapawalang-bisa bago mo ito kailanganin. Pasyahan kung paano dumarating ang mga update, ano ang nagpapanatiling tumatakbo ang serbisyo sa background at paano ito nakakabawi pagkatapos ng reboot o pagbabago ng network.
Iwasan ang mga shortcut na mukhang maginhawa: lipas na static binary, hardcoded na pangalan ng interface at startup script na nag-aalis ng umiiral na patakaran ng firewall. Pagkatapos, tanggapin ang resulta lamang laban sa isang konkretong pagsubok: naaabot ng awtorisadong malayuang client ang nilalayong resource, nananatiling hindi available ang mga ipinagbabawal na destinasyon, at kusang bumabalik ang device pagkatapos ng sinusuportahang kaganapan sa lifecycle. Ang access ng root ay isang posibleng sangkap sa resultang iyon, at bihirang ang nagpapasya.