¿Fallan los nombres privados de la VPN? La protección rebind de DNS es la sospechosa

En la LAN de la oficina el nombre interno responde al instante. En el momento en que la VPN está activa deja de funcionar, la aplicación informa de un tiempo de espera agotado y el túnel sigue pasando tráfico sin quejarse. Lo que cambió es el resolutor, y ese resolutor tiene una opinión sobre las direcciones privadas.

La protección rebind existe para detener un truco concreto. Un nombre privado publicado a propósito se parece lo suficiente y la defensa se dispara.

Lee la respuesta antes de leer la política

Consulta el nombre en el resolutor que la VPN realmente entrega, no en el que tu portátil usa en casa. Compara la respuesta con el registro que esperas y anota si la respuesta está vacía, rechazada o llena de direcciones públicas que nadie había previsto.

Los síntomas se solapan, así que la forma de la respuesta decide el diagnóstico. Un NXDOMAIN es un registro que falta, un REFUSED es una regla de acceso, una dirección pública para un nombre interno es un error de política o de DNS dividido, y una dirección privada correcta que el cliente no puede usar es un problema completamente distinto. Una conexión rechazada o una petición atascada no demuestran nada por sí solas, por eso el primer comando en cualquiera de estos tickets debería ser una consulta y no un reinicio. Anota la respuesta antes de cambiar nada.

Qué detiene realmente la defensa

El rebinding de DNS funciona cambiando a qué resuelve un nombre después de que el cliente ya haya confiado en él. Una página se carga desde un nombre controlado por el atacante, la respuesta cambia a una dirección privada y el navegador es engañado para hablar con algo de la red local con lo que nunca habría aceptado una conexión directa. La defensa consiste en rechazar las respuestas que apuntan al espacio privado cuando nunca se pidió al resolutor que sirviera un espacio de nombres privado. Esa asimetría es todo el ataque.

dnsmasq documenta exactamente ese comportamiento, junto con excepciones por dominio. Su página de manual describe rebind-domain-ok como la forma de nombrar dominios que pueden devolver legítimamente tales direcciones. Léelo como una señal de que el arreglo previsto es un permiso acotado, no un interruptor global.

Acota la excepción al espacio de nombres

Arregla primero el espacio de nombres y después la excepción. Confirma que el nombre que falla pertenece a un dominio que la organización controla y que el registro se mantiene a propósito. Una dirección inesperada que solo se parece a un rango familiar de la LAN merece sospecha y no una excepción, así que comprueba quién es el dueño de la zona antes de escribir cualquier permiso.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

Después añade el permiso más estrecho que cubra los nombres previstos: un dominio, o un subdominio delegado, en la configuración del resolutor que consultan los clientes de la VPN. Desactivar la protección para todos los nombres de ese resolutor elimina la defensa para todos a la vez, incluidos los nombres que nunca la necesitaron.

El DNS dividido pertenece a la misma decisión. Si el espacio de nombres privado solo debe responderse en el resolutor interno, publícalo allí y deja de filtrarlo a resolutores públicos, para que la excepción cubra un camino en lugar de todos los caminos.

Vuelve a probar el recurso y la defensa

Consulta de nuevo, luego conéctate al servicio y mira qué ve el cliente. Una respuesta privada correcta con una sesión que funciona significa que la excepción ha entrado. Una respuesta correcta con una sesión atascada significa que la ruta o la identidad del servicio es el siguiente sospechoso.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

Prueba también un nombre público a través del mismo resolutor. La protección debería seguir funcionando para los nombres fuera de la excepción, y si esa comprobación falla, el cambio fue más amplio de lo previsto. Mantén la validación del certificado intacta en todo momento, porque un nombre que resuelve correctamente todavía tiene que coincidir con el certificado que presenta el servicio.

Anota en el ticket la respuesta rechazada, el dominio, el resolutor y quién es el dueño de la política. Ese registro es lo que convierte una interrupción interna misteriosa en un cambio de configuración que alguien puede revisar.