Server VPN në Android: root nuk e bën telefonin të arritshëm
Tre probleme të veçanta vendosin nëse një telefon mund t'u shërbejë klientëve VPN: rruga hyrëse, modeli i privilegjeve dhe përcjellja. root prek vetëm atë të mesmin.
root ndryshon cilat operacione rrjeti një proces mund të provojë. Nuk i jep telefonit një adresë publikisht të arritshme, nuk rezervon një mapim hyrës te operatori dhe nuk mban gjallë një daemon pas rinisjes. Nëse po vendosni nëse një telefon Android mund të veprojë si server VPN, ndani tre pyetje: a mundet klienti i synuar ta arrijë fare dëgjuesin, çfarë modeli privilegjesh kërkon implementimi i serverit dhe çfarë duhet përcjellë pasi tuneli është ngritur.
Kush duhet ta arrijë telefonin, dhe nga ku
Një klient në të njëjtën LAN të lejuar dhe një klient në të dhëna celulare testojnë dy rrjete të ndryshme. Vendosni së pari atë të synuar, sepse përgjigjet nuk transferohen. Në Wi-Fi, trafiku hyrës i pa kërkuar zakonisht kërkon një mapim te routeri i sipërm dhe një rrugë publike të përdorshme përtej tij. Në rrjetin celular, NAT në nivel operatori do të thotë që IPv4 hyrëse shpesh nuk është e disponueshme, pavarësisht se çfarë lejon telefoni.
Pikërisht kjo pikë e fundit është ajo që root nuk mund ta prekë. Firewall-i lokal i telefonit dhe NAT-i i operatorit janë sisteme të ndryshme, dhe ndryshimi i të parit nuk ka efekt te i dyti. Një adresë private ndërfaqeje, një ikonë e të dhënave celulare ose një socket që dëgjon nuk janë provë e arritshmërisë. Nëse rruga e operatorit ofron gjithsesi IPv6 të rrugëtueshme globalisht, ju ende keni nevojë për një politikë të qëllimshme dëgjuesi dhe firewall-i për të; të kesh një adresë nuk është njësoj si të pranosh lidhje.
| 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 |
Shërbimi dhe përcjellja janë dy suksese të ndryshme
Një shtrëngim duarsh VPN i përfunduar provon se tuneli ekziston. Nuk provon se klienti arrin një LAN pas telefonit, as se telefoni mund të shërbejë si dalje interneti. Këto janë konfigurime të veçanta, të ndërtuara mbi planin e brendshëm të adresave, rrugët, sjelljen e kthimit dhe një politikë përcjelljeje të ngushtë për detyrën që dëshironi vërtet.
Mënyra e dështimit është e parashikueshme: shtrëngimi i duarve ka sukses, klienti shfaqet i lidhur dhe asgjë nuk ngarkohet. Përpara se të korrigjoni klientin, vendosni cilën nga dy rolet po ndërtoni. Qasja në distancë te një pajisje në rrjetin e telefonit dhe dalja në internet përmes tunelit të plotë kërkojnë rregulla të ndryshme përcjelljeje, dhe dhënia e të dyjave kur donit njërën zgjeron ekspozimin pa shtuar aftësinë e kërkuar.
Modeli i privilegjeve është një zgjedhje, jo root ose asgjë
Një daemon konvencional OpenVPN që përdor një pajisje TUN të kernelit kërkon aftësitë përkatëse, akses te nyja e pajisjes dhe bashkëpunim nga politika e sigurisë e Android. root nuk është një përjashtim i përgjithshëm nga SELinux; një proces i privilegjuar mbetet i kufizuar nga politika e platformës. Kjo është arsyeja pse një binar që punon mirë në një server Linux mund të dështojë në një telefon pa një gabim të qartë rreth lejeve.
Një implementim portë në hapësirën e përdoruesit mund të ketë një model privilegjesh krejt të ndryshëm, prandaj pohimi i zakonshëm se çdo server VPN në Android kërkon root është shumë i gjerë. Ajo që root ju blen është aftësia për të provuar më shumë operacione, jo garancia se ato do të lejohen ose se rezultati do të jetë i arritshëm.
Regjistrimi i shërbimit VPN të vetë Android është përsëri një mekanizëm tjetër. I jep një aplikacioni një ndërfaqe klienti të menaxhuar me një cikël jete të përcaktuar; nuk është një instalues i përgjithshëm serveri, dhe nisja e një daemon nga terminali nuk i jep menaxhim të përhershëm, politikë për aplikacion ose një rrugë rikuperimi të vetën.
Nëse doni një pikë daljeje, ndryshoni arkitekturën
Kur qëllimi është thjesht një dalje interneti në distancë përmes telefonit dhe jo përputhshmëria me një profil OpenVPN ekzistues, një nyje daljeje e mbështetur në një rrjet mbitruk është dizajni më i përshtatshëm. Tailscale dokumenton një rol nyje daljeje për Android me hapat e vet të regjistrimit, autorizimit dhe përzgjedhjes së klientit.
Shkëmbimi është i vërtetë dhe ia vlen të thuhet qartë: ju pranoni një protokoll tjetër, një model tjetër besimi dhe një varësi nga ai llogari dhe shërbim koordinimi. Nuk bën që një klient OpenVPN i pandryshuar të bashkohet me rrjetin mbitruk dhe nuk ju jep një dëgjues OpenVPN në një adresë publike.
Çfarë i duhet ende vendosjes
Cilën rrugë të zgjidhni, bazat operacionale vendosin nëse do të mbijetojë një javë. Mbani private kredencialet e serverit, lëshoni identitete klienti të ndryshme dhe planifikoni revokimin përpara se t'ju duhet. Vendosni si vijnë përditësimet, çfarë e mban shërbimin duke punuar në sfond dhe si rikuperohet pas një rinisjeje ose një ndryshimi rrjeti.
Shmangni shkurtoret që duken të rehatshme: një binar statik i vjetruar, emra ndërfaqesh të koduar fort dhe një skript nisjeje që fshin politikën ekzistuese të firewall-it. Pastaj pranoni rezultatin vetëm përballë një testi konkret: një klient në distancë i autorizuar arrin burimin e synuar, destinacionet e ndaluara mbeten të padisponueshme dhe pajisja kthehet vetë pas ngjarjes së mbështetur të ciklit të jetës. Qasja root është një përbërës i mundshëm i atij rezultati dhe rrallë ai vendimtar.