Enrutamento VPN en Android: regras de política antes da táboa main

Unha ruta engadida á táboa main en Android parece correcta en calquera listaxe e aínda así non transporta o tráfico. A razón é que a táboa main é unha opción entre varias e non se consulta primeiro. O servizo de rede de Android constrúe regras de política que seleccionan unha táboa de enrutamento usando información que o enderezo de destino non contén — o uid da aplicación, unha marca no paquete, a interface pola que chegou — e a busca de destino ocorre despois, dentro da táboa que escollan esas regras.

Tres decisións nunha orde fixa

Un paquete de saída toma tres decisións separadas. Primeiro, unha regra de política decide que táboa de enrutamento se aplica. Segundo, unha ruta dentro desa táboa decide o seguinte salto e a interface de saída. Terceiro, os ganchos de netfilter deciden se o paquete sobrevive, se modifica ou se redirixe.

A orde importa porque cada etapa só pode responder á súa propia pregunta. Unha regra de devasado que acepta un paquete non selecciona unha táboa, e unha ruta engadida a unha táboa que ningunha regra selecciona é inerte. Boa parte da confusión coas VPN de Android vén de corrixir unha das tres e non observar ningún cambio, porque o fallo estaba noutra.

As marcas son un campo empaquetado, non unha etiqueta propia

Android empaqueta varios feitos no mesmo valor de marca: que rede se seleccionou, se unha aplicación escolleu unha rede explicitamente, se un socket está protexido fronte á VPN e bits relacionados con permisos. A cabeceira fwmark de AOSP define ese deseño para a árbore actual, e o deseño é un detalle interno da plataforma que cambia entre versións.

Por iso escribir un valor de marca completo con iptables -j MARK --set-mark é perigoso en Android. Non engade unha etiqueta; substitúe a selección de rede que o sistema xa fixo. O paquete pasa entón a coincidir con regras distintas, o que pode parecer que a VPN comezou a funcionar ou que unha aplicación non relacionada perdeu a conectividade, segundo que bits se sobrescribisen.

Se tes que tocar marcas, le primeiro o valor actual e usa unha máscara para que só se modifiquen os bits que entendes:

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

Unha marca de conexión é un obxecto separado dunha marca de paquete, e ningunha das dúas é unha ruta. Restaurar a marca nos paquetes de resposta é un paso distinto de seleccionar unha táboa na saída, por iso as correccións unidireccionais producen conexións que se abren e despois se colgan.

Quen posúe as regras e as táboas

O servizo de rede de Android, netd, crea as regras e as táboas por rede. O AOSP RouteController é onde se ensamblan esas regras para VPN, redes físicas e rangos de uid, e o seu ciclo de vida está ligado a eventos de rede máis que a un ficheiro de configuración.

Derivan dúas consecuencias. Primeira, as prioridades e os números de táboa que atopas nun teléfono son interioridades da compilación, non unha interface: números de aspecto idéntico noutra versión de Android poden significar algo completamente distinto. Segunda, o estado reconstrúese cando cambian as redes, así que unha regra inserida hoxe desde un shell root pode ter desaparecido tras o seguinte cambio de Wi-Fi.

Esa desaparición múldase a miúdo como que o sistema ignora unha ruta. O que ocorreu en realidade é que a regra que seleccionaba a táboa xa non existe, e a ruta dentro da táboa agora é inalcanzable desde a perspectiva do paquete. Revisa a lista de regras, non a de rutas, cando unha configuración que funcionaba deixa de facelo tras unha reconexión.

As preguntas sobre a orde dos ganchos non teñen resposta universal

A pregunta de se iptables se executa antes do enrutamento da VPN non se pode responder sen nomear o camiño do paquete. Un paquete xerado localmente atravesa o gancho output, onde un cambio de marca dispara unha comprobación de reenrutamento — unha segunda busca, non unha edición retroactiva da primeira. Un paquete que chega dun cliente en tethering atravesa o camiño prerouting e reenvíase no seu lugar, e as cadeas que o ven son outras.

Así, a mesma regra pode ser efectiva para o tráfico dunha aplicación e invisible para o tráfico en tethering, e un contador que queda en cero diche que camiño tomou o paquete, non se a regra é incorrecta. Usa contadores para establecer a ruta antes de cambiar calquera condición de coincidencia.

Esta é tamén a etapa na que un erro de enrutamento por política se volve difícil de ver. Enrutar cara a unha táboa que existe pero non contén o destino produce unha rede inalcanzable que parece un descarte do devasado, mentres que un descarte do devasado produce un tempo de espera que parece un burato negro de enrutamento.

Diagnostica dentro do sistema ou déixao en paz

Para unha revisión autorizada, establece catro feitos antes de tocar nada: o uid e o perfil da aplicación, a rede que Android seleccionou para ela, se a VPN inclúe esa aplicación e se o problema existe para ambas familias de enderezos. Unha exclusión por aplicación explica moitísimos informes de VPN que non funciona sen ningunha falla de enrutamento.

Despois le as regras, máscaras e táboas que están realmente en vigor, e mantén un cambio de rede dentro da xanela de observación. Se o comportamento cambia ao longo dunha reconexión, estás a ver un ciclo de vida xestionado, non unha ruta ausente.

Para requisitos ordinarios, usa os controis soportados: inclusión e exclusión por aplicación na aplicación VPN, e a selección de rede propia da plataforma para todo o que necesite unha ruta concreta. Se unha integración privilexiada ten que cooperar de verdade coa maquinaria de enrutamento, apunta á implementación da versión exacta de Android que soportas e mantén o seu ciclo de vida a través do compoñente que a posúe. Baleirar cadeas da plataforma ou inserir unha regra de alta prioridade converte un diagnóstico nun segundo xestor de rede, e o teléfono comportarase en consecuencia.