El nom d’amfitrió de la LAN falla per VPN: sufix, mDNS o zona?

Al costat del dispositiu, la impressora respon a un nom curt i el servidor de fitxers respon a un àlies. A través del túnel, tots dos noms expiren mentre les seves adreces continuen funcionant. La ruta fa la seva feina; el camí de noms que feia funcionar aquells noms curts mai no va travessar el túnel. Tres mecanismes produeixen aquest comportament i cadascun necessita una correcció diferent.

Comenceu per identificar de quin mecanisme depèn el nom.

Tres tipus de nom que es comporten de manera diferent

Un nom d’una sola etiqueta com fileserver normalment depèn d’un sufix de cerca DNS que afegeix el resolutor. Aquest sufix sovint arriba amb la concessió DHCP local, de manera que un client remot que obté adreçament de la VPN no té cap motiu per conèixer-lo. Afegir una ruta no lliura el sufix. El nom curt simplement deixa d’existir com a nom, tot i que l’adreça que hi ha al darrere és abastable.

Un nom que acaba en .local normalment es resol mitjançant DNS multicast a l’enllaç local, tal com descriu l’RFC 6762. El multicast no travessa un túnel encaminat tret que alguna cosa el pontegi o el proxifiqui deliberadament, així que el nom deixa de resoldre’s en el moment que sortiu del segment.

Un nom d’empresa completament qualificat pertany a una zona interna servida pels resolutors de l’organització. Aquest funciona de manera remota quan la VPN empeny aquests resolutors i el client està configurat per fer-los servir. I localhost és d’ús especial segons l’RFC 6761: es refereix a la màquina que teniu al davant, mai a un servei remot.

Llegiu el resolutor abans de canviar la ruta

Pregunteu quin servidor de noms va respondre i quin sufix es va afegir. La mateixa consulta a través de resolutors diferents dona respostes diferents, i aquesta diferència és l’evidència que necessiteu.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Si la consulta completament qualificada es resol però la curta no, la fallada és del sufix, no del servidor. Si no es resol cap de les dues i l’adreça funciona, el client no està fent servir el resolutor intern en absolut. Compareu la llista de resolutors amb el que la VPN hauria d’empènyer, perquè un client que conserva el seu resolutor local per a cada consulta mai no veurà la zona interna.

Porteu el nom correcte al client

Demaneu a l’administrador el nom d’accés remot documentat, sencer, i feu-lo servir al perfil en comptes d’endevinar sufixos. Si el desplegament admet DNS dividit, configureu el domini intern perquè el resolguin els servidors interns mentre tota la resta conserva el resolutor local. Empenyeu el domini de cerca a través de la configuració de la VPN allà on el client ho admeti.

Verifiqueu el resultat al client i no a la passarel·la. Un paràmetre aplicat al servidor que mai no arriba al client no canvia res.

Manteniu intacta la identitat del certificat

Una prova basada en l’adreça que ignora l’error del certificat només demostra que el sòcol es va obrir. El certificat del servei s’emet per a un nom, i el client continuarà refusant la discrepància amb raó. Si el certificat només llista el nom intern, feu servir aquest nom i arregleu la resolució, o obteniu un certificat que cobreixi l’adreça que voleu utilitzar.

Anoteu el nom, el resolutor i el sufix que van produir una connexió correcta. Aquest registre estalvia a la persona següent repetir la solució provisional basada en l’adreça que amaga el problema real.