mDNS dentro dunha VPN: por que os nomes .local non se resolven

A impresora da oficina aparece en todas as aplicacións do seu escritorio e desaparece na VPN, aínda que pode facer ping ao enderezo que sabe que ten. Nada no túnel está roto: o descubrimento e a accesibilidade son servizos separados, e só un deles atravesa un túnel encamiñado por defecto. As comprobacións seguintes séparanos antes de que comece a engadir rutas. Unha ruta non pode arranxar unha consulta que nunca saíu da ligazón.

Comprobe que se resolve hoxe e que só parece resolto

Separe primeiro as dúas preguntas: unha consulta unicast para un nome de host pregunta a un resolutor, mentres que unha busca de _ipp._tcp pregunta á ligazón local. En Linux, avahi-browse -a mostra o que pode ver o DNS multicast, e resolvectl query name.local mostra o que fai a pila de resolutores con ese nome. En macOS, dns-sd -B _ipp._tcp lista os servizos descubertos sen necesidade dun enderezo previo.

Se o enderezo responde e o nome non, o encamiñamento funciona e o descubrimento non. Un nome .local tamén se pode responder no propio host mediante nss-mdns sen ter avahi-browse instalado, así que un getent ou un ping correcto a ese nome non é proba de que o descubrimento cruzase o túnel; o resultado da busca e o do resolutor son probas distintas. As aplicacións gardan na caché o que descubriron, e por iso o fallo adoita aparecer horas despois de conectarse e non ao conectarse. Peche e volva abrir a aplicación, e comprobe se a entrada na caché contén un nome ou un enderezo, porque un enderezo segue funcionando moito despois de que o descubrimento se detivese.

Por que a consulta nunca cruza o túnel

O DNS multicast envía consultas a 224.0.0.251, dentro do bloque de control da rede local, no porto UDP 5353. Os encamiñadores non reenvían enderezos dese bloque, así que a consulta queda na ligazón á que se enviou. Os emisores tamén fixan o TTL de IP, ou o límite de saltos de IPv6, en 255 para que o receptor poida rexeitar un paquete que xa cruzou un encamiñador; así é como o protocolo detecta a suplantación fóra da ligazón, non así como se mantén local. A localidade vén do enderezo de destino, non dun TTL dun só salto.

O tipo de túnel tamén importa. Unha interface de estilo tun transporta paquetes IP e nada máis, así que ningún grupo multicast sobrevive a ela. Unha ponte de estilo tap amplía o dominio de difusión en si, e por iso algúns deseños antigos facían ponte en lugar de encamiñar, e herdaron todos os problemas que trae a ponte.

Unha excepción de LAN de confianza non cambia nada disto, porque decide que tráfico pode usar o túnel en lugar de ensinar ao túnel a reenviar multicast. O paquete segue sen ter un segmento compartido onde ser oído.

Escolla un deseño de nomes que poida manter

Para os recursos da empresa, a resposta duradeira é un nome de host encamiñado que serve o resolutor que empurra a VPN, con DNS dividido para que os nomes internos vaian a servidores internos e todo o demais non. Windows expono como táboa de políticas de resolución de nomes, macOS usa resolutores con ámbito por interface, e a maioría dos clientes teñen un axuste equivalente de empurre. O dispositivo conserva o seu nome habitual no DNS interno, e o descubrimento deixa de formar parte do camiño.

Un proxy de descubrimento ou un reflector mDNS pode salvar esa fenda, e é un deseño real co seu propio host, a súa propia exposición e os seus propios requisitos de cliente. Non aparece porque engadise unha ruta. Nunca reenvíe consultas .local a un resolutor público: o dominio está reservado para o uso multicast local por RFC 6762, e envialo cara a fóra produce fallos lentos e unha revelación innecesaria de datos.

Verifique o servizo, non o nome

Un nome nunha lista de busca demostra o paso de descubrimento, non que o servizo responda. Abra a cola de impresión ou a interface web e complete unha operación real, e repítaa tras unha reconexión.

O descubrimento garda nomes na caché de forma agresiva, así que unha entrada obsoleta pode parecer un éxito. Se aparece un certificado ou unha petición de autenticación, é a capa seguinte e un problema aparte. Anote que mecanismo cambiou, resolutor ou descubrimento, para que a seguinte persoa non teña que reabrir toda a cuestión.