mDNS dins d’una VPN: per què els noms .local no es resolen

La impressora de l’oficina apareix a totes les aplicacions del vostre escriptori i desapareix a la VPN, encara que pugueu fer ping a l’adreça que sabeu que té. Al túnel no hi ha res trencat: el descobriment i l’abastabilitat són serveis separats, i només un d’ells travessa un túnel encaminat per defecte. Les comprovacions següents els separen abans que comenceu a afegir rutes. Una ruta no pot arreglar una consulta que mai no va sortir de l’enllaç.

Comproveu què es resol avui i què només sembla resolt

Separeu primer les dues preguntes: una consulta unicast per a un nom d’amfitrió pregunta a un resolutor, mentre que una cerca de _ipp._tcp pregunta a l’enllaç local. A Linux, avahi-browse -a mostra què pot veure el DNS multicast, i resolvectl query name.local mostra què fa la pila de resolutors amb aquest nom. A macOS, dns-sd -B _ipp._tcp llista els serveis descoberts sense necessitat d’una adreça prèvia.

Si l’adreça respon i el nom no, l’encaminament funciona i el descobriment no. Un nom .local també es pot respondre al mateix amfitrió mitjançant nss-mdns sense tenir avahi-browse instal·lat, així que un getent o un ping correcte a aquest nom no és prova que el descobriment hagi travessat el túnel; el resultat de la cerca i el del resolutor són proves diferents. Les aplicacions fan memòria cau del que han descobert, i per això la fallada sovint apareix hores després de connectar-se i no en connectar-se. Tanqueu i torneu a obrir l’aplicació, i comproveu si l’entrada a la memòria cau conté un nom o una adreça, perquè una adreça continua funcionant molt després que el descobriment s’hagi aturat.

Per què la consulta no travessa mai el túnel

El DNS multicast envia consultes a 224.0.0.251, dins del bloc de control de la xarxa local, al port UDP 5353. Els encaminadors no reenvien adreces d’aquest bloc, de manera que la consulta es queda a l’enllaç on es va enviar. Els emissors també fixen el TTL d’IP, o el límit de salts d’IPv6, a 255 perquè el receptor pugui rebutjar un paquet que ja ha travessat un encaminador; així és com el protocol detecta la suplantació fora de l’enllaç, no així com es manté local. La localitat ve de l’adreça de destinació, no d’un TTL d’un sol salt.

El tipus de túnel també importa. Una interfície d’estil tun transporta paquets IP i res més, així que cap grup multicast no hi sobreviu. Un pont d’estil tap amplia el domini de difusió mateix, i per això alguns dissenys antics feien pont en lloc d’encaminar, i van heretar tots els problemes que comporta fer pont.

Una excepció de LAN de confiança no canvia res d’això, perquè decideix quin trànsit pot fer servir el túnel en lloc d’ensenyar el túnel a reenviar multicast. El paquet continua sense cap segment compartit on ser sentit.

Trieu un disseny de noms que pugueu mantenir

Per als recursos de l’empresa, la resposta duradora és un nom d’amfitrió encaminat que serveix el resolutor que la VPN empeny, amb DNS dividit perquè els noms interns vagin a servidors interns i la resta no. Windows ho exposa com a taula de polítiques de resolució de noms, macOS fa servir resolutors amb abast per interfície, i la majoria de clients tenen un paràmetre equivalent d’impulsió. El dispositiu conserva el seu nom habitual al DNS intern, i el descobriment deixa de formar part del camí.

Un servidor intermediari de descobriment o un reflector mDNS pot salvar aquesta bretxa, i és un disseny real amb el seu propi amfitrió, la seva pròpia exposició i els seus propis requisits de client. No apareix perquè hàgiu afegit una ruta. No reenvieu mai consultes .local a un resolutor públic: el domini està reservat per a l’ús multicast local per RFC 6762, i enviar-lo cap enfora produeix fallades lentes i una revelació innecessària de dades.

Verifiqueu el servei, no el nom

Un nom en una llista de cerca demostra el pas de descobriment, no que el servei respongui. Obriu la cua d’impressió o la interfície web i completeu una operació real, i repetiu-la després d’una reconnexió.

El descobriment fa memòria cau dels noms de manera agressiva, així que una entrada antiga pot semblar un èxit. Si apareix un certificat o una petició d’autenticació, és la capa següent i un problema a part. Anoteu quin mecanisme heu canviat, resolutor o descobriment, perquè la persona següent no hagi de reobrir tota la qüestió.