Android VPN-roetebepaling: beleidsreëls voor die main-tabel

'n Roete wat by die main-tabel op Android gevoeg word, lyk in elke lys korrek en dra tog nie die verkeer nie. Die rede is dat die main-tabel een opsie onder verskeie is, en dit word nie eerste geraadpleeg nie. Android se netwerkdiens bou beleidsreëls wat 'n roetebepalingstabel kies met inligting wat die bestemmingsadres nie bevat nie — die toepassing se uid, 'n merk op die pakket, die koppelvlak waarop dit aangekom het — en die bestemmingsopsoek gebeur daarna, binne watter tabel daardie reëls ook al gekies het.

Drie besluite in 'n vaste volgorde

'n Pakket op pad uit neem drie afsonderlike besluite. Eerstens besluit 'n beleidsreël watter roetebepalingstabel geld. Tweedens besluit 'n roete binne daardie tabel die volgende hop en die uitgaande koppelvlak. Derdens besluit netfilter-hake of die pakket oorleef, gewysig word of herlei word.

Die volgorde maak saak omdat elke stadium net sy eie vraag kan beantwoord. 'n Firewall-reël wat 'n pakket aanvaar, kies nie 'n tabel nie, en 'n roete wat by 'n tabel gevoeg is wat geen reël kies nie, is onaktief. Baie van die verwarring rondom Android VPN's kom daaruit dat 'n mens een van die drie regmaak en geen verandering sien nie, want die fout was in 'n ander een.

Merkwaardes is 'n verpakte veld, nie 'n etiket wat jy besit nie

Android verpak verskeie feite in dieselfde merkwaarde: watter netwerk gekies is, of 'n toepassing eksplisiet 'n netwerk gekies het, of 'n socket teen die VPN beskerm is, en bits wat met toestemmings verband hou. Die AOSP fwmark-kop definieer daardie uitleg vir die huidige boom, en die uitleg is 'n platform-interne ding wat tussen vrystellings verander.

Dit is waarom die skryf van 'n hele merkwaarde met iptables -j MARK --set-mark gevaarlik is op Android. Dit voeg nie 'n etiket by nie; dit vervang die netwerkkeuse wat die stelsel reeds gemaak het. Die pakket pas dan by ander reëls, wat kan lyk of die VPN begin werk het, of of 'n onverwante toepassing konnektiwiteit verloor het, afhangende van watter bits oorskryf is.

As jy merke moet aanraak, lees eers die huidige waarde en gebruik 'n masker sodat net die bits wat jy verstaan gewysig word:

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

'n Verbindingsmerk is 'n aparte objek van 'n pakketmerk, en nie een daarvan is 'n roete nie. Om die merk op antwoordpakette te herstel is 'n aparte stap van om 'n tabel op pad uit te kies, en daarom lewer eenrigting-regstellings verbindings wat oopgaan en dan hang.

Wie besit die reëls en tabelle

Android se netwerkdiens, netd, skep die reëls en die per-netwerk-tabelle. Die AOSP RouteController is waar daardie reëls vir VPN's, fisiese netwerke en uid-reekse saamgestel word, en sy lewensiklus is aan netwerkgebeurtenisse gekoppel eerder as aan 'n konfigureerlêer.

Twee gevolge volg. Eerstens is prioriteite en tabelnommers wat jy op een selfoon vind bou-interne dinge, nie 'n koppelvlak nie: eenderslykende nommers op 'n ander Android-weergawe kan heeltemal iets anders beteken. Tweedens word die toestand herbou wanneer netwerke verander, so 'n reël wat vandag uit 'n root-dop ingevoeg is, kan ná die volgende Wi-Fi-oorgang weg wees.

Daardie verdwyning word dikwels gerapporteer asof die stelsel 'n roete ignoreer. Wat eintlik gebeur het, is dat die reël wat die tabel gekies het nie meer bestaan nie, en die roete binne die tabel is nou onbereikbaar uit die pakket se oogpunt. Kyk na die reëlls, nie die roetelys nie, wanneer 'n werkende konfigurasie ná 'n herverbinding ophou werk.

Vrae oor haakvolgorde het geen universele antwoord nie

Die vraag of iptables voor VPN-roetebepaling loop, kan nie beantwoord word sonder om die pakketpad te benoem nie. 'n Plaaslik gegenereerde pakket gaan deur die output-haak, waar 'n merkverandering 'n herroetebepalingskontrole veroorsaak — 'n tweede opsoek, nie 'n terugwerkende wysiging van die eerste nie. 'n Pakket wat van 'n getetherde kliënt arriveer, gaan deur die prerouting-pad en word eerder aangestuur, en die kettings wat dit sien, is ander.

Dieselfde reël kan dus doeltreffend wees vir 'n toepassing se verkeer en onsigbaar vir getetherde verkeer, en 'n teller wat op nul bly, vertel jou watter pad die pakket gevolg het, nie of die reël verkeerd is nie. Gebruik tellers om die pad vas te stel voordat jy enige passingstoestand verander.

Dit is ook die stadium waar 'n beleidsroetebepalingsfout moeilik sigbaar word. Roetebepaling na 'n tabel wat bestaan maar nie die bestemming bevat nie, lewer 'n netwerk-onbereikbaar wat soos 'n firewall-val lyk, terwyl 'n firewall-val 'n time-out lewer wat soos 'n roetebepalings-swartgat lyk.

Diagnoseer binne die stelsel, of los dit uit

Vir 'n gemagtigde ondersoek, stel vier feite vas voordat jy iets aanraak: die toepassing se uid en profiel, die netwerk wat Android daarvoor gekies het, of die VPN daardie toepassing hoegenaamd insluit, en of die probleem by beide adresfamilies bestaan. 'n Per-toepassing-uitsluiting verduidelik baie verslae van die vorm VPN werk nie sonder enige roetebepalingsfout.

Lees dan die reëls, maskers en tabelle wat werklik van krag is, en hou 'n netwerkwisseling binne die waarnemingsvenster. As die gedrag oor 'n herverbinding verander, kyk jy na 'n bestuurde lewensiklus, nie na 'n ontbrekende roete nie.

Vir gewone vereistes, gebruik die ondersteunde beheermiddels: per-toepassing-insluiting en -uitsluiting in die VPN-toepassing, en die platform se eie netwerkkeuse vir enigiets wat 'n spesifieke pad nodig het. As 'n bevoorregte integrasie werklik met die roetebepalingsmasjinerie moet saamwerk, teiken die implementering van die presiese Android-weergawe wat jy ondersteun en onderhou sy lewensiklus deur die komponent wat dit besit. Om platformkettings te spoel of 'n hoëprioriteit-reël in te voeg, verander 'n diagnose in 'n tweede netwerkbestuurder, en die selfoon sal daarvolgens optree.