A túa VPN non fai privado Cosmos DB por si soa

Conectas o portátil á VNet mediante unha VPN, abres o URL da conta de Cosmos DB e a solicitude segue saíndo pola internet pública. O túnel fixo o seu traballo. O que non fixo foi crear un punto de conexión privado, publicar o rexistro DNS privado ou desactivar o acceso público, porque son tres cambios separados na conta e non propiedades da túa conexión de rede. Este exemplo usa Azure Cosmos DB para NoSQL, un punto de conexión privado nunha VNet e un portátil conectado a esa VNet por VPN, e mantén o enderezo da aplicación sen cambios.

O mito: estar na VPN fai privada a base de datos

Estar na VNet só significa que os teus paquetes poden alcanzar enderezos privados nesa VNet. Non di nada sobre onde se resolve o nome da conta, nin di nada sobre se a conta segue aceptando tráfico público.

Un punto de conexión privado é un recurso aparte co seu propio enderezo, o seu propio paso de aprobación e a súa propia cableaxe DNS. Ata que exista e se aprobe, o nome resólvese ao punto de conexión público e o teu tráfico vai alí independentemente do túnel.

Que fai que o nome se resolva de forma privada

Mantén o punto de conexión normal da conta do SDK, algo como https://ACCOUNT.documents.azure.com. O DNS privado debería resolver ese nome a través da cadea de Private Link ata os enderezos privados do punto de conexión. Non o substitúas por un URL numérico nin desactives as comprobacións de certificados, porque iso cambia un problema de DNS por un problema de seguridade.

Eses valores son específicos da API NoSQL. As demais API de Cosmos non son entradas intercambiables no mesmo exemplo, e copiar o nome do subrecurso doutra API produce un punto de conexión que nunca se resolve.

Crea e aproba o punto de conexión mediante o fluxo de traballo autorizado de Azure e despois usa a súa integración co grupo de zonas DNS privadas. O portátil necesita un resolvedor que poida responder por esa zona, xa sexa directamente ou mediante un reenvío aprobado, e unha ruta de cliente VPN a cada enderezo relevante do punto de conexión.

Un punto de conexión privado pode ter máis dun enderezo, incluíndo entradas globais e rexionais. Mantén a integración DNS cando cambien as rexións da conta en lugar de fixar un único enderezo nun ficheiro hosts, e lembra que unha resposta dun resolvedor público non relacionado non demostra nada sobre a ruta privada. Se reenvías DNS a través dun concentrador, confirma que o reenviador responde antes de depurar o cliente. Un reenviador obsoleto devolve a resposta pública, que se ve exactamente como un punto de conexión ausente.

O modo Gateway e o modo Direct non son intercambiables

O modo Gateway envía as solicitudes do servizo por HTTPS sobre TCP 443. Por iso unha política de cortafuegos só para o 443 funciona con el e por iso este exemplo o escolle deliberadamente.

O modo Direct sobre Private Link ten requisitos de conectividade distintos, incluído un rango de portos TCP máis amplo que enumera a documentación da conta. Unha política escrita para o modo Gateway non debe reutilizarse en silencio para un cliente en modo Direct, ou o SDK conectarase e despois colgarase na primeira operación de datos.

Escolle un modo, anótao coa conta e fai que a política de rede coincida. Os equipos que cambian de modo durante a resolución de problemas adoitan acabar cun conxunto de regras de cortafuegos que non satisfai ningún dos dous.

Desactivar o acceso público é un interruptor aparte

Se a conta debe ser só privada, desactiva o acceso á rede pública mediante a configuración compatible da conta e verifica o resultado. Non trates a existencia dun punto de conexión privado como a decisión completa de acceso, porque unha conta cun punto de conexión privado e acceso público activado segue respondendo en internet.

Verifícao desde fóra da VPN e tamén desde dentro. Unha solicitude desde unha rede que debería estar excluída é a proba que demostra que a configuración surtiu efecto, e é a proba que a maioría das ventás de cambio se saltan.

A accesibilidade non é permiso

Unha operación SDK permitida desde o portátil da VPN é a proba de aceptación, co URL normal da conta e a identidade prevista. A accesibilidade por VPN non concede permisos de datos de Cosmos; o plano de datos comproba os seus propios roles ou chaves.

Despois executa as denegacións: unha identidade distinta e unha ruta de rede que xa non debería alcanzar a conta. Se calquera das dúas ten éxito, o límite que documentaches non é o límite que construíches.

Anota catro feitos ao rematar: os enderezos privados do punto de conexión, a zona DNS que responde polo nome da conta, o modo de conexión cos seus requisitos de portos e se o acceso público está desactivado. Eses catro explican a configuración á persoa seguinte, e cada un falla de forma independente.