Punto de conexión privado, mismo nombre de servidor: cadenas de conexión de Azure SQL

Private Link cambia dónde llega una conexión, no cómo se llama la conexión. Para Azure SQL Database esa distinción es todo el diseño: el servidor lógico conserva su nombre, y el punto de conexión privado proporciona una entrada de red a la que se resuelve el nombre. Sustituir el nombre por una dirección IP es el único cambio que rompe TLS, las credenciales y las herramientas a la vez. Dos cadenas de conexión pueden parecer equivalentes y comportarse de forma completamente distinta.

Conserve orders-db.database.windows.net y dé al cliente una respuesta privada para él.

El nombre y la dirección tienen trabajos distintos

El nombre identifica el servicio SQL, y eso es lo que esperan el certificado y el inicio de sesión. La dirección privada proporciona una entrada de red dentro de la red virtual conectada. Confundir una con otra produce una conexión que llega a algo y no se autentica contra nada.

La guía de Microsoft para Azure SQL exige el nombre de servidor normal de los clientes. Una IP directa, e igualmente el nombre con el prefijo privatelink, no es un destino de inicio de sesión intercambiable. Las herramientas que aceptan una IP la aceptarán y luego fallarán en TLS o en la autenticación, lo que oculta el error real. Esos fallos se leen como problemas de credenciales hasta que se mira el nombre de host en el error.

Qué cambia realmente la zona privada

La zona DNS privada registra una dirección para el servidor dentro del espacio de nombres privatelink, y la zona está vinculada a la red virtual que debe usarla. La resolución se mueve; la cadena de conexión no. La forma de abajo es una ilustración, no un registro para pegar 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

Mantenga ese registro y su vínculo de zona como infraestructura, con un propietario y una fecha de revisión.

Dos zonas con el mismo origen y respuestas distintas son el estado final normal, no un conflicto. Los clientes públicos conservan la respuesta pública, y los clientes privados obtienen la dirección del punto de conexión. El modo de fallo que hay que vigilar es la propagación parcial de la vista privada, donde una subred se resuelve de forma privada y otra, en silencio, no.

Los clientes fuera de Azure necesitan un camino hacia esa zona

Un cliente VPN se sitúa fuera del resolutor de Azure, así que la zona privada debe ser alcanzable desde la ruta híbrida. Un reenviador DNS de Azure o Azure DNS Private Resolver pueden atender las consultas que llegan por esa red. La guía de Microsoft es reenviar la zona de servicio público correspondiente mediante esa disposición en lugar de suponer que los clientes consultan el nombre privatelink directamente. Los clientes que no pueden resolver la respuesta privada vuelven a la pública sin quejarse.

Mantenga el alcance del reenvío intencionado, porque sustituir una zona pública en uso rompe nombres que la sustitución no contiene.

Aprovisione en un orden que mantenga la identidad fija

Los pasos tienen propietarios separados: cree y apruebe el punto de conexión, proporcione la ruta VPN, integre el DNS privado y luego configure el cliente con su nombre de servidor normal. Hacer el DNS antes de la ruta produce tiempos de espera que parecen fallos de DNS. Hacer el cliente al final mantiene una variable en movimiento cada vez. Cada paso tiene un resultado observable, así que ninguno tiene que probarse adivinando.

Un icono de VPN conectada no selecciona un destino privado por sí solo.

Qué no desactiva un punto de conexión privado

Crear un punto de conexión privado no desactiva automáticamente el acceso público al servidor lógico. Esa es una decisión de implementación aparte, y corresponde después de que los clientes privados previstos estén confirmados como funcionales. Mantenga una ruta de recuperación y tenga en cuenta las aplicaciones que aún usan la entrada pública. Desactivar primero el acceso público es como un servicio que funciona se convierte en una interrupción con un registro de auditoría ordenado.

Compruebe también qué política de conexión utiliza el servidor.

Redirect envía al cliente a un puerto del nodo tras una conexión inicial a la puerta de enlace, lo que cambia lo que debe permitir la red del cliente. Proxy mantiene el tráfico en la puerta de enlace. Un protocolo de enlace TCP correcto en un puerto no es todo el flujo de inicio de sesión.

Esto es Azure SQL Database, no SQL Managed Instance, que tiene su propio modelo de conectividad y ninguna historia equivalente de punto de conexión privado. En ambos casos, mantenga tres cosas etiquetadas por separado: el nombre, la entrada de red y la credencial. Cambiar por dónde viaja una conexión nunca debería cambiar con qué servicio cree el cliente que habla.