Per què el DNS propi del router evita el túnel VPN?

Les consultes dels clients segueixen el túnel, mentre que les consultes pròpies del router surten per la WAN, i la regla de tallafoc que governa una no té cap efecte sobre l'altra. El motiu no és un error: una petició reenviada i una petició que genera el router són dos fluxos separats, i cadascun es compara amb una part diferent de la configuració. Capturar només la meitat del client produeix una resposta confiada sobre un camí que la segona meitat no fa servir mai. La reparació consisteix a apuntar deliberadament el resolutor del router i després provar els dos camins per separat.

A quin flux pertany realment la captura de paquets

Una consulta implica dos intercanvis. Un client de la LAN envia una consulta al resolutor del router, i aquesta arriba com a trànsit reenviat a la interfície LAN, de manera que una ruta de política o una regla NAT escrita per a paquets reenviats la pot fer coincidir. Després el router respon de la memòria cau o, si no hi ha entrada, obre la seva pròpia consulta a un servidor ascendent.

Aquesta segona consulta té el router com a origen i com a destinació pròpia, i la plataforma tria el seu camí en un bloc de configuració diferent. Tots dos intercanvis porten el mateix nom, i cap no és una còpia de l'altre. Per tant, una captura feta al costat de la LAN demostra on va anar el paquet del client i no diu res sobre el paquet sortint.

La comprovació pràctica és observar tots dos costats alhora. Al router, llista el sòcol del resolutor, consulta'l localment i captura la interfície WAN:

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

Si la llista de sòcols mostra un oient lligat a l'adreça de loopback o de la LAN, el router respon localment en lloc de reenviar a un altre amfitrió. Aleshores la captura mostra si la consulta ascendent resultant surt per la interfície del túnel o per la WAN, que és la resposta que la regla de ruta de política mai no hauria donat.

Per què la ruta de política no veu mai la segona consulta

Les regles de tallafoc s'escriuen per a una interfície, un origen, una destinació i un port, i s'avaluen per als paquets que passen per l'equip. Una consulta que origina el router no passa per res, perquè un procés local la lliura directament a la taula d'encaminament. Encaminament per política i NAT per tant, només s'apliquen al camí reenviat, i per això un conjunt de regles pot semblar complet i tot i així deixar el DNS del router fora del túnel.

La distinció sobreviu a cada reescriptura del microprogramari perquè deriva del camí del paquet i no d'una funció. Tot el que l'equip genera per a si mateix, siguin consultes del resolutor, sincronització de l'hora, comprovacions d'actualitzacions o accés a miralls de paquets, és d'origen local i cau al mateix punt cec. És també per això que una prova feta des d'un portàtil no demostra res sobre el router.

On el resolutor de pfSense decideix el seu propi camí ascendent

pfSense fa visible la separació. El trànsit dels clients es pot encaminar per política a través d'una passarel·la VPN mentre el trànsit propi del tallafoc segueix el paràmetre de sortida del resolutor en lloc de les regles de la LAN. A la interfície web aquest paràmetre es troba a Services > DNS Resolver > Outgoing Network Interfaces, i el seu valor és la llista d'interfícies que el resolutor pot fer servir per a consultes ascendents.

Anomenar-hi la interfície del túnel, i només aquella interfície, és el que fa que les consultes pròpies del router segueixin el túnel. Si es deixa per defecte, el resolutor tria una sortida de la taula d'encaminament, que en un amfitrió amb doble WAN o VPN sovint és la WAN.

Altres microprogramaris exposen la mateixa decisió amb una etiqueta diferent: una llista de servidors ascendents lligada a una adreça d'origen, un mode només de reenviament o una política d'encaminament documentada. El paràmetre que cal buscar sempre és el que tria una sortida o un origen per a les consultes generades localment. La referència de configuració del resolutor documenta aquesta opció per a pfSense i val la pena llegir-la abans del canvi.

Tria el comportament de fallada abans del paràmetre

Quan el túnel cau, dos comportaments són defensables: aturar les consultes ascendents perquè no s'escoli res, o passar a un resolutor aprovat per un camí conegut. Tots dos són polítiques, i cap no és el que s'obté per defecte. Decideix quin necessita la xarxa abans de tocar la llista d'interfícies.

El tancament en fallada és més fàcil de defensar, però converteix una caiguda del túnel en una caiguda de resolució de noms per a cada dispositiu darrere del router. El retrocés manté l'oficina utilitzable, a costa d'un intercanvi ascendent fora del túnel que ha de ser acceptable a propòsit i no per accident. Escriu la decisió, perquè la propera persona que vegi una adreça de resolutor fora de la VPN ho llegirà com una fuita tret que una nota digui el contrari. Aquesta nota és el que separa un retrocés documentat d'una troballa inexplicada en la revisió del proper trimestre.

Dos casos compliquen la decisió. Els noms privats poden necessitar un resolutor intern que el túnel pugui assolir, i un navegador o una aplicació amb el seu propi DNS xifrat pot evitar del tot el router, de manera que el resolutor que has configurat no és sempre el que fa servir una aplicació concreta.

Prova els dos camins i mantén els resultats separats

Una prova de DNS al navegador respon una pregunta estreta: quins resolutors va fer servir aquell navegador, en les condicions d'aquella prova. No inventaria els dispositius de la xarxa ni pot veure una consulta que el router hagi generat per a si mateix. Tracta la seva sortida com una dada més i no com una auditoria.

Des d'un client de la LAN, demana al router un nom públic i després un de privat que només hauria de respondre la teva zona interna. Un fallo només en la segona consulta apunta a un reenviament de noms i no al túnel:

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

Després abaixa el túnel i repeteix les dues consultes. Les respostes refusades volen dir que el resolutor es tanca en fallada; una resposta correcta apunta a un resolutor de retrocés i al camí que ha fet servir. Compara-ho amb la nota que vas escriure i amb una captura a la interfície WAN feta en el mateix minut.

Mantén les observacions separades al registre: l'intercanvi del client amb el router, l'intercanvi del router amb l'ascendent i la configuració que va decidir el segon. Un canvi d'encaminament posterior exercitarà aquest segon intercanvi sense avís. Una resposta que arriba d'un lloc que no és el punt final de la VPN no és una fuita per si mateixa; es converteix en fuita només quan la configuració va triar aquell camí per accident.