Por que um ponto de extremidade privado ainda responde com um endereço público

O portátil se conecta, o túnel se declara ativo e a conta de armazenamento continua recusando todas as solicitações. O ponto de extremidade privado existe, a rota para a sua sub-rede existe, e o nome ou responde com um endereço público ou não é resolvido. Nada está errado com o túnel: nunca se disse ao cliente qual servidor deveria responder por esse nome. Siga a consulta para fora e a lacuna se torna óbvia.

Comece pelo resolvedor do cliente

Pergunte ao cliente qual servidor ele consulta enquanto o túnel está ativo. Um perfil ponto a site fornece esse endereço, e um perfil que não fornece nada deixa o sistema operacional recorrer aos padrões do adaptador.

Resolvedores públicos não têm qualquer visão de uma zona privada, então respondem pela internet, o que é exatamente o trabalho deles. A primeira verificação é, portanto, o endereço do resolvedor em uso, não o túnel e não o ponto de extremidade.

Leia o que a resposta realmente é

Resolva o nome do serviço e leia o endereço que volta. Uma resposta pública significa que a consulta chegou a um servidor que não consegue ver a zona. Nenhuma resposta significa que o nome existe apenas de forma privada e que nada que o cliente alcance o mantém.

Esses dois resultados produzem erros de aplicação semelhantes e pertencem a proprietários diferentes. Um é um problema de escolha de resolvedor, o outro é um vínculo de zona ausente.

Uma entrada hosts prova o caminho e depois mente

Colocar o endereço do ponto de extremidade no arquivo hosts local é a forma mais rápida de provar que o túnel e o firewall do serviço já funcionam. Se a solicitação tiver êxito com essa entrada, apenas a resolução de nomes está quebrada. Também é uma alteração por máquina que cobre exatamente um nome.

Não ajuda a segunda conta, o segundo ponto de extremidade ou um colega, e quebra sem aviso quando o ponto de extremidade é recriado em um novo endereço.

Pior, faz a sua máquina se comportar de forma diferente da de todos, e é assim que uma falha de resolvedor sobrevive a uma semana de investigação. Use-a para confirmar o caminho, depois remova-a e corrija a causa.

Vincule a zona e distribua um resolvedor

Duas condições precisam valer ao mesmo tempo. A zona privada deve estar vinculada à rede virtual onde vive o ponto de extremidade, e o cliente deve enviar suas consultas a um servidor que consiga ler essa zona. Um ponto de extremidade de entrada do DNS Private Resolver fornece esse endereço dentro da rede e responde às consultas que chegam pelo túnel. Coloque esse endereço no perfil de VPN e adicione o sufixo privado que o cliente deve aplicar.

Um resolvedor local já existente pode alcançar o mesmo resultado por meio de um encaminhador condicional direcionado à zona.

As regras de rede no resolvedor contam tanto quanto o roteamento. Se a regra de entrada excluir a faixa de clientes VPN, as consultas expiram em vez de retornar uma resposta errada. É essa expiração que manda as pessoas de volta a uma tabela de rotas onde nada está errado.

Verifique nome, porta e identidade em ordem

Trabalhe em ordem: resolva o nome, confirme que a resposta é privada, abra a porta e faça uma solicitação autenticada. Cada etapa tem seu próprio responsável e sua própria assinatura de falha.

Uma resposta privada seguida de expiração aponta para uma rota ou um firewall. Uma resposta pública aponta para o resolvedor. Uma conexão concluída que retorna um erro de identidade pertence ao serviço.

Mais uma falha pertence a esta lista. Um firewall de serviço que permite um endereço de cliente deixa de corresponder quando o pool entrega esse endereço a outra sessão após uma reconexão. Leia o endereço do chamador que o serviço registrou, não o que o cliente acredita ter. Os dois discordam com mais frequência do que as pessoas esperam. As orientações do Azure DNS Private Resolver cobrem o vínculo da zona e a disposição do encaminhamento.