Punt final privat, mateix nom de servidor: cadenes de connexió d’Azure SQL

Private Link canvia on arriba una connexió, no com s’anomena la connexió. Per a Azure SQL Database aquesta distinció és tot el disseny: el servidor lògic conserva el seu nom, i el punt final privat proporciona una entrada de xarxa a què el nom es resol. Substituir el nom per una adreça IP és l’únic canvi que trenca TLS, les credencials i les eines alhora. Dues cadenes de connexió poden semblar equivalents i comportar-se de manera completament diferent.

Mantingueu orders-db.database.windows.net i doneu al client una resposta privada per a ell.

El nom i l’adreça tenen feines diferents

El nom identifica el servei SQL, i això és el que esperen el certificat i l’inici de sessió. L’adreça privada proporciona una entrada de xarxa dins de la xarxa virtual connectada. Confondre una amb l’altra produeix una connexió que arriba a alguna cosa i no s’autentica contra res.

L’orientació de Microsoft per a Azure SQL exigeix el nom de servidor normal dels clients. Una IP directa, i igualment el nom amb el prefix privatelink, no és una destinació d’inici de sessió intercanviable. Les eines que accepten una IP l’acceptaran i després fallaran a TLS o a l’autenticació, cosa que amaga l’error real. Aquests errors es llegeixen com a problemes de credencials fins que mireu el nom d’amfitrió al missatge.

Què canvia realment la zona privada

La zona DNS privada registra una adreça per al servidor dins de l’espai de noms privatelink, i la zona s’enllaça amb la xarxa virtual que l’ha d’utilitzar. La resolució es mou; la cadena de connexió no. La forma de sota és una il·lustració, no un registre per enganxar en una zona pública.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Manteniu aquest registre i el seu enllaç de zona com a infraestructura, amb un propietari i una data de revisió.

Dues zones amb el mateix origen i respostes diferents és l’estat final normal, no un conflicte. Els clients públics conserven la resposta pública, i els clients privats obtenen l’adreça del punt final. El mode de fallada a vigilar és la propagació parcial de la vista privada, on una subxarxa es resol de manera privada i una altra, en silenci, no.

Els clients fora d’Azure necessiten un camí cap a aquesta zona

Un client VPN se situa fora del resolutor d’Azure, així que la zona privada ha de ser abastable des del camí híbrid. Un reenviador DNS d’Azure o Azure DNS Private Resolver poden servir les consultes que arriben per aquesta xarxa. L’orientació de Microsoft és reenviar la zona de servei públic corresponent per aquesta disposició en lloc de suposar que els clients consulten el nom privatelink directament. Els clients que no poden resoldre la resposta privada tornen a la pública sense queixar-se.

Manteniu l’abast del reenviament intencionat, perquè substituir una zona pública en ús trenca noms que la substitució no conté.

Aprovisioneu en un ordre que mantingui la identitat fixa

Els passos tenen propietaris diferents: creeu i aproveu el punt final, proporcioneu la ruta VPN, integreu el DNS privat i, després, configureu el client amb el seu nom de servidor normal. Fer el DNS abans de la ruta produeix temps d’espera que semblen fallades de DNS. Fer el client al final manté una variable en moviment alhora. Cada pas té un resultat observable, així que cap no s’ha de provar endevinant.

Una icona de VPN connectada no selecciona una destinació privada per si sola.

Què no desactiva un punt final privat

Crear un punt final privat no desactiva automàticament l’accés públic al servidor lògic. Aquesta és una decisió de desplegament separada, i pertoca després que els clients privats previstos es confirmin com a funcionals. Manteniu un camí de recuperació i tingueu en compte les aplicacions que encara utilitzen l’entrada pública. Desactivar primer l’accés públic és com un servei que funciona es converteix en una interrupció amb un registre d’auditoria net.

Comproveu també quina política de connexió utilitza el servidor.

Redirect envia el client a un port del node després d’una connexió inicial a la passarel·la, cosa que canvia què ha de permetre la xarxa del client. Proxy manté el trànsit a la passarel·la. Una negociació TCP correcta en un port no és tot el flux d’inici de sessió.

Això és Azure SQL Database, no SQL Managed Instance, que té el seu propi model de connectivitat i cap història equivalent de punt final privat. En tots dos casos, manteniu tres coses etiquetades per separat: el nom, l’entrada de xarxa i la credencial. Canviar on viatja una connexió no hauria de canviar mai a quin servei el client creu que parla.