Roteamento por políticas no OpenWrt: a cadeia que apanha o DNS local

Os clientes da LAN resolvem pelo túnel e as consultas do próprio router, em silêncio, não o fazem. Atualizações de pacotes, sincronização de hora e DNS dinâmico saem todos pelo uplink comum, enquanto cada consulta encaminhada apanha a VPN, e nada na interface sugere que existam dois caminhos diferentes. A explicação não é um bug na política mas uma questão de que gancho vê o pacote. Dois fluxos, um endereço de resolvedor, e só um deles atravessa o router. Separá-los é toda a correção.

Dois fluxos, um endereço de resolvedor

O primeiro fluxo é o que as pessoas imaginam. Um cliente pergunta ao resolvedor do router, o resolvedor encaminha para cima, e esse pacote encaminhado passa pelo router ao sair. Esse pacote é visível para tudo o que observa o tráfego encaminhado.

O segundo fluxo nunca chega de lugar nenhum. O router cria-o, por isso não existe pacote de entrada nem passo de encaminhamento a corresponder.

Ambos podem visar o mesmo endereço de resolvedor, e é exatamente por isso que a diferença passa facilmente despercebida. Mesmo destino, origem diferente, cadeia diferente. Assim que você vê a origem, o resto do diagnóstico segue.

Os pacotes encaminhados e os gerados localmente entram de forma diferente

O tráfego encaminhado é avaliado quando chega de outra interface. Os pacotes de roteamento por políticas expõem-no como uma cadeia prerouting, e uma regra colocada ali vê cada pacote que atravessa o router. É por isso que as consultas dos clientes se comportam exatamente como a política descreve, e é por isso que o router a ignora. A regra não está errada, está apenas ligada a um gancho que o router nunca alcança. Mova-a, e a mesma correspondência começa a funcionar.

O tráfego gerado localmente é criado por um processo no router e entra no caminho de saída. É roteado pela decisão do próprio router e só encontra a política se a política cobrir essa cadeia. Não há interface de entrada a corresponder nem decisão de encaminhamento a observar.

É uma propriedade de onde os pacotes nascem, não de um pacote em particular. Uma regra escrita para uma cadeia simplesmente não tem opinião sobre a outra. Nenhum ajuste de regras muda isso.

Escolha a cadeia de saída e depois estreite a correspondência

A correção é ligar a mesma intenção também à cadeia de saída, ou mover a regra para lá quando são as consultas do próprio router que lhe importam. Numa instalação de OpenWrt baseada num pacote de roteamento por políticas, isso significa escolher output em vez de prerouting na definição de cadeia da regra. Mantenha as duas regras se ambas as populações precisarem de cobertura.

Depois estreite aquilo a que a regra corresponde. Endereços de resolvedor de destino na porta que o resolvedor realmente usa são uma decisão muito menor do que enviar para o túnel tudo o que o router origina.

Mantenha as duas regras explícitas em vez de tentar escrever uma que cubra as duas cadeias. Regras separadas são mais fáceis de ler, e permitem desativar o caminho do router sem perturbar o tráfego dos clientes enquanto depura. Também tornam os contadores significativos um de cada vez.

Mantenha o transporte do próprio túnel fora da regra

A ligação externa do túnel também é criada pelo router. Uma regra que envie todo o tráfego gerado localmente para o túnel irá rotear o túnel através de si mesma, e ele não vai subir de todo.

O acesso de gestão é a segunda vítima. As sessões administrativas originadas no router, ou as respostas a elas, podem ser arrastadas para o túnel por uma regra local demasiado ampla e tornar-se inacessíveis a partir da LAN.

Exclua o ponto final do túnel da correspondência e mantenha a regra limitada aos endereços do resolvedor. Isso basta para o requisito de DNS e é pequeno o suficiente para se raciocinar sobre ele.

Teste as duas populações, não uma

Observe o router a fazer a sua própria consulta e anote qual interface a transportou. Repita a consulta a partir de um anfitrião da LAN e anote o caminho que essa tomou. Os contadores das regras de política tornam ambas as respostas visíveis sem adivinhar.

Trate os resultados como duas descobertas. Um cliente que resolve pelo túnel não diz nada sobre o router, e um router que resolve corretamente não diz nada sobre um cliente noutro ouvinte. Escreva-os como linhas separadas no registo de alterações.

Verifique também a porta: uma regra que corresponde à porta de destino 53 falha um resolvedor alcançado por DNS over TLS na 853 ou por um ponto final HTTPS. Faça corresponder o transporte que o upstream configurado realmente usa, e a fuga fecha pelo motivo certo.