Permitir DNS só a través do teu resolutor VPN: un percorrido paso a paso

Segue unha soa consulta de nome desde o momento en que a escribes. O navegador pregunta ao sistema operativo, o sistema operativo pregunta ao resolutor que escolle a súa política, e a consulta sae do dispositivo por algunha interface con algún transporte. O teu deseño de VPN di que a resposta debe vir dun resolutor concreto por unha ruta concreta. A fenda entre esas dúas afirmacións é o que configuras e despois impós.

Paso 1: nomea o resolutor e a ruta

Anota tres cousas antes de tocar unha devasa: o enderezo do resolutor, o protocolo e o porto que esperas, e a interface pola que debe saír a consulta. Sen esa lista, unha regra é unha conxectura sobre o tráfico e non a execución dunha decisión. Unha VPN pode transportar datos de aplicacións mentres o DNS segue un arranxo aparte, e iso non é un erro en si mesmo. É o que ocorre cando ninguén lle dixo outra cousa ao cliente.

Nomear a ruta de forma explícita é a diferenza entre un deseño e un accidente. Tamén che dá algo que probar despois, porque cada observación se pode comparar cunha expectativa escrita. Garda esa lista no tícket de cambio e non na cabeza de ninguén.

Paso 2: pon a política onde de verdade vive

A escolla do resolutor pertence ao cliente: a configuración de rede do sistema operativo, os axustes propios do cliente VPN ou unha política de navegador xestionada. Poncha primeiro alí, co mecanismo que admite a plataforma, porque unha devasa non pode obrigar un cliente a escoller un resolutor que nunca lle mencionaron. Nun cliente con túnel dividido, di explicitamente que dominios van ao resolutor interno. Nun parque xestionado, a política do navegador adoita ser a única panca para DoH, porque o navegador pode escoller o seu propio resolutor cifrado con independencia do axuste do sistema.

Se o saltas e vas directo á devasa, obtés unha regra que permite o resolutor correcto xunto cun cliente que nunca o usa. A regra parece correcta e os rexistros do resolutor quedan baleiros, unha parella desconcertante de depurar. Configura primeiro a escolla e despois impona.

Paso 3: impón a ruta de forma estreita

Agora engade o permiso de rede para a ruta permitida: o enderezo do resolutor, o protocolo e o porto, e a interface pola que debe saír. Mantén a regra limitada a ese resolutor en lugar de permitir todo o DNS saínte. As tres rutas de abaixo son as que pode tomar un cliente moderno, e só a primeira queda cuberta por unha regra do porto 53.

Bloquear DoH e DoT é lexítimo; supor que unha regra do porto 53 xa os bloqueou non o é. Un navegador con DoH resolve nomes por unha ruta que a túa regra nunca describiu, e unha aplicación que trae o seu propio resolutor fai o mesmo. Escribe cada ruta que pretendes permitir e cada unha que pretendes rexeitar. Unha regra que non nomea unha ruta non decidiu nada sobre ela.

Paso 4: segue os nomes privados e públicos

O DNS dividido envía a propósito só espazos de nomes privados a un resolutor interno mentres os nomes públicos van a outro sitio, así que máis dun resolutor no deseño non é unha fuga. A fuga é unha consulta que debía ir ao teu resolutor e chega a outro lugar, ou unha ruta prevista inalcanzable que fai que o cliente volva atrás en silencio. Eses dous casos son os que hai que buscar. Segue un nome interno e un nome público baixo a política prevista e anota que resolutor respondeu a cada un.

Un sitio de proba que informa do teu resolutor é unha pista, non unha proba, porque só ve as consultas que lle chegaron. Captura a consulta no lado do cliente cando necesites saber que ruta tomou de verdade, e compara ambas as observacións. Cando non coinciden, atopaches un retroceso que ninguén documentou.

Se o enderezo do resolutor é correcto pero non é accesible, o problema está no encamiñamento ou na filtraxe e non na política. Segue a consulta ata ese enderezo e confirma que a resposta volve pola interface esperada antes de cambiar calquera axuste do resolutor.

Paso 5: mantén unha vía de volta

Antes de endurecer o acceso DNS na pasarela, confirma un método de recuperación que non dependa da resolución de nomes. Un resolutor roto fai máis difícil chegar a calquera ferramenta de reparación, incluídas as que usarías para desfacer o cambio. Mantén unha consola local ou unha vía fóra de banda aberta ata que a nova política estea probada. Quítaa só cando a política sobrevivise a unha reconexión.

Tras unha reconexión ou unha actualización da política do navegador, inspecciona de novo o estado efectivo, porque ambos poden cambiar o resolutor sen cambiar a túa regra. O requisito é un destinatario coñecido e unha ruta protexida para as consultas, non unha etiqueta de resolutor tranquilizadora nunha captura de pantalla. A especificación RFC 8484 de DNS over HTTPS é a referencia para a ruta cifrada que a túa regra de porto non ve.