Din VPN gør ikke Cosmos DB privat af sig selv

Du forbinder den bærbare computer til VNet'et via en VPN, åbner Cosmos DB-kontoens URL, og anmodningen forlader stadig over det offentlige internet. Tunnelen gjorde sit arbejde. Det, den ikke gjorde, var at oprette et privat endepunkt, offentliggøre den private DNS-post eller slå offentlig adgang fra, fordi det er tre separate ændringer af kontoen og ikke egenskaber ved din netværksforbindelse. Dette eksempel bruger Azure Cosmos DB til NoSQL, et privat endepunkt i et VNet og en bærbar computer forbundet til det VNet via VPN, og det holder applikationens adresse uændret.

Myten: at være på VPN'en gør databasen privat

At være på VNet'et betyder kun, at dine pakker kan nå private adresser i det VNet. Det siger intet om, hvor kontoens navn opløses, og det siger intet om, hvorvidt kontoen stadig accepterer offentlig trafik.

Et privat endepunkt er en separat ressource med sin egen adresse, sit eget godkendelsestrin og sin egen DNS-kabling. Indtil det findes og er godkendt, opløses navnet til det offentlige endepunkt, og din trafik går derhen uanset tunnelen.

Hvad der faktisk får navnet til at opløses privat

Behold SDK'ets normale kontoendepunkt, noget som https://ACCOUNT.documents.azure.com. Privat DNS bør opløse det navn gennem Private Link-kæden til endepunktets private adresser. Erstat det ikke med en numerisk URL, og slå ikke certifikatkontroller fra, fordi det bytter et DNS-problem for et sikkerhedsproblem.

Disse værdier er specifikke for NoSQL-API'en. Andre Cosmos-API'er er ikke udskiftelige poster i samme eksempel, og kopiering af underressourcenavnet fra en anden API giver et endepunkt, der aldrig opløses.

Opret og godkend endepunktet gennem det autoriserede Azure-arbejdsflow, og brug derefter dets integration med private DNS-zonegrupper. Den bærbare computer har brug for en resolver, der kan svare for den zone, enten direkte eller gennem godkendt videresendelse, og en VPN-klientrute til hver relevant endepunktsadresse.

Et privat endepunkt kan have mere end én adresse, herunder globale og regionale poster. Vedligehold DNS-integrationen, når kontoens regioner ændres, i stedet for at fastgøre en enkelt adresse i en hosts-fil, og husk, at et svar fra en urelateret offentlig resolver ikke beviser noget om den private vej. Hvis du videresender DNS gennem et hub, skal du bekræfte, at videresenderen svarer, før du fejlretter klienten. En forældet videresender returnerer det offentlige svar, hvilket ser præcis ud som et manglende endepunkt.

Gateway-tilstand og Direct-tilstand kan ikke udskiftes

Gateway-tilstand sender serviceanmodninger over HTTPS på TCP 443. Det er derfor, en firewallpolitik kun for 443 virker til den, og derfor vælger dette eksempel den bevidst.

Direct-tilstand over Private Link har andre forbindelseskrav, herunder et bredere TCP-portområde, som kontoens dokumentation angiver. En politik skrevet til Gateway-tilstand må ikke lydløst genbruges til en Direct-tilstandsklient, ellers forbinder SDK'en og hænger derefter på den første dataoperation.

Vælg én tilstand, skriv den ned sammen med kontoen, og få netværkspolitikken til at matche den. Teams, der skifter tilstand under fejlfinding, ender normalt med et regelsæt til firewalling, der ikke opfylder nogen af dem.

At slå offentlig adgang fra er en separat kontakt

Hvis kontoen skal være kun privat, skal du slå offentlig netværksadgang fra via kontoens understøttede indstilling og bekræfte resultatet. Behandl ikke eksistensen af et privat endepunkt som den fulde adgangsbeslutning, fordi en konto med et privat endepunkt og offentlig adgang aktiveret stadig svarer på internettet.

Bekræft udefra VPN'en såvel som indefra. En anmodning fra et netværk, der bør udelukkes, er den test, der beviser, at indstillingen trådte i kraft, og det er den test, de fleste ændringsvinduer springer over.

Tilgængelighed er ikke tilladelse

En tilladt SDK-operation fra VPN-computeren er accepttesten med kontoens normale URL og den tilsigtede identitet. VPN-tilgængelighed giver ikke Cosmos-datatilladelser; dataplanet kontrollerer sine egne roller eller nøgler.

Kør derefter afvisningerne: en anden identitet og en netværksvej, der ikke længere bør nå kontoen. Hvis en af dem lykkes, er den grænse, du dokumenterede, ikke den grænse, du byggede.

Skriv fire fakta ned, når du er færdig: endepunktets private adresser, den DNS-zone, der svarer for kontoens navn, forbindelsestilstanden med dens portkrav, og om offentlig adgang er slået fra. De fire forklarer opsætningen for den næste person, og hver af dem fejler uafhængigt.