Android VPN-routing: beliedsregels foar de tabel main

In rûte dy't op Android oan 'e tabel main tafoege wurdt, liket yn elk oersjoch korrekt en draacht dochs it ferkear net. De reden is dat de tabel main ien opsje fan ferskate is, en hy wurdt net earst rieplachte. De netwurkstsjinst fan Android bout beliedsregels dy't in routingtabel kieze mei ynformaasje dy't it bestimmingsadres net befettet — de uid fan 'e applikaasje, in markearring op it pakket, de ynterface wêr't it op oankaam — en it sykjen nei de bestimming bart dêrnei, binnen de tabel dy't dy regels keazen hawwe.

Trije besluten yn in fêste folchoarder

In pakket dat útgiet nimt trije aparte besluten. Earst beslút in beliedsregel hokker routingtabel jildt. Twadde beslút in rûte yn dy tabel de folgjende hop en de útgeande ynterface. Tredde beslute netfilter-haken oft it pakket oerlibbet, feroare of om laat wurdt.

De folchoarder is wichtich, want elke stap kin allinnich syn eigen fraach beantwurdzje. In firewallregel dy't in pakket akseptearret, kiest gjin tabel, en in rûte dy't oan in tabel tafoege wurdt dy't gjin inkelde regel kiest, is ynaktyf. In grut part fan 'e betizing om Android-VPN's hinne komt derfan dat men ien fan 'e trije reparearret en gjin feroaring sjocht, om't de flater yn in oare siet.

Markearrings binne in ynpakt fjild, gjin label dat jo besitte

Android pakt ferskate feiten yn deselde markearringswaarde: hokker netwurk keazen is, oft in applikaasje in netwurk eksplisyt keazen hat, oft in socket tsjin it VPN beskerme is en bits oangeande tastimmingen. De fwmark-kop fan AOSP definiearret dy yndieling foar de hjoeddeiske beam, en de yndieling is in ynterne saak fan it platfoarm dy't tusken útjeften feroaret.

Dêrom is it op Android gefaarlik om in hiele markearringswaarde te skriuwen mei iptables -j MARK --set-mark. It foeget gjin label ta; it ferfangt de netwurkseleksje dy't it systeem al dien hat. It pakket past dan by oare regels, wat lykje kin as is it VPN begûn te wurkjen, of as hat in net besibbe applikaasje de ferbining ferlern, ôfhinklik fan hokker bits oerskreaun binne.

As jo markearrings oanreitsje moatte, lês dan earst de hjoeddeiske wearde en brûk in masker sadat allinnich de bits dy't jo begripe feroare wurde:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

In ferbiningsmarkearring is in apart objekt fan in pakketmarkearring, en gjin fan beide is in rûte. It weromsetten fan 'e markearring op antwurdpakketten is in oare stap as it kiezen fan in tabel by it útgien, en dêrom leverje ienrjochtingsreparaasjes ferbiningen dy't iepengeane en dan hingje.

Wa't de regels en tabellen besit

De netwurkstsjinst fan Android, netd, makket de regels en de tabellen per netwurk. AOSP RouteController is it plak dêr't dy regels gearstald wurde foar VPN's, fysike netwurken en uid-berikken, en syn libbenssyklus is keppele oan netwurkbarrens ynstee fan oan in konfiguraasjebestân.

Twa gefolgen folgje. Earst binne prioriteiten en tabelnûmers dy't jo op ien tillefoan fine, bou-ynterne details, gjin ynterface: nûmers dy't der itselde útsjen op in oare Android-ferzje kinne hiel wat oars betsjutte. Twadde wurdt de tastân op 'e nij boud as netwurken feroarje, dat in regel dy't hjoed fan in root-shell ôf ynfoege is, kin nei de folgjende Wi-Fi-oergong fuort wêze.

Dat ferdwinen wurdt faak rapportearre as soe it systeem in rûte negearje. Wat feitlik barde, is dat de regel dy't de tabel keas net mear bestiet, en de rûte yn 'e tabel is no ûnberikber út it eachpunt fan it pakket. Kontrolearje de regellist, net de rûtelist, as in wurkjende konfiguraasje nei in werferbining ophâldt te wurkjen.

Fragen oer de folchoarder fan 'e haken hawwe gjin algemien antwurd

De fraach oft iptables foar it VPN-routing rint, is net te beantwurdzjen sûnder it paad fan it pakket te neamen. In lokaal oanmakke pakket giet troch de output-haak, wêr't in markearringsferoaring in wer-routingkontrôle útlokket — in twadde syktocht, gjin efterôf bewurkjen fan 'e earste. In pakket dat fan in tethering-klant komt, giet troch it prerouting-paad en wurdt ynstee trochstjoerd, en de keatlingen dy't it sjogge binne oare.

Sa kin deselde regel effektyf wêze foar it ferkear fan in applikaasje en ûnsichtber foar tethering-ferkear, en in teller dy't op nul bliuwt fertelt jo hokker paad it pakket naam, net oft de regel ferkeard is. Brûk tellers om it paad fêst te stellen foar't jo in matchbetingst feroarje.

Dit is ek de stap wêr't in beliedsroutingflater dreech sichtber wurdt. Routing nei in tabel dy't bestiet mar de bestimming net befettet, leveret in netwurk ûnberikber op dat op in firewall-drop liket, wylst in firewall-drop in time-out jout dy't op in routing-swart gat liket.

Diagnostisearje binnen it systeem, of lit it gewurde

Foar in autorisearre resinsje stelle jo fjouwer feiten fêst foar't jo eat oanreitsje: de uid en it profyl fan 'e applikaasje, it netwurk dat Android derfoar keas, oft it VPN dy applikaasje uberhaupt omfettet, en oft it probleem foar beide adresfamyljes bestiet. In útsluting per applikaasje ferklearret in soad rapporten fan VPN wurket net sûnder inkelde routingflater.

Lês dan de regels, maskers en tabellen dy't echt jilde, en hâld in netwurkwiksel binnen it observaasjefinster. As it gedrach oer in werferbining feroaret, sjogge jo nei in beheard libbenssyklus, net nei in ûntbrekkende rûte.

Foar gewoane easken brûk de stipe bestjoeringsmiddels: yntsluting en útsluting per applikaasje yn 'e VPN-applikaasje, en de eigen netwurkseleksje fan it platfoarm foar alles dat in spesifyk paad nedich hat. As in privilegiearre yntegraasje wier mei de routingmasjinerie gearwurkje moat, rjochtsje jo op 'e ymplemintaasje fan 'e krekte Android-ferzje dy't jo stypje en ûnderhâlde jo syn libbenssyklus fia it komponint dat der eigner fan is. It leegjen fan platfoarmkeatlingen of it ynfoegjen fan in regel mei hege prioriteit makket fan in diagnoaze in twadde netwurkbehearder, en de tillefoan sil dêrneffens gedrage.