Por que un punto de conexión privado segue respondendo cun enderezo público

O portátil conéctase, o túnel declárase activo e a conta de almacenamento segue rexeitando todas as solicitudes. O punto de conexión privado existe, a ruta cara á súa subrede existe, e o nome ou responde cun enderezo público ou non se resolve. Non hai nada mal co túnel: nunca se lle dixo ao cliente que servidor debía responder por ese nome. Segue a consulta cara a fóra e o oco vólvese evidente.

Comeza polo resolutor do cliente

Pregunta ao cliente a que servidor consulta mentres o túnel está activo. Un perfil de punto a sitio fornece ese enderezo, e un perfil que non fornece nada deixa que o sistema operativo recorra aos valores predeterminados do adaptador.

Os resolutores públicos non teñen visión ningunha dunha zona privada, así que responden desde internet, que é exactamente o seu traballo. A primeira comprobación é, xa que logo, o enderezo do resolutor en uso, non o túnel e non o punto de conexión.

Le o que é realmente a resposta

Resolve o nome do servizo e le o enderezo que volve. Unha resposta pública significa que a consulta chegou a un servidor que non pode ver a zona. A ausencia de resposta significa que o nome só existe de forma privada e que nada ao que o cliente poida chegar o contén.

Eses dous resultados producen erros de aplicación semellantes e pertencen a propietarios distintos. Un é un problema de selección de resolutor, o outro é unha vinculación de zona que falta.

Unha entrada hosts demostra a ruta e despois mente

Pór o enderezo do punto de conexión no ficheiro hosts local é a forma máis rápida de demostrar que o túnel e a devasa do servizo xa funcionan. Se a solicitude ten éxito con esa entrada, só está rota a resolución de nomes. Tamén é un cambio por máquina que cobre exactamente un nome.

Non axuda á segunda conta, ao segundo punto de conexión nin a un compañeiro, e rompe sen aviso cando o punto de conexión se recrea nun enderezo novo.

Peor aínda, fai que a túa máquina se comporte de forma distinta á de todos os demais, e así é como unha avaría do resolutor sobrevive unha semana de investigación. Úsaa para confirmar a ruta, despois quitaa e corrixe a causa.

Vincula a zona e reparte un resolutor

Dúas condicións deben cumprirse á vez. A zona privada debe estar vinculada á rede virtual onde vive o punto de conexión, e o cliente debe enviar as súas consultas a un servidor que poida ler esa zona. Un punto de conexión de entrada de DNS Private Resolver fornece ese enderezo dentro da rede e responde ás consultas que chegan polo túnel. Pon ese enderezo no perfil de VPN e engade o sufixo privado que o cliente debe aplicar.

Un resolutor local xa existente pode acadar o mesmo resultado mediante un reenviador condicional dirixido á zona.

As regras de rede do resolutor contan tanto como o encamiñamento. Se a regra de entrada exclúe o rango de clientes de VPN, as consultas caducan en lugar de devolver unha resposta incorrecta. É ese tempo de espera o que devolve a xente a unha táboa de rutas onde nada está mal.

Comproba nome, porto e identidade por orde

Traballa por orde: resolve o nome, confirma que a resposta é privada, abre o porto e fai unha solicitude autenticada. Cada etapa ten o seu propio dono e a súa propia sinatura de fallo.

Unha resposta privada seguida dun tempo de espera apunta a unha ruta ou a unha devasa. Unha resposta pública apunta ao resolutor. Unha conexión completada que devolve un erro de identidade pertence ao servizo.

Outro fallo pertence a esta lista. Unha devasa de servizo que permite un enderezo de cliente deixa de coincidir cando o grupo asigna ese enderezo a outra sesión tras reconectarse. Le o enderezo do chamante que o servizo rexistrou, non o que o cliente cre ter. Os dous discrepan máis a miúdo do que a xente espera. A guía de Azure DNS Private Resolver cobre a vinculación de zona e a disposición de reenvío.