Por que o DNS propio do router evita o túnel VPN?

As consultas dos clientes seguen o túnel, mentres que as consultas propias do router saen pola WAN, e a regra de devasas que goberna unha non ten ningún efecto sobre a outra. A razón non é un fallo: unha petición reenviada e unha petición que xera o router son dous fluxos separados, e cada un compárase cunha parte distinta da configuración. Capturar só a metade do cliente produce unha resposta segura sobre un camiño que a segunda metade nunca usa. A reparación consiste en apuntar deliberadamente o resolutor do router e despois probar os dous camiños por separado.

A que fluxo pertence realmente a captura de paquetes

Unha consulta implica dous intercambios. Un cliente da LAN envía unha consulta ao resolutor do router, e esta chega como tráfico reenviado na interface LAN, así que unha ruta de política ou unha regra NAT escrita para paquetes reenviados pode facela coincidir. Despois o router responde da caché ou, se non hai entrada, abre a súa propia consulta a un servidor ascendente.

Esa segunda consulta ten o router como orixe e como destino propio, e a plataforma escolle o seu camiño nun bloque de configuración distinto. Ambos intercambios levan o mesmo nome, e ningún é unha copia do outro. Por iso unha captura tomada no lado da LAN demostra onde foi o paquete do cliente e non di nada sobre o paquete saínte.

A comprobación práctica é observar os dous lados á vez. No router, lista o socket do resolutor, consúltao localmente e captura a interface WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Se a lista de sockets mostra un oínte ligado ao enderezo de loopback ou da LAN, o router responde localmente en vez de reenviar a outro host. A captura mostra entón se a consulta ascendente resultante sae pola interface do túnel ou pola WAN, que é a resposta que a regra de ruta de política nunca daría.

Por que a ruta de política nunca ve a segunda consulta

As regras de devasas escríbense para unha interface, unha orixe, un destino e un porto, e avalíanse para os paquetes que pasan polo equipo. Unha consulta que orixina o router non pasa por nada, porque un proceso local entrégaa directamente á táboa de encamiñamento. Encamiñamento por política e NAT por tanto, só se aplican ao camiño reenviado, e por iso un conxunto de regras pode parecer completo e aínda así deixar o DNS do router fóra do túnel.

A distinción sobrevive a cada reescritura do firmware porque deriva do camiño do paquete e non dunha función. Todo o que o equipo xera para si mesmo, xa sexan consultas do resolutor, sincronización da hora, comprobacións de actualizacións ou acceso a espellos de paquetes, é de orixe local e cae no mesmo punto cego. É tamén por iso que unha proba feita desde un portátil non demostra nada sobre o router.

Onde decide o resolutor de pfSense o seu propio camiño ascendente

pfSense fai visible a separación. O tráfico dos clientes pódese encamiñar por política a través dunha pasarela VPN mentres o tráfico propio das devasas segue o axuste de saída do resolutor en vez das regras da LAN. Na interface web ese axuste atópase en Services > DNS Resolver > Outgoing Network Interfaces, e o seu valor é a lista de interfaces que o resolutor pode usar para consultas ascendentes.

Nomear alí a interface do túnel, e só esa interface, é o que fai que as consultas propias do router sigan o túnel. Se se deixa por defecto, o resolutor escolle unha saída da táboa de encamiñamento, que nun host con dobre WAN ou VPN adoita ser a WAN.

Outros firmwares expoñen a mesma decisión cunha etiqueta distinta: unha lista de servidores ascendentes ligada a un enderezo de orixe, un modo de só reenvío ou unha política de rutas documentada. O axuste que hai que buscar é sempre o que escolle unha saída ou unha orixe para as consultas xeradas localmente. A referencia de configuración do resolutor documenta esa opción para pfSense e merece lerse antes do cambio.

Escolle o comportamento ante fallos antes do axuste

Cando o túnel cae, dous comportamentos son defendibles: deter as consultas ascendentes para que nada se escape, ou recorrer a un resolutor aprobado por un camiño coñecido. Ambos son políticas, e ningún é o que se obtén por defecto. Decide cal necesita a rede antes de tocar a lista de interfaces.

O peche ante fallos é máis fácil de defender, pero converte unha caída do túnel nunha caída de resolución de nomes para cada dispositivo detrás do router. A alternativa mantén a oficina utilizábel, a costa dun intercambio ascendente fóra do túnel que debe ser aceptábel a propósito e non por accidente. Escribe a escolla, porque a próxima persoa que vexa un enderezo de resolutor fóra da VPN lerá iso como unha fuga a menos que unha nota diga o contrario. Esa nota é o que separa unha alternativa documentada dun achado sen explicación na revisión do próximo trimestre.

Dous casos complican a decisión. Os nomes privados poden necesitar un resolutor interno que o túnel poida alcanzar, e un navegador ou unha aplicación co seu propio DNS cifrado pode evitar o router por completo, así que o resolutor que configurou non é sempre o que usa unha aplicación concreta.

Proba ambos camiños e mantén os resultados separados

Unha proba de DNS no navegador responde a unha pregunta estreita: que resolutores usou ese navegador, nas condicións desa proba. Non inventaría os dispositivos da rede e non pode ver unha consulta que o router xerase para si mesmo. Trata a súa saída como un dato e non como unha auditoría.

Desde un cliente da LAN, pide ao router un nome público e despois un privado que só debería responder a túa zona interna. Un fallo só na segunda consulta apunta ao reenvío de nomes e non ao túnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Despois baixa o túnel e repite ambas consultas. As respostas rexeitadas significan que o resolutor se pecha ante fallos; unha resposta correcta apunta a un resolutor alternativo e ao camiño que usou. Compara iso coa nota que escribiu e cunha captura na interface WAN tomada no mesmo minuto.

Mantén as observacións separadas no rexistro: o intercambio do cliente co router, o intercambio do router co ascendente e a configuración que decidiu o segundo. Un cambio de encamiñamento posterior exercitará ese segundo intercambio sen aviso. Unha resposta que chega dun lugar distinto do punto final da VPN non é unha fuga por si mesma; convértese en fuga só cando a configuración escolleu ese camiño por accidente.