Encaminament VPN a l'Android: regles de política abans de la taula main

Una ruta afegida a la taula main a l'Android sembla correcta a tots els llistats i tot i així no transporta el tràfic. La raó és que la taula main és una opció entre diverses i no es consulta primer. El servei de xarxa de l'Android construeix regles de política que trien una taula d'encaminament amb informació que l'adreça de destinació no conté — l'uid de l'aplicació, una marca al paquet, la interfície per la qual ha arribat — i la consulta de destinació passa després, dins de la taula que hagin triat aquestes regles.

Tres decisions en un ordre fix

Un paquet de sortida pren tres decisions separades. Primer, una regla de política decideix quina taula d'encaminament s'aplica. Segon, una ruta dins d'aquesta taula decideix el següent salt i la interfície de sortida. Tercer, els ganxos de netfilter decideixen si el paquet sobreviu, es modifica o es redirigeix.

L'ordre importa perquè cada etapa només pot respondre la seva pròpia pregunta. Una regla de tallafocs que accepta un paquet no tria cap taula, i una ruta afegida a una taula que cap regla tria és inert. Bona part de la confusió al voltant de les VPN a l'Android ve de corregir una de les tres i no veure cap canvi, perquè la fallada era en una altra.

Les marques són un camp empaquetat, no una etiqueta pròpia

L'Android empaqueta diversos fets en el mateix valor de marca: quina xarxa s'ha triat, si una aplicació ha triat explícitament una xarxa, si un sòcol està protegit de la VPN i bits relacionats amb permisos. La capçalera fwmark de l'AOSP defineix aquesta disposició per a l'arbre actual, i la disposició és un detall intern de la plataforma que canvia entre versions.

Per això escriure un valor de marca sencer amb iptables -j MARK --set-mark és perillós a l'Android. No afegeix una etiqueta; substitueix la selecció de xarxa que el sistema ja havia fet. Llavors el paquet coincideix amb regles diferents, cosa que pot semblar que la VPN ha començat a funcionar o que una aplicació no relacionada ha perdut la connexió, segons quins bits s'hagin sobreescrit.

Si heu de tocar marques, llegiu primer el valor actual i feu servir una màscara perquè només es modifiquin els bits que enteneu:

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

Una marca de connexió és un objecte separat d'una marca de paquet, i cap de les dues és una ruta. Restaurar la marca als paquets de resposta és un pas diferent de triar una taula a la sortida, i per això les correccions unidireccionals produeixen connexions que s'obren i després es pengen.

Qui posseeix les regles i les taules

El servei de xarxa de l'Android, netd, crea les regles i les taules per xarxa. El AOSP RouteController és on s'assemblen aquestes regles per a VPN, xarxes físiques i rangs d'uid, i el seu cicle de vida està lligat a esdeveniments de xarxa més que no pas a un fitxer de configuració.

Se'n deriven dues conseqüències. Primera, les prioritats i els números de taula que trobeu en un telèfon són detalls interns de la compilació, no una interfície: números d'aspecte idèntic en una altra versió de l'Android poden significar una cosa completament diferent. Segona, l'estat es reconstrueix quan canvien les xarxes, així que una regla inserida avui des d'un shell root pot haver desaparegut després del següent canvi de Wi-Fi.

Aquesta desaparició sovint es descriu com que el sistema ignora una ruta. El que ha passat en realitat és que la regla que triava la taula ja no existeix, i la ruta dins de la taula ara és inabastable des de la perspectiva del paquet. Reviseu la llista de regles, no la de rutes, quan una configuració que funcionava deixa de funcionar després d'una reconnexió.

Les preguntes sobre l'ordre dels ganxos no tenen resposta universal

La pregunta de si iptables s'executa abans de l'encaminament de la VPN no es pot respondre sense anomenar el camí del paquet. Un paquet generat localment travessa el ganxo output, on un canvi de marca provoca una comprovació de reencaminament — una segona consulta, no una edició retroactiva de la primera. Un paquet que arriba d'un client en tethering travessa el camí prerouting i es reenvia en lloc d'allò, i les cadenes que el veuen són unes altres.

Així, la mateixa regla pot ser efectiva per al tràfic d'una aplicació i invisible per al tràfic en tethering, i un comptador que es queda a zero us diu quin camí ha pres el paquet, no si la regla és incorrecta. Feu servir comptadors per establir el camí abans de canviar qualsevol condició de coincidència.

Aquesta és també l'etapa on un error d'encaminament per política es fa difícil de veure. Encaminar cap a una taula que existeix però no conté la destinació produeix una xarxa inabastable que sembla un descart del tallafocs, mentre que un descart del tallafocs produeix un temps d'espera que sembla un forat negre d'encaminament.

Diagnostiqueu dins del sistema o deixeu-lo estar

Per a una revisió autoritzada, establiu quatre fets abans de tocar res: l'uid i el perfil de l'aplicació, la xarxa que l'Android ha triat per a ella, si la VPN inclou aquesta aplicació, i si el problema existeix per a les dues famílies d'adreces. Una exclusió per aplicació explica molts informes de VPN que no funciona sense cap fallada d'encaminament.

Després llegiu les regles, màscares i taules que estan realment en vigor, i manteniu un canvi de xarxa dins de la finestra d'observació. Si el comportament canvia en una reconnexió, esteu mirant un cicle de vida gestionat, no una ruta que falta.

Per a requisits ordinaris, feu servir els controls suportats: inclusió i exclusió per aplicació a l'aplicació VPN, i la selecció de xarxa pròpia de la plataforma per a tot el que necessiti un camí específic. Si una integració privilegiada ha de cooperar de debò amb la maquinària d'encaminament, apunteu a la implementació de la versió exacta de l'Android que suporteu i manteniu-ne el cicle de vida a través del component que la posseeix. Buidar cadenes de la plataforma o inserir una regla de prioritat alta converteix un diagnòstic en un segon gestor de xarxa, i el telèfon es comportarà en conseqüència.