O túnel está activo, pero por que segue fallando o nome privado?

Todo na conexión parece correcto: o túnel está activo e a consola mostra o extremo privado, pero cada solicitude falla na resolución de nomes. O movemento natural é culpar o túnel, que normalmente resulta inocente. A consulta envíase a un servidor que non sabe nada da zona privada. Ningún cambio de encamiñamento alterará esa resposta, porque o problema é a quen se preguntou.

Que resolutor recibiu a consulta?

Atope o resolutor asociado a cada enlace antes de mirar o túnel. Linux expón servidores por enlace mediante o comando de estado do resolutor, e macOS mostra resolutores con ámbito no seu volcado de configuración DNS. Se a resposta aínda vén do router da casa, o enlace do túnel nunca se consultou.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Aquí confúndense dúas etapas: un servidor que empurra un enderezo de resolutor e un cliente que o instala no enlace activo. Un perfil pode conter a opción e un rexistro pode mostrar que chega, mentres o sistema operativo segue usando o servidor antigo. Compare o rexistro co que informa o enlace e confíe no enlace.

Use un enderezo ao que a rede da nube responda de verdade

As redes da nube adoitan responder a nomes privados mediante un enderezo reservado desprazado dous lugares desde a base do rango, así que unha rede que comeza en 10.0.0.0 responde en 10.0.0.2. Algúns provedores tamén publican un resolutor local de enlace que funciona sen coñecer o rango, o que axuda cando a rede a construíu outra persoa. Consulte o enderezo candidato directamente antes de pasarlle a ninguén. Un enderezo que non é un resolutor parece exactamente unha caída do cortafogos, porque a consulta simplemente nunca recibe resposta.

Se a consulta directa responde desde dentro da rede pero non a través do túnel, o resolutor está ben e o camiño entre os dous puntos non. Ese resultado traslada a investigación a rutas, reenvío e regras de acceso en lugar do perfil do cliente.

Un túnel non transporta o espazo de nomes

Os paquetes atravesan; os nomes non. Hai que dicir a cada lado que espazo de nomes pertence ao outro, e iso é un obxecto separado que posúe quen ten a zona. A forma habitual é un reenvío para un espazo de nomes, apuntado a un resolutor accesible polo túnel.

Na práctica, cada dirección necesita a súa propia regra, porque o lado que posúe a zona é o que debe enviar a consulta. As dúas direccións necesitan que a orixe da consulta estea encamiñada e permitida, e o lado que responde debe devolver as respostas polo túnel en lugar de cara a internet. Manteña o reenvío estreito, de xeito que só o espazo de nomes privado dependa do enlace. Enviar cada consulta a través del converte unha dependencia pequena nunha caída total no momento en que o túnel cae.

Percorra as fronteiras en orde

Probe o resolutor instalado no enlace activo, despois unha consulta directa a ese resolutor, despois a mesma consulta desde o lado afastado e por último a aplicación que usa o mesmo nome. Cada paso illa unha fronteira, así que un fallo di onde mirar en lugar de reiniciar a investigación. Unha resposta que funciona mentres a aplicación falla apunta á confianza do certificado ou a unha política de API en lugar de DNS. Eses fallos son reais e ningún cambio de resolutor os reparará.

Anote que paso fallou. Esa única liña é o que necesita a seguinte persoa, e rexistrala leva dez segundos.

Manteña a cadea onde a seguinte persoa poida atopala

Rexiste o resolutor empurrado, a regra de reenvío, a orixe de consulta permitida e o extremo que responde nun só lugar. Cando o nome privado volva fallar, o rexistro mostra se o túnel se moveu, se o enderezo do resolutor cambiou ou se se estreitou unha regra. Sen el, cada incidente comeza de cero e remata coas mesmas tres conxecturas.

Manteña o rexistro o bastante curto para seguir sendo exacto: catro liñas, unha data e o nome de quen posúe cada parte. Un rexistro antigo é peor que ningún, porque parece autoritativo mentres está equivocado.