Tu VPN no hace privado Cosmos DB por sí sola

Conectas el portátil a la VNet mediante una VPN, abres la URL de la cuenta de Cosmos DB y la solicitud sigue saliendo por la internet pública. El túnel hizo su trabajo. Lo que no hizo fue crear un punto de conexión privado, publicar el registro DNS privado o desactivar el acceso público, porque son tres cambios separados en la cuenta y no propiedades de tu conexión de red. Este ejemplo usa Azure Cosmos DB para NoSQL, un punto de conexión privado en una VNet y un portátil conectado a esa VNet por VPN, y mantiene la dirección de la aplicación sin cambios.

El mito: estar en la VPN hace privada la base de datos

Estar en la VNet solo significa que tus paquetes pueden alcanzar direcciones privadas en esa VNet. No dice nada sobre dónde se resuelve el nombre de la cuenta, ni dice nada sobre si la cuenta sigue aceptando tráfico público.

Un punto de conexión privado es un recurso aparte con su propia dirección, su propio paso de aprobación y su propio cableado DNS. Hasta que exista y se apruebe, el nombre se resuelve al punto de conexión público y tu tráfico va allí independientemente del túnel.

Qué hace que el nombre se resuelva de forma privada

Mantén el punto de conexión normal de la cuenta del SDK, algo como https://ACCOUNT.documents.azure.com. El DNS privado debería resolver ese nombre a través de la cadena de Private Link hasta las direcciones privadas del punto de conexión. No lo sustituyas por una URL numérica ni desactives las comprobaciones de certificados, porque eso cambia un problema de DNS por un problema de seguridad.

Esos valores son específicos de la API NoSQL. Las demás API de Cosmos no son entradas intercambiables en el mismo ejemplo, y copiar el nombre del subrecurso de otra API produce un punto de conexión que nunca se resuelve.

Crea y aprueba el punto de conexión mediante el flujo de trabajo autorizado de Azure y luego usa su integración con el grupo de zonas DNS privadas. El portátil necesita un resolutor que pueda responder por esa zona, ya sea directamente o mediante un reenvío aprobado, y una ruta de cliente VPN a cada dirección relevante del punto de conexión.

Un punto de conexión privado puede tener más de una dirección, incluidas entradas globales y regionales. Mantén la integración DNS cuando cambien las regiones de la cuenta en lugar de fijar una sola dirección en un archivo hosts, y recuerda que una respuesta de un resolutor público no relacionado no demuestra nada sobre la ruta privada. Si reenvías DNS a través de un concentrador, confirma que el reenviador responde antes de depurar el cliente. Un reenviador obsoleto devuelve la respuesta pública, que se ve exactamente como un punto de conexión ausente.

El modo Gateway y el modo Direct no son intercambiables

El modo Gateway envía las solicitudes del servicio por HTTPS sobre TCP 443. Por eso una política de cortafuegos solo para el 443 funciona con él y por eso este ejemplo lo elige deliberadamente.

El modo Direct sobre Private Link tiene requisitos de conectividad distintos, incluido un rango de puertos TCP más amplio que enumera la documentación de la cuenta. Una política escrita para el modo Gateway no debe reutilizarse en silencio para un cliente en modo Direct, o el SDK se conectará y luego se colgará en la primera operación de datos.

Elige un modo, anótalo con la cuenta y haz que la política de red coincida. Los equipos que cambian de modo durante la resolución de problemas suelen acabar con un conjunto de reglas de cortafuegos que no satisface a ninguno de los dos.

Desactivar el acceso público es un interruptor aparte

Si la cuenta debe ser solo privada, desactiva el acceso a la red pública mediante la configuración compatible de la cuenta y verifica el resultado. No trates la existencia de un punto de conexión privado como la decisión completa de acceso, porque una cuenta con un punto de conexión privado y acceso público activado sigue respondiendo en internet.

Verifícalo desde fuera de la VPN y también desde dentro. Una solicitud desde una red que debería estar excluida es la prueba que demuestra que la configuración surtió efecto, y es la prueba que la mayoría de las ventanas de cambio se saltan.

La accesibilidad no es permiso

Una operación SDK permitida desde el portátil de la VPN es la prueba de aceptación, con la URL normal de la cuenta y la identidad prevista. La accesibilidad por VPN no concede permisos de datos de Cosmos; el plano de datos comprueba sus propios roles o claves.

Luego ejecuta las denegaciones: una identidad distinta y una ruta de red que ya no debería alcanzar la cuenta. Si cualquiera de las dos tiene éxito, el límite que documentaste no es el límite que construiste.

Anota cuatro hechos al terminar: las direcciones privadas del punto de conexión, la zona DNS que responde por el nombre de la cuenta, el modo de conexión con sus requisitos de puertos y si el acceso público está desactivado. Esos cuatro explican la configuración a la siguiente persona, y cada uno falla de forma independiente.