Punto de conexión privado, mesmo nome de servidor: cadeas de conexión de Azure SQL

Private Link cambia onde chega unha conexión, non como se chama a conexión. Para Azure SQL Database esa distinción é todo o deseño: o servidor lóxico conserva o seu nome, e o punto de conexión privado proporciona unha entrada de rede á que se resolve o nome. Substituír o nome por un enderezo IP é o único cambio que rompe TLS, as credenciais e as ferramentas ao mesmo tempo. Dúas cadeas de conexión poden parecer equivalentes e comportarse de xeito completamente distinto.

Conserve orders-db.database.windows.net e dea ao cliente unha resposta privada para el.

O nome e o enderezo teñen traballos distintos

O nome identifica o servizo SQL, e iso é o que esperan o certificado e o inicio de sesión. O enderezo privado proporciona unha entrada de rede dentro da rede virtual conectada. Confundir un co outro produce unha conexión que chega a algo e non se autentica contra nada.

A guía de Microsoft para Azure SQL esixe o nome de servidor normal dos clientes. Un IP directo, e igualmente o nome co prefixo privatelink, non é un destino de inicio de sesión intercambiable. As ferramentas que aceptan un IP aceptarana e despois fallarán en TLS ou na autenticación, o que oculta o erro real. Eses fallos lese como problemas de credenciais ata que se mira o nome de host no erro.

Que cambia realmente a zona privada

A zona DNS privada rexistra un enderezo para o servidor dentro do espazo de nomes privatelink, e a zona está vinculada á rede virtual que debe usala. A resolución móvese; a cadea de conexión non. A forma de abaixo é unha ilustración, non un rexistro para pegar nunha 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

Manteña ese rexistro e o seu vínculo de zona como infraestrutura, cun propietario e unha data de revisión.

Dúas zonas coa mesma orixe e respostas distintas son o estado final normal, non un conflito. Os clientes públicos conservan a resposta pública, e os clientes privados obteñen o enderezo do punto de conexión. O modo de fallo que hai que vixiar é a propagación parcial da vista privada, onde unha subrede se resolve de forma privada e outra, en silencio, non.

Os clientes fóra de Azure necesitan un camiño cara a esa zona

Un cliente VPN sitúase fóra do resolvedor de Azure, así que a zona privada debe ser alcanzable desde a ruta híbrida. Un reenviador DNS de Azure ou Azure DNS Private Resolver poden atender as consultas que chegan por esa rede. A guía de Microsoft é reenviar a zona de servizo público correspondente mediante esa disposición en lugar de supoñer que os clientes consultan o nome privatelink directamente. Os clientes que non poden resolver a resposta privada volven á pública sen queixarse.

Manteña o alcance do reenvío intencionado, porque substituír unha zona pública en uso rompe nomes que a substitución non contén.

Aprovisione nunha orde que manteña a identidade fixa

Os pasos teñen propietarios separados: cree e aprobe o punto de conexión, proporcione a ruta VPN, integre o DNS privado e despois configure o cliente co seu nome de servidor normal. Facer o DNS antes da ruta produce tempos de espera que parecen fallos de DNS. Facer o cliente ao final mantén unha variable en movemento á vez. Cada paso ten un resultado observable, así que ningún ten que probarse adiviñando.

Unha icona de VPN conectada non selecciona un destino privado por si soa.

Que non desactiva un punto de conexión privado

Crear un punto de conexión privado non desactiva automaticamente o acceso público ao servidor lóxico. Esa é unha decisión de despregamento separada, e corresponde despois de que os clientes privados previstos se confirmen como funcionais. Manteña unha ruta de recuperación e teña en conta as aplicacións que aínda usan a entrada pública. Desactivar primeiro o acceso público é como un servizo que funciona se converte nunha interrupción cun rexistro de auditoría ordenado.

Comprobe tamén que política de conexión usa o servidor.

Redirect envía o cliente a un porto do nodo tras unha conexión inicial á pasarela, o que cambia o que debe permitir a rede do cliente. Proxy mantén o tráfico na pasarela. Unha negociación TCP correcta nun porto non é todo o fluxo de inicio de sesión.

Isto é Azure SQL Database, non SQL Managed Instance, que ten o seu propio modelo de conectividade e ningunha historia equivalente de punto de conexión privado. En ambos os casos, manteña tres cousas etiquetadas por separado: o nome, a entrada de rede e a credencial. Cambiar por onde viaxa unha conexión nunca debería cambiar con que servizo cre o cliente que fala.