mDNS dentro de una VPN: por qué no se resuelven los nombres .local

La impresora de la oficina aparece en todas las aplicaciones de su escritorio y desaparece en la VPN, aunque puede hacer ping a la dirección que sabe que tiene. Nada en el túnel está roto: el descubrimiento y la accesibilidad son servicios separados, y solo uno de ellos cruza un túnel enrutado de forma predeterminada. Las comprobaciones siguientes los separan antes de que empiece a añadir rutas. Una ruta no puede arreglar una consulta que nunca salió del enlace.

Compruebe qué se resuelve hoy y qué solo parece resuelto

Separe primero las dos preguntas: una consulta unicast para un nombre de host pregunta a un resolutor, mientras que una búsqueda de _ipp._tcp pregunta al enlace local. En Linux, avahi-browse -a muestra lo que puede ver el DNS multicast, y resolvectl query name.local muestra lo que hace la pila de resolutores con ese nombre. En macOS, dns-sd -B _ipp._tcp enumera los servicios descubiertos sin necesidad de una dirección previa.

Si la dirección responde y el nombre no, el enrutamiento funciona y el descubrimiento no. Un nombre .local también puede responderse en el propio host mediante nss-mdns sin tener avahi-browse instalado, así que un getent o un ping correcto a ese nombre no es prueba de que el descubrimiento haya cruzado el túnel; el resultado de la búsqueda y el del resolutor son pruebas distintas. Las aplicaciones almacenan en caché lo que descubrieron, y por eso el fallo suele aparecer horas después de conectarse y no al conectarse. Cierre y vuelva a abrir la aplicación, y compruebe si la entrada en caché contiene un nombre o una dirección, porque una dirección sigue funcionando mucho después de que el descubrimiento se haya detenido.

Por qué la consulta nunca cruza el túnel

El DNS multicast envía consultas a 224.0.0.251, dentro del bloque de control de la red local, en el puerto UDP 5353. Los enrutadores no reenvían direcciones de ese bloque, así que la consulta se queda en el enlace al que se envió. Los emisores también fijan el TTL de IP, o el límite de saltos de IPv6, en 255 para que el receptor pueda rechazar un paquete que ya cruzó un enrutador; así es como el protocolo detecta la suplantación fuera del enlace, no así como se mantiene local. La localidad viene de la dirección de destino, no de un TTL de un solo salto.

El tipo de túnel también importa. Una interfaz de estilo tun transporta paquetes IP y nada más, así que ningún grupo multicast sobrevive a ella. Un puente de estilo tap amplía el dominio de difusión en sí, y por eso algunos diseños antiguos hacían puente en lugar de enrutar, y heredaron todos los problemas que trae el puente.

Una excepción de LAN de confianza no cambia nada de esto, porque decide qué tráfico puede usar el túnel en lugar de enseñar al túnel a reenviar multicast. El paquete sigue sin tener un segmento compartido donde ser oído.

Elija un diseño de nombres que pueda mantener

Para los recursos de la empresa, la respuesta duradera es un nombre de host enrutado que sirve el resolutor que la VPN empuja, con DNS dividido para que los nombres internos vayan a servidores internos y todo lo demás no. Windows lo expone como tabla de directivas de resolución de nombres, macOS usa resolutores con ámbito por interfaz, y la mayoría de los clientes tienen un ajuste equivalente de empuje. El dispositivo conserva su nombre habitual en el DNS interno, y el descubrimiento deja de formar parte del camino.

Un proxy de descubrimiento o un reflector mDNS puede salvar esa brecha, y es un diseño real con su propio host, su propia exposición y sus propios requisitos de cliente. No aparece porque haya añadido una ruta. Nunca reenvíe consultas .local a un resolutor público: el dominio está reservado para el uso multicast local por RFC 6762, y enviarlo hacia fuera produce fallos lentos y una revelación innecesaria de datos.

Verifique el servicio, no el nombre

Un nombre en una lista de búsqueda demuestra el paso de descubrimiento, no que el servicio responda. Abra la cola de impresión o la interfaz web y complete una operación real, y repítala tras una reconexión.

El descubrimiento almacena nombres en caché de forma agresiva, así que una entrada obsoleta puede parecer un éxito. Si aparece un certificado o una petición de autenticación, es la capa siguiente y un problema aparte. Anote qué mecanismo cambió, resolutor o descubrimiento, para que la siguiente persona no tenga que reabrir toda la cuestión.