Azure P2S VPN no pot resoldre el nom d'un punt de connexió privat

Connecteu el túnel punt a lloc, feu ping a l'adreça privada, obriu l'aplicació i obteniu un 403 o un error de certificat. Tots dos símptomes apunten al DNS, però són avaries diferents: una significa que el client ha resolt l'adreça pública, l'altra que ha resolt l'adreça privada i després ha ofert un nom que el certificat no cobreix. Feu les comprovacions següents per ordre i atureu-vos a la primera fallada, perquè una entrada a hosts o una resposta en memòria cau poden fer que cada comprovació posterior passi per la raó equivocada. Tinc aquest ordre en un fitxer de text al costat dels meus perfils de VPN, perquè la correcció no canvia res del túnel i ho canvia tot del que sap el client.

Comenceu per l'adreça que el client rep realment

Pregunteu al resolutor directament en lloc de confiar en l'aplicació. A Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net mostra quina vista ha rebut el client. Una resposta pública vol dir que res més avall no arribarà al punt de connexió; l'adreça privada del punt de connexió vol dir que el DNS ja està fet i que la comprovació següent és la connexió mateixa.

Un punt de connexió privat no canvia el nom del servei. El compte o l'aplicació conserva el seu nom complet habitual, i el punt de connexió només canvia l'adreça a què es resol aquest nom per als clients dins de la xarxa virtual. Per això el mateix nom d'amfitrió es resol de manera privada des d'una VM de la xarxa i de manera pública des d'un portàtil que mai no ha rebut la vista privada.

Comproveu la zona, el seu enllaç i el registre abans del túnel

Tres condicions s'han de complir alhora: la zona privada existeix, està enllaçada a la xarxa virtual on entren a Azure la passarel·la de VPN i els clients, i conté un registre A del punt de connexió que apunta a l'adreça privada. Enllaceu la zona a una xarxa no relacionada i la passarel·la continuarà resolent el registre públic mentre tot el túnel sembla sa.

Els noms de zona pertanyen als serveis, no als enllaços privats en general. App Service normalment fa servir privatelink.azurewebsites.net, l'emmagatzematge i SQL tenen els seus propis espais de noms, i manllevar la zona d'un altre servei produeix una zona que existeix i no respon res d'útil.

Doneu al client un resolutor que realment pugui abastar

168.63.129.16 respon des de màquines virtuals d'Azure i no és un servidor DNS per a un portàtil a l'altre costat d'un túnel punt a lloc. El client necessita un resolutor abastable a través del túnel: un punt de connexió d'entrada d'Azure DNS Private Resolver, un reenviador dins de la xarxa virtual, o entrades de servidor DNS portades al perfil del client VPN perquè el client pregunti directament a la xarxa virtual.

Un resolutor configurat però inabastable es comporta exactament com cap resolutor, i el símptoma és un temps d'espera i no una resposta incorrecta, per això es malinterpreta com un problema de tallafoc. Proveu-lo amb una consulta que el túnel ha de portar, no amb un nom públic que ja hauria funcionat per l'enllaç local.

Si reenvieu en lloc d'empènyer configuracions, reenvieu l'espai de noms que posseeix la zona privada, privatelink.azurewebsites.net en lloc de tot azurewebsites.net. Un reenviador condicional que s'empassa tot el sufix pare envia a Azure cada consulta del servei, incloses les que haurien de quedar-se locals.

Utilitzeu el nom pel qual es va emetre el certificat

Quan l'adreça és correcta, apareix la segona avaria. L'emmagatzematge i App Service publiquen un àlies privatelink, i aquest àlies no és necessàriament el nom del certificat. Una pujada amb AzCopy adreçada a privatelink.blob.core.windows.net va fallar la validació; la mateixa pujada a <account>.blob.core.windows.net/<container> es va resoldre a l'adreça privada i va passar, així que es va quedar al camí privat sense cap excepció.

La regla val al navegador i també per a App Service: connecteu-vos amb el nom d'amfitrió que cobreix el certificat i deixeu que el DNS proporcioni l'adreça privada. No recorreu a saltar-vos la validació, perquè converteix un error de nomenclatura en una regressió de seguretat. Un ping correcte demostra la ruta i no diu res del nom dins de l'apretada de mans, per això són comprovacions separades.

Un ordre de quatre passos que aïlla cada capa

1. Confirmeu que el client VPN té una adreça del pool punt a lloc i una ruta cap a l'adreça privada del punt de connexió.
2. Resoleu el nom exacte que fa servir l'aplicació i compareu la resposta amb l'adreça del punt de connexió.
3. Obriu una connexió TCP al punt de connexió pel port del servei i després llegiu el nom del certificat que es presenta en aquesta connexió.
4. Només ara proveu l'autorització, perquè un camí que funciona i un certificat vàlid encara no donen accés al recurs.

Una connexió rebutjada amb l'adreça correcta assenyala el grup de seguretat de xarxa o l'estat de connexió del punt de connexió privat, no el DNS, així que comproveu-ho abans de tornar a editar la configuració del resolutor. Un desajust de nom TLS us retorna al nom d'amfitrió de l'URL i al subject del certificat. Guardeu junts la sortida de resolució, el nom del certificat i l'URL exacta; aquests tres valors expliquen la majoria d'aquests casos sense tocar la passarel·la.

Feu servir una VM dins de la xarxa virtual com a control. Si el nom es resol privadament allà i públicament des del túnel, la zona i el registre són correctes i l'única diferència és el camí del resolutor del client, que es confirma més de pressa que una altra passada per la configuració del punt de connexió.

Els clients també fan memòria cau. Un registre que va respondre públicament fa deu minuts continua responent després d'arreglar la zona, així que buideu-la abans de tornar a provar. A Windows, ipconfig /flushdns neteja la memòria cau del client; les regles de política de resolució de noms persisteixen, decideixen quin sufix va a quin servidor i poden continuar enviant l'espai de noms al resolutor que acabeu de substituir.

On pertoca una entrada a hosts

Afegir l'adreça del punt de connexió a un fitxer hosts és un bon diagnòstic i un mal disseny. Demostra que la correspondència entre nom i adreça és la peça que falta i us deixa provar tot el que ve després, però és invisible per als usuaris, es trenca quan canvia l'adreça del punt de connexió i amaga la zona que hauria de respondre.

Una entrada de prova romanent és pitjor que una memòria cau obsoleta, perquè pot fer que el camí arreglat sembli trencat o el camí trencat sembli arreglat segons la direcció de l'error. Traieu-la abans de la passada final i resoleu només amb el resolutor de producció.

Els noms curts necessiten un sufix de cerca i els noms complets no, així que proveu primer el nom complet i després decidiu si el flux de treball necessita un sufix empès pel perfil del client. Microsoft documenta els noms de zona i les formes de registre de cada servei a les seves directrius de DNS per a punts de connexió privats; llegiu l'entrada del vostre servei en lloc de copiar una zona d'un altre.