Enrutamento de políticas en OpenWrt: a cadea que atrapa o DNS local

Os clientes da LAN resolven a través do túnel e as consultas do propio router, en silencio, non o fan. As actualizacións de paquetes, a sincronización horaria e o DNS dinámico saen pola ligazón ordinaria mentres cada consulta reenviada toma a VPN, e nada na interface suxire que existan dúas rutas distintas. A explicación non é un erro da política senón unha cuestión de que gancho ve o paquete. Dous fluxos, un enderezo de resolutor, e só un deles cruza o router. Sepáralos é toda a solución.

Dous fluxos, un enderezo de resolutor

O primeiro fluxo é o que a xente imaxina. Un cliente pregunta ao resolutor do router, o resolutor reenvía cara arriba, e ese paquete reenviado pasa polo router de saída. Ese paquete é visible para calquera cousa que observe o tráfico reenviado.

O segundo fluxo nunca chega de ningún sitio. Créao o router, así que non hai paquete entrante nin paso de reenvío que coincida.

Ambos poden apuntar ao mesmo enderezo de resolutor, e por iso mesmo a diferenza pasa facilmente desapercibida. Mesmo destino, distinta orixe, distinta cadea. En canto ves a orixe, o resto do diagnóstico segue.

Os paquetes reenviados e os xerados localmente entran de forma distinta

O tráfico reenviado avalíase cando chega doutra interface. Os paquetes de enrutamento de políticas expoñen iso como unha cadea de prerouting, e unha regra colocada alí ve cada paquete que cruza o router. Por iso as consultas dos clientes compórtanse exactamente como describe a política, e por iso o router a ignora. A regra non está mal, simplemente está unida a un gancho que o router nunca alcanza. Móvea e a mesma coincidencia comeza a funcionar.

O tráfico xerado localmente créao un proceso do router e entra na ruta de saída. Encamínao a decisión do propio router e só atopa a política se a política cobre esa cadea. Non hai interface de entrada que coincida nin decisión de reenvío que observar.

É unha propiedade de onde nacen os paquetes, non de ningún paquete concreto. Unha regra escrita para unha cadea simplemente non ten opinión sobre a outra. Ningunha cantidade de axuste de regras o cambia.

Escolle a cadea de saída e despois estreita a coincidencia

A solución é unir a mesma intención tamén á cadea de saída, ou trasladar alí a regra cando o que che importa son as consultas do propio router. Nunha instalación de OpenWrt baseada nun paquete de enrutamento de políticas, iso significa escoller output en lugar de prerouting no axuste de cadea da regra. Mantén as dúas regras se ambas as poboacións necesitan cobertura.

Despois estreita o que coincide coa regra. Os enderezos de resolutor de destino no porto que o resolutor usa realmente son unha decisión moito máis pequena que mandar ao túnel todo o que orixina o router.

Mantén as dúas regras explícitas en lugar de tentar escribir unha que cubra ambas as cadeas. As regras separadas son máis fáciles de ler, e permítenche desactivar a ruta do router sen molestar o tráfico dos clientes mentres depuras. Tamén fan que os contadores teñan sentido dun en un.

Mantén o transporte propio do túnel fóra da regra

A conexión exterior do túnel tamén a crea o router. Unha regra que envíe todo o tráfico xerado localmente ao túnel enrutará o túnel a través de si mesmo, e non levantará en absoluto.

O acceso de xestión é a segunda vítima. As sesións administrativas orixinadas no router, ou as respostas a elas, poden ser arrastradas ao túnel por unha regra local demasiado ampla e volverse inaccesibles desde a LAN.

Exclúe o extremo do túnel da coincidencia e mantén a regra limitada aos enderezos de resolutor. Iso abonda para o requisito de DNS e é o bastante pequeno para razoar sobre iso.

Proba ambas as poboacións, non unha

Observa o router facer a súa propia consulta e anota que interface a levou. Repite a consulta desde un host da LAN e anota a ruta que tomou. Os contadores das regras de política fan visibles ambas as respostas sen adiviñar.

Trata os resultados como dous achados. Un cliente que resolve a través do túnel non di nada sobre o router, e un router que resolve correctamente non di nada sobre un cliente noutro escoitador. Escríbeos como liñas separadas no rexistro de cambios.

Comproba tamén o porto: unha regra que coincide co porto de destino 53 perde un resolutor alcanzado por DNS over TLS no 853 ou por un extremo HTTPS. Fai coincidir o transporte que o upstream configurado usa realmente, e a fuga péchase polo motivo correcto.