O DNS non resolve cando o kill switch da VPN bloquea o porto 53
Un kill switch pode bloquear o DNS a propósito. Compare a resolución só dentro do túnel cunha excepción para un resolvedor local e despois determine que capa fallou realmente.
Cando o kill switch deixa caer o túnel, leva consigo a ruta do DNS, e o resolvedor que queda atrás rara vez é o que vostede espera. Dous deseños afrontan ese momento de forma moi distinta: bloquear todos os paquetes DNS que non vaian dentro do túnel, oudeixar un resolvedor en pé como excepción. Ambos son defendibles. Desde unha lapela do navegador os síntomas parecen case idénticos, así que a primeira tarefa é descubrir que deseño despregou realmente.
Manteño esa distinción diante porque a corrección é oposta en cada caso. Un deseño necesita unha excepción máis ampla; o outro, unha máis estreita. Adiviñar cóstalle ou a privacidade ou unha tarde.
Dous deseños de DNS para a mesma caída
O deseño A trata o resolvedor como un servizo máis detrás do túnel. As regras do cortafuegos permiten UDP e TCP 53 só na interface do túnel, e o enderezo que recibe o cliente é un resolvedor dentro do túnel. Cando o túnel cae, as consultas detéñense, e ese é o resultado previsto, non unha avaría.
O deseño B mantén un resolvedor accesible na rede local, normalmente o router en 192.168.1.1 ou o stub do sistema operativo en 127.0.0.53, co razoamento de que a resolución de nomes non debería morrer co túnel. Resulta cómodo nunha LAN doméstica onde o router resolve para toda a casa. No Wi-Fi dun hotel ou aeroporto a mesma excepción apunta ao servidor doutra persoa, e cada nome que escriba queda ao descuberto aínda que o seu tráfico web siga bloqueado.
A fronteira é quen posúe o resolvedor. Se confía no local, unha excepción é un burato pequeno e honesto. Se non, o deseño só-túnel é o único que aguanta, e o prezo é que un túnel caído leva todos os nomes.
Por que a consulta do propio cliente VPN segue funcionando
O cliente ten que resolver o nome de host da pasarela antes de que exista un túnel, así que un bloqueo estrito non debe cubrir a ruta de arranque do cliente. A maioría dos clientes ou ben cachean o enderezo do extremo ou ben inclúen unha excepción de arranque documentada para ese único host. Se o seu conxunto de regras bloquea esa consulta, o túnel non volve nunca e os rexistros mostran un cliente que non pode alcanzar o seu propio servidor, o que é un defecto de política e non de DNS.
O DNS dividido é o outro lugar onde isto aparece. O cliente empuxa unha zona interna a un resolvedor privado e deixa todo o demais ao resolvedor do sistema. Tras unha caída, os nomes públicos poden seguir resolvéndose mentres os internos esgotan o tempo, porque a zona privada xa non ten ruta. Para o usuario iso é "a VPN rompeu internet"; para o rexistro do resolvedor é unha consulta que nunca chegou.
Con systemd-resolved pode ver a división directamente.resolvectl statusenumera os servidores DNS por ligazón e os dominios de encamiñamento, e tras caer o túnel o dominio interno segue apuntando a un servidor nunha ligazón que xa non existe. O stub en 127.0.0.53 acepta aínda a consulta, despois espera un servidor superior que non responderá, e por iso o fallo tarda segundos en vez de volver de inmediato.
O DNS cifrado non esquiva un filtro de paquetes
DNS sobre HTTPS e DNS sobre TLS viaxan por 443 e 853, así que unha regra que bloquea o porto 53 non dixo nada sobre eles. Bloquear "DNS" por porto é unha política sobre un porto, non sobre a resolución de nomes. Se o seu kill switch bloquea todo o tráfico fóra do túnel, DoH queda cuberto por accidente. Se reservou un permiso para un portal cativo ou un resolvedor público, non.
Os controis do lado do cliente son a panca máis barata. Firefox abandona o seu resolvedor DoH cando o nome canariouse-application-dns.netnon resolve, e por iso as redes xestionadas publican ese dominio como NXDOMAIN; a política empresarial tamén pode fixalo desactivado. Android Private DNS e o DNS seguro de Chrome teñen os seus propios interruptores e os seus propios valores por defecto. Desactivalos é máis fiable que perseguir enderezos de resolvedores, porque a lista de enderezos cambia e o seu conxunto de regras non.
Hai unha versión disto que non vai de fugas en absoluto. Unha aplicación cun resolvedor fixado segue necesitando unha ruta de rede para alcanzalo. O cifrado cambia quen pode ler a consulta, non se o paquete pode saír da máquina, así que un bloqueo de todo o dispositivo derrota o axuste sen tocalo.
Emparexe o síntoma coa capa
A maioría dos informes chegan como unha frase, e esa frase normalmente xa nomea a capa. A táboa de abaixo é o que repaso antes de tocar unha regra; o obxectivo é decidir se a consulta se bloqueou, se dirixiu mal ou nunca se enviou.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
As dúas primeiras filas son as que a xente diagnostica mal. Unha caída silenciosa e un rexeitamento parecen ambos "o DNS está roto" nun navegador, pero só un dos dous significa que o seu kill switch está facendo o seu traballo. Un rexeitamento significa que algo respondeu, así que o bloqueo non está onde vostede cre.
Restaura a política do resolvedor e despois demóstraa
Arranxe o deseño, non o síntoma. Para resolución só por túnel, permita 53 na interface do túnel, empuxe o resolvedor interno coa configuración do túnel e deixe a ligazón física sen ningún permiso de DNS. Con wg-quick, a liñaDNS =é a que escribe o resolvedor na configuración da interface, así que un túnel que a omite deixa o resolvedor antigo no seu sitio e cada consulta pola ruta equivocada.O manual de wg-quickdocumenta ese comportamento por plataforma.
Despois verifique nesta orde. En Linux,resolvectl statusmostra a ligazón activa,dig +short example.comproba un nome público,dig @10.8.0.1 internal.example.comproba o privado, esudo tcpdump -ni any port 53mostra que interface usan os paquetes mentres executa ambos. En Windows,Get-DnsClientServerAddress -AddressFamily IPv4eResolve-DnsName example.comdan os mesmos dous feitos: quen está configurado e quen responde.
Remate coa proba negativa. Desconecte o túnel, confirme que un nome público novo falla, confirme que o nome privado falla, econfirme que ningún paquete do porto 53 saíu do adaptador físico. Un bloqueo que só aguanta para respostas en caché non aguanta en absoluto.
Lista de comprobación antes de pechar o tícket:
- O resolvedor usado durante a caída é o que a política pretende.
- A consulta do propio extremo do cliente segue permitida, por caché ou por excepción.
- DoH e DoT quedan cubertos polo bloqueo ou desactivados por política.
- As zonas privadas fallan pechadas, non abertas, unha vez que o túnel desaparece.