Gweinydd VPN Android: nid yw root yn gwneud y ffôn yn gyrraeddadwy
Mae tri phroblem ar wahân yn penderfynu a all ffôn wasanaethu cleientiaid VPN: y llwybr i mewn, y model braint a'r anfon ymlaen. Dim ond yr un canol y mae root yn ei gyffwrdd.
Mae root yn newid pa weithrediadau rhwydwaith y caiff proses eu cynnig. Nid yw'n rhoi cyfeiriad cyhoeddus gyrraeddadwy i'r ffôn, nid yw'n cadw mapio i mewn gyda'r cludwr, ac nid yw'n cadw daemon yn fyw ar ôl ailgychwyn. Os ydych yn penderfynu a all ffôn Android weithredu fel gweinydd VPN, gwahaniaethwch dri chwestiwn: a all y cleient a fwriedir gyrraedd y gwrandawr o gwbl, pa fodel braint sydd ei angen ar weithrediad y gweinydd, a beth sydd raid ei anfon ymlaen unwaith y bydd y twnnel i fyny.
Pwy sydd raid cyrraedd y ffôn, ac o ble
Mae cleient ar yr un LAN a ganiateir a chleient ar ddata symudol yn profi dwy rwydwaith wahanol. Setlwch yr un a fwriedir yn gyntaf, oherwydd nid yw'r atebion yn trosglwyddo. Ar Wi-Fi, mae traffig i mewn heb ei ofyn fel arfer angen mapio ar y llwybrydd uwch a llwybr cyhoeddus defnyddiadwy y tu hwnt iddo. Ar y rhwydwaith cellog, mae NAT lefel cludwr yn golygu bod IPv4 i mewn yn aml heb fod ar gael, beth bynnag y mae'r ffôn yn ei ganiatáu.
Y pwynt olaf hwnnw yw'r un na all root ei gyffwrdd. Mae mur tân lleol y ffôn a NAT y cludwr yn systemau gwahanol, ac nid oes gan newid y cyntaf unrhyw effaith ar yr ail. Nid yw cyfeiriad rhyngwyneb preifat, eicon data symudol na soced sy'n gwrando yn dystiolaeth o gyrraeddadwyedd. Os yw llwybr y cludwr yn cynnig IPv6 y gellir ei lwybr yn fyd-eang, mae dal angen polisi gwrandawr a mur tân bwriadol ar ei gyfer; nid yw cael cyfeiriad yr un peth â derbyn cysylltiadau.
| 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 |
Mae gwasanaethu ac anfon ymlaen yn ddau lwyddiant gwahanol
Mae cydlawenderbyn VPN wedi'i gwblhau yn profi bod y twnnel yn bodoli. Nid yw'n profi y gall y cleient gyrraedd LAN y tu ôl i'r ffôn, ac nid yw'n profi y gall y ffôn weithredu fel allanfa i'r rhyngrwyd. Mae'r rheini'n ffurfweddiadau ar wahân a adeiladir ar gynllun y cyfeiriadau mewnol, y llwybrau, yr ymddygiad dychwelyd a pholisi anfon ymlaen cul ar gyfer y dasg yr ydych ei heisiau mewn gwirionedd.
Mae'r dull methu yn ragweladwy: mae'r cydlawenderbyn yn llwyddo, mae'r cleient yn dangos cysylltiad, ac nid oes dim yn llwytho. Cyn dadfygio'r cleient, penderfynwch pa un o'r ddwy rôl yr ydych yn ei hadeiladu. Mae mynediad o bell i ddyfais ar rwydwaith y ffôn ac allanfa ryngrwyd twnnel llawn angen gwahanol reolau anfon ymlaen, ac mae caniatáu'r ddwy pan oeddech am un yn ehangu'r amlygiad heb ychwanegu'r gallu y gwnaethoch ofyn amdano.
Mae'r model braint yn ddewis, nid root neu ddim
Mae daemon OpenVPN confensiynol sy'n defnyddio dyfais TUN cnewyllyn angen y galluoedd cyfatebol, mynediad i nod y ddyfais, a chydweithrediad polisi diogelwch Android. Nid yw root yn esemptiad cyffredinol rhag SELinux; mae proses freintiedig yn dal i gael ei chyfyngu gan bolisi'r platfform. Dyna pam y gall deuaidd sy'n rhedeg yn ddigon hapus ar weinydd Linux fethu ar ffôn heb wall amlwg am ganiatadau.
Gall gweithrediad porth yn y gofod defnyddiwr fod â model braint hollol wahanol, felly mae'r honiad cyffredin bod angen root ar bob gweinydd VPN ar Android yn rhy eang. Yr hyn y mae root yn ei brynu i chi yw'r gallu i geisio mwy o weithrediadau, nid gwarant y cânt eu caniatáu na bod y canlyniad yn gyrraeddadwy.
Mae cofrestriad gwasanaeth VPN Android ei hun yn fecanwaith arall eto. Mae'n rhoi rhyngwyneb cleient rheoledig i ap gyda chylch bywyd diffiniedig; nid yw'n osodwr gweinydd cyffredinol, ac nid yw cychwyn daemon o derfynell yn rhoi rheolaeth barhaus, polisi fesul ap na llwybr adfer ei hun iddo.
Os ydych am bwynt allanfa, newidiwch y bensaernïaeth
Pan fo'r nod yn syml yn allanfa ryngrwyd o bell drwy'r ffôn yn hytrach na chydnawsedd â phroffil OpenVPN sy'n bodoli, mae nod allanfa a gefnogir mewn rhwydwaith troshaen yn ffitio'n well. Mae Tailscale yn dogfennu rôl nod allanfa Android gyda'i gamau cofrestru, awdurdodi a dewis cleient ei hun.
Mae'r cyfnewid yn real ac yn werth ei ddweud yn blwmp: rydych yn derbyn protocol gwahanol, model ymddiriedaeth gwahanol a dibyniaeth ar y cyfrif a'r gwasanaeth cydlynu hwnnw. Nid yw'n gwneud i gleient OpenVPN heb ei newid ymuno â'r rhwydwaith troshaen, ac nid yw'n rhoi gwrandawr OpenVPN i chi ar gyfeiriad cyhoeddus.
Beth sydd ei angen ar y defnydd o hyd
Pa bynnag lwybr a gymerwch, mae'r pethau sylfaenol gweithredol yn penderfynu a fydd yn goroesi wythnos. Cadwch gymwysterau'r gweinydd yn breifat, cyhoeddwch hunaniaethau cleient gwahanol, a chynlluniwch ddirymu cyn i chi fod ei angen. Penderfynwch sut y daw diweddariadau, beth sy'n cadw'r gwasanaeth i redeg yn y cefndir, a sut y mae'n adfer ar ôl ailgychwyn neu newid rhwydwaith.
Osgoi'r llwybrau byr sy'n edrych yn gyfleus: deuaidd statig hen ffasiwn, enwau rhyngwyneb wedi'u caledu, a sgript gychwyn sy'n fflysio'r polisi mur tân presennol. Yna derbyniwch y canlyniad yn unig yn erbyn prawf pendant: mae cleient o bell awdurdodedig yn cyrraedd yr adnodd a fwriedir, mae cyrchfannau gwaharddedig yn aros yn anghyraeddadwy, ac mae'r ddyfais yn dychwelyd ohoni ei hun ar ôl y digwyddiad cylch bywyd a gefnogir. Mae mynediad root yn un cynhwysyn posibl yn y canlyniad hwnnw, ac anaml yw'r un penderfynol.