Enrutament de polítiques a OpenWrt: la cadena que atrapa el DNS local

Els clients de la LAN resolen a través del túnel i les consultes del propi router, en silenci, no ho fan. Les actualitzacions de paquets, la sincronització de l’hora i el DNS dinàmic surten per l’enllaç ordinari mentre que cada consulta reenviada agafa la VPN, i res a la interfície no suggereix que existeixin dos camins diferents. L’explicació no és un error de la política sinó una qüestió de quin ganxo veu el paquet. Dos fluxos, una adreça de resolutor, i només un d’ells travessa el router. Separar-los és tota la solució.

Dos fluxos, una adreça de resolutor

El primer flux és el que la gent s’imagina. Un client pregunta al resolutor del router, el resolutor reenvia cap amunt, i aquest paquet reenviat passa pel router en la seva sortida. Aquest paquet és visible per a qualsevol cosa que observi el tràfic reenviat.

El segon flux no arriba mai de cap lloc. El crea el router, així que no hi ha cap paquet d’entrada ni cap pas de reenviament amb què coincidir.

Tots dos poden apuntar a la mateixa adreça de resolutor, i és exactament per això que la diferència és fàcil de passar per alt. Mateixa destinació, origen diferent, cadena diferent. Un cop veus l’origen, la resta del diagnòstic segueix.

Els paquets reenviats i els generats localment entren de manera diferent

El tràfic reenviat s’avalua quan arriba d’una altra interfície. Els paquets d’enrutament de polítiques ho exposen com una cadena de prerouting, i una regla col·locada allà veu cada paquet que travessa el router. Per això les consultes dels clients es comporten exactament com descriu la política, i per això el router l’ignora. La regla no és incorrecta, simplement està lligada a un ganxo que el router no arriba mai a tocar. Mou-la i la mateixa coincidència comença a funcionar.

El tràfic generat localment el crea un procés del router i entra pel camí de sortida. L’encamina la decisió del propi router i només troba la política si la política cobreix aquesta cadena. No hi ha cap interfície d’entrada amb què coincidir ni cap decisió de reenviament a observar.

És una propietat d’on neixen els paquets, no de cap paquet concret. Una regla escrita per a una cadena simplement no té opinió sobre l’altra. Cap quantitat d’ajust de regles ho canvia.

Trieu la cadena de sortida i després estrenyeu la coincidència

La solució és lligar la mateixa intenció també a la cadena de sortida, o traslladar-hi la regla quan el que t’importa són les consultes del propi router. En una instal·lació d’OpenWrt basada en un paquet d’enrutament de polítiques, això vol dir triar output en lloc de prerouting a la configuració de cadena de la regla. Mantén les dues regles si les dues poblacions necessiten cobertura.

Després estreny què fa coincidir la regla. Les adreces de resolutor de destinació al port que el resolutor fa servir realment són una decisió molt més petita que enviar al túnel tot el que origina el router.

Mantén les dues regles explícites en lloc d’intentar escriure’n una que cobreixi les dues cadenes. Les regles separades són més fàcils de llegir, i et permeten desactivar el camí del router sense destorbar el tràfic dels clients quan estàs depurant. També fan que els comptadors tinguin sentit d’un en un.

Mantén el transport propi del túnel fora de la regla

La connexió exterior del túnel també la crea el router. Una regla que enviï tot el tràfic generat localment al túnel encaminarà el túnel a través de si mateix, i no s’aixecarà gens.

L’accés de gestió és la segona víctima. Les sessions administratives originades al router, o les respostes a aquestes, poden ser arrossegades al túnel per una regla local massa àmplia i quedar inaccessibles des de la LAN.

Exclou el punt final del túnel de la coincidència i mantén la regla limitada a les adreces de resolutor. Això n’hi ha prou per al requisit de DNS i és prou petit per raonar-hi.

Prova les dues poblacions, no una

Observa el router fent la seva pròpia consulta i anota quina interfície l’ha portada. Repeteix la consulta des d’un amfitrió de la LAN i anota el camí que ha seguit. Els comptadors de les regles de política fan visibles les dues respostes sense endevinar.

Tracta els resultats com dues troballes. Un client que resol a través del túnel no diu res sobre el router, i un router que resol correctament no diu res sobre un client en un altre escoltador. Escriu-los com a línies separades al registre de canvis.

Comprova també el port: una regla que fa coincidir el port de destinació 53 es perd un resolutor al qual s’arriba per DNS over TLS al 853 o per un punt final HTTPS. Fes coincidir el transport que l’upstream configurat fa servir realment, i la fuita es tanca pel motiu correcte.