Tudo na conexão parece certo: o túnel está ativo e o console mostra o endpoint privado, mas cada solicitação falha na resolução de nomes. O movimento natural é culpar o túnel, que normalmente se revela inocente. A consulta é enviada a um servidor que não sabe nada sobre a zona privada. Nenhuma mudança de roteamento alterará essa resposta, porque o problema é a quem se perguntou.

Qual resolvedor recebeu a consulta?

Encontre o resolvedor associado a cada enlace antes de olhar para o túnel. O Linux expõe servidores por enlace pelo comando de status do resolvedor, e o macOS mostra resolvedores com escopo no dump de configuração DNS. Se a resposta ainda vem do roteador de casa, o enlace do túnel nunca foi consultado.

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

Aqui se confundem duas etapas: um servidor que empurra um endereço de resolvedor e um cliente que o instala no enlace ativo. Um perfil pode conter a opção, e um log pode mostrar que ela chega, enquanto o sistema operacional continua usando o servidor antigo. Compare o log com o que o enlace relata e confie no enlace.

Use um endereço ao qual a rede da nuvem realmente responde

As redes da nuvem costumam responder a nomes privados por meio de um endereço reservado deslocado dois lugares da base do intervalo, então uma rede que começa em 10.0.0.0 responde em 10.0.0.2. Alguns provedores também publicam um resolvedor local de enlace que funciona sem conhecer o intervalo, o que ajuda quando a rede foi construída por outra pessoa. Consulte o endereço candidato diretamente antes de empurrá-lo para qualquer pessoa. Um endereço que não é resolvedor parece exatamente um descarte de firewall, porque a consulta simplesmente nunca recebe resposta.

Se a consulta direta responde de dentro da rede, mas não pelo túnel, o resolvedor está bem e o caminho entre os dois pontos não. Esse resultado desloca a investigação para rotas, encaminhamento e regras de acesso em vez do perfil do cliente.

Um túnel não transporta o espaço de nomes

Os pacotes atravessam; os nomes não. Cada lado precisa saber qual espaço de nomes pertence ao outro, e isso é um objeto separado de propriedade de quem detém a zona. A forma usual é um encaminhamento para um espaço de nomes, apontado para um resolvedor alcançável pelo túnel.

Na prática, cada direção precisa da sua própria regra, porque o lado que possui a zona é quem deve enviar a consulta adiante. As duas direções exigem que a origem da consulta seja roteada e permitida, e o lado que responde deve devolver as respostas pelo túnel em vez de para a internet. Mantenha o encaminhamento estreito, de modo que apenas o espaço de nomes privado dependa do enlace. Enviar cada consulta por ele transforma uma dependência pequena em queda total no momento em que o túnel cai.

Percorra as fronteiras em ordem

Teste o resolvedor instalado no enlace ativo, depois uma consulta direta a esse resolvedor, depois a mesma consulta do lado distante e, por fim, o aplicativo que usa o mesmo nome. Cada passo isola uma fronteira, então uma falha diz onde olhar em vez de recomeçar a investigação. Uma resposta que funciona enquanto o aplicativo falha aponta para a confiança do certificado ou uma política de API em vez do DNS. Essas falhas são reais, e nenhuma mudança de resolvedor as reparará.

Anote qual passo falhou. Essa única linha é o que a próxima pessoa precisa, e registrá-la leva dez segundos.

Mantenha a cadeia onde a próxima pessoa possa encontrá-la

Registre o resolvedor empurrado, a regra de encaminhamento, a origem de consulta permitida e o endpoint que responde num único lugar. Quando o nome privado falhar de novo, o registro mostra se o túnel mudou, se o endereço do resolvedor mudou ou se uma regra foi estreitada. Sem isso, cada incidente começa do zero e termina com as mesmas três suposições.

Mantenha o registro curto o bastante para continuar exato: quatro linhas, uma data e o nome de quem possui cada parte. Um registro desatualizado é pior do que nenhum, porque parece autoritativo enquanto está errado.

Artigos relacionados