Azure P2S VPN non pode resolver o nome dun punto de conexión privado

Conecta o túnel de punto a sitio, fai ping ao enderezo privado, abre a aplicación e recibe un 403 ou un erro de certificado no seu lugar. Ambos os síntomas apuntan ao DNS, pero son fallos distintos: un significa que o cliente resolveu o enderezo público, o outro que resolveu o enderezo privado e despois ofreceu un nome que o certificado non cobre. Siga as comprobacións seguintes en orde e detéñase no primeiro fallo, porque unha entrada en hosts ou unha resposta na caché poden facer que cada comprobación posterior pase polo motivo equivocado. Teño esta orde nun ficheiro de texto xunto aos meus perfís de VPN, porque a corrección non cambia nada do túnel e cambiao todo do que sabe o cliente.

Comece polo enderezo que o cliente recibe de verdade

Pregunte ao solucionador directamente en lugar de confiar na aplicación. En Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net mostra que vista recibiu o cliente. Unha resposta pública significa que nada augas abaixo chegará ao punto de conexión; o enderezo privado do punto de conexión significa que o DNS rematou e que a seguinte comprobación é a propia conexión.

Un punto de conexión privado non cambia o nome do servizo. A conta ou a aplicación conserva o seu nome completo habitual, e o punto de conexión só cambia o enderezo ao que ese nome se resolve para os clientes dentro da rede virtual. Por iso o mesmo nome de host resólvese de forma privada desde unha VM da rede e de forma pública desde un portátil ao que nunca se lle deu a vista privada.

Comprobe a zona, a súa ligazón e o rexistro antes do túnel

Tres condicións deben cumprirse á vez: a zona privada existe, está ligada á rede virtual pola que entran en Azure a pasarela de VPN e os clientes, e contén un rexistro A do punto de conexión que apunta ao enderezo privado. Ligazón a zona a unha rede allea e a pasarela seguirá resolvendo o rexistro público mentres todo o túnel parece san.

Os nomes de zona pertencen aos servizos, non ás ligazóns privadas en xeral. App Service adoita usar privatelink.azurewebsites.net, o almacenamento e SQL teñen os seus propios espazos de nomes, e tomar prestada a zona doutro servizo produce unha zona que existe e non responde nada útil.

Déalle ao cliente un solucionador que realmente poida alcanzar

168.63.129.16 responde desde máquinas virtuais de Azure e non é un servidor DNS para un portátil ao outro lado dun túnel de punto a sitio. O cliente necesita un solucionador accesible polo túnel: un punto de conexión entrante de Azure DNS Private Resolver, un reenviador dentro da rede virtual ou entradas de servidor DNS transportadas no perfil do cliente VPN para que o cliente pregunte á rede virtual directamente.

Un solucionador configurado pero inalcanzable compórtase exactamente como ningún solucionador, e o síntoma é un tempo de espera en lugar dunha resposta incorrecta, por iso se malinterpreta como un problema de firewall. Próbéo cunha consulta que o túnel deba transportar, non cun nome público que habería funcionar pola ligazón local de todos os xeitos.

Se reenvía en lugar de inserir configuracións, reenvíe o espazo de nomes que posúe a zona privada, privatelink.azurewebsites.net en lugar de todo azurewebsites.net. Un reenviador condicional que traga todo o sufixo pai envía a Azure cada busca do servizo, incluídas as que deberían quedar locais.

Use o nome para o que se emitiu o certificado

Cando o enderezo é correcto aparece o segundo fallo. O almacenamento e App Service publican un alias privatelink, e ese alias non é necesariamente o nome do certificado. Unha carga con AzCopy dirixida a privatelink.blob.core.windows.net fallou a validación; a mesma carga a <account>.blob.core.windows.net/<container> resolveuse ao enderezo privado e pasou, así que quedou na ruta privada sen ningunha excepción.

A regra vale no navegador e tamén para App Service: conéctese co nome de host que cobre o certificado e deixe que DNS proporcione o enderezo privado. Non recorra a saltar a validación, porque converte un erro de nomenclatura nunha regresión de seguridade. Un ping correcto demostra a ruta e non di nada do nome dentro do saldo, por iso seguen sendo comprobacións separadas.

Unha orde de catro pasos que illa cada capa

1. Confirme que o cliente VPN ten un enderezo do conxunto de punto a sitio e unha ruta cara ao enderezo privado do punto de conexión.
2. Resolva o nome exacto que usa a aplicación e compare a resposta co enderezo do punto de conexión.
3. Abra unha conexión TCP ao punto de conexión no porto do servizo e despois lea o nome do certificado que se presenta nesa conexión.
4. Só agora probe a autorización, porque unha ruta que funciona e un certificado válido aínda non dan acceso ao recurso.

Unha conexión rexeitada co enderezo correcto apunta ao grupo de seguridade de rede ou ao estado de conexión do punto de conexión privado, non ao DNS, así que compróbeos antes de volver editar a configuración do solucionador. Un desaxuste de nome TLS devólveo ao nome de host da URL e ao subject do certificado. Garde xuntos a saída de resolución, o nome do certificado e a URL exacta; eses tres valores explican a maioría destes casos sen tocar a pasarela.

Use unha VM dentro da rede virtual como control. Se o nome se resolve de forma privada alí e de forma pública desde o túnel, a zona e o rexistro son correctos e a única diferenza é a ruta do solucionador do cliente, que se confirma máis rápido que outra pasada pola configuración do punto de conexión.

Os clientes tamén almacenan na caché. Un rexistro que respondeu de forma pública hai dez minutos segue respondendo despois de arranxar a zona, así que baleire a caché antes de volver probar. En Windows, ipconfig /flushdns limpa a caché do cliente; as regras de política de resolución de nomes persisten, deciden que sufixo vai a que servidor e poden seguir enviando o espazo de nomes ao solucionador que acaba de substituír.

Onde encaixa unha entrada en hosts

Engadir o enderezo do punto de conexión a un ficheiro hosts é un bo diagnóstico e un mal deseño. Demostra que a correspondencia entre nome e enderezo é a peza que falta e déixalle probar todo o posterior, pero é invisible para os seus usuarios, rompe cando cambia o enderezo do punto de conexión e oculta a zona que debería responder.

Unha entrada de proba que queda é peor que unha caché obsoleta, porque pode facer que a ruta arranxada pareza rota ou a ruta rota pareza arranxada segundo a dirección do erro. Elimína antes da pasada final e resolva só co solucionador de produción.

Os nomes curtos necesitan un sufixo de busca e os nomes completos non, así que probe primeiro o nome completo e logo decida se o fluxo de traballo necesita un sufixo inserido polo perfil do cliente. Microsoft documenta os nomes de zona e as formas de rexistro de cada servizo nas súas directrices de DNS para puntos de conexión privados; lea a entrada do seu servizo en lugar de copiar unha zona doutro.