Filtro DNS da VPN: bloquear nomes non bloquea anuncios
Unha regra de dnsmasq responde aos nomes con NXDOMAIN; nunca le a páxina. Compare iso co que fai un bloqueador do lado do cliente antes de prometer eliminar anuncios.
Unha soa liña de dnsmasq pode responder un nome con NXDOMAIN, e ese é todo o mecanismo. Nunca le HTML, nunca inspecciona a ruta dunha petición e nunca ve que fai unha aplicación cunha conexión que xa abriu. Por iso comparalo cunha extensión do navegador é comparar dúas tarefas distintas. Unha decide se un nome se resolve; a outra decide que ocorre despois.
Que controla realmente un filtro de nomes
A opción address=/metrics.example/, sen nada despois da última barra, fai que o resolutor devolva NXDOMAIN para ese nome e os seus subdominios. Deixar o enderezo baleiro é a parte importante: evita enviar clientes a un servidor de substitución sen relación ou facer pasar un enderezo de bucle local polo destino real. O manual de dnsmasq describe esa forma como unha resposta negativa e non como unha redirección.
Todo o que a regra pode facer deriva desa única decisión. Un cliente que pregunta a este resolutor obtén unha resposta negativa; un cliente que pregunta a outro resolutor obtén o que diga ese resolutor. O filtro non sabe nada da ruta, a cadea de consulta nin a conta que tería usado a aplicación.
Ese detalle importa porque un nome de host adoita servir para varios fins. Os puntos de inicio de sesión, as imaxes e o seguimento poden compartir un dominio, e unha regra que elimina todo o nome pode eliminar tamén un fluxo de traballo. Unha política a nivel de nome ten que aceptar ese intercambio ou escoller nomes máis estreitos.
En que se diferencia un bloqueador do lado do cliente
Unha extensión do navegador ve a petición antes de que saia, así que pode facer coincidir unha ruta de URL, cancelar unha petición concreta e agochar o elemento que tería mostrado o resultado. Pode permitir example.com/article mentres rexeita example.com/ads/, algo que ningunha resposta DNS pode expresar. Esa visión a nivel de ruta é a capacidade que un resolutor simplemente non ten. Tamén é a razón de que unha lista de filtros creada para unha ferramenta raramente se comporte igual na outra.
O custo é o alcance. Esa protección vive dentro dun navegador, nun perfil, nun dispositivo, e desaparece cando o usuario pasa a outra aplicación. Un filtro DNS configurado na pasarela cobre todos os dispositivos que usan o resolutor da pasarela, incluídos os dispositivos onde non se pode instalar ningunha extensión.
Ningunha das dúas disposicións está completa por si soa. Un filtro DNS non pode eliminar un identificador que unha páxina xa enviou, e unha extensión do navegador non pode protexer unha aplicación que nunca a carga.
A ruta do resolutor decide se algo disto se aplica
Unha VPN pode anunciar un servidor DNS e aínda así non recibir todas as consultas. Un navegador con DNS cifrado configurado, unha aplicación co seu propio resolutor ou un dispositivo nunha ruta de rede que exclúe a pasarela mirarán todos a outro sitio. As plataformas móbiles ofrecen cada vez máis un axuste de DNS privado que substitúe en silencio o que suxire o túnel.
Así que probe a ruta e non a política. Consulte o resolutor previsto directamente desde a pasarela, logo consúlteo desde un cliente e compare, e despois observe se un nome que debería estar bloqueado falla de verdade na aplicación que executa o usuario.
As respostas na caché e os sockets abertos volven ruidoso isto. Unha páxina que xa cargou os seus recursos seguirá funcionando despois de cambiar a regra, así que unha conexión nova é mellor proba que recargar unha pestana vella.
Probe as dúas direccións antes de afirmar un resultado
Use un nome de documentación bloqueado a propósito, un nome público permitido e un nome privado que o servizo necesita:
$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53
Unha resposta baleira para o nome bloqueado, un enderezo normal para o público e un enderezo privado para o interno mostran en conxunto que o filtrado, a resolución augas arriba e os rexistros locais funcionan. Se fallan os tres, está ante un problema augas arriba ou do receptor, non dun filtro.
Manteña a afirmación estreita en todo o que publique internamente. Isto é filtrado de dominios nun resolutor, non inspección de contido, non filtrado de rutas e non unha promesa de que ninguén é rastrexado. Indique o propietario da política, a ruta de excepción e o período de retención de consultas xunto ás regras, porque un filtro que rexistra cada busca ten o seu propio custo de privacidade.