Din VPN gör inte Cosmos DB privat av sig själv

Du ansluter den bärbara datorn till VNet via en VPN, öppnar URL:en för Cosmos DB-kontot, och begäran lämnar fortfarande över det offentliga internet. Tunneln gjorde sitt jobb. Det den inte gjorde var att skapa en privat slutpunkt, publicera den privata DNS-posten eller stänga av offentlig åtkomst, eftersom det är tre separata ändringar av kontot och inte egenskaper hos din nätverksanslutning. Det här exemplet använder Azure Cosmos DB för NoSQL, en privat slutpunkt i ett VNet och en bärbar dator ansluten till det VNet:et via VPN, och det håller programmets adress oförändrad.

Myten: att vara på VPN gör databasen privat

Att vara på VNet betyder bara att dina paket kan nå privata adresser i det VNet:et. Det säger ingenting om var kontonamnet löses upp, och det säger ingenting om kontot fortfarande tar emot offentlig trafik.

En privat slutpunkt är en separat resurs med sin egen adress, sitt eget godkännandesteg och sin egen DNS-kabling. Tills den finns och är godkänd löses namnet upp till den offentliga slutpunkten och din trafik går dit oavsett tunneln.

Vad som faktiskt får namnet att lösas upp privat

Behåll SDK:ns vanliga konto-slutpunkt, något som https://ACCOUNT.documents.azure.com. Privat DNS bör lösa upp det namnet genom Private Link-kedjan till slutpunktens privata adresser. Ersätt den inte med en numerisk URL och stäng inte av certifikatkontrollerna, eftersom det byter ett DNS-problem mot ett säkerhetsproblem.

Dessa värden är specifika för NoSQL-API:et. Andra Cosmos-API:er är inte utbytbara poster i samma exempel, och att kopiera underresursnamnet från ett annat API ger en slutpunkt som aldrig löses upp.

Skapa och godkänn slutpunkten genom det auktoriserade Azure-arbetsflödet och använd sedan dess integrering med privata DNS-zongrupper. Den bärbara datorn behöver en resolver som kan svara för den zonen, antingen direkt eller via godkänd vidarebefordran, och en VPN-klientrutt till varje relevant slutpunktsadress.

En privat slutpunkt kan ha mer än en adress, inklusive globala och regionala poster. Underhåll DNS-integreringen när kontots regioner ändras i stället för att fästa en enda adress i en hosts-fil, och kom ihåg att ett svar från en orelaterad offentlig resolver inte bevisar något om den privata vägen. Om du vidarebefordrar DNS via ett nav bekräftar du att vidarebefordraren svarar innan du felsöker klienten. En inaktuell vidarebefordrare returnerar det offentliga svaret, vilket ser exakt ut som en saknad slutpunkt.

Gateway-läge och Direct-läge är inte utbytbara

Gateway-läget skickar tjänsteförfrågningar över HTTPS på TCP 443. Det är därför en brandväggsprincip bara för 443 fungerar med det och därför väljer det här exemplet det medvetet.

Direct-läget över Private Link har andra anslutningskrav, inklusive ett bredare TCP-portintervall som kontodokumentationen listar. En princip skriven för Gateway-läget får inte tyst återanvändas för en Direct-lägesklient, annars ansluter SDK:n och hänger sig sedan vid den första dataoperationen.

Välj ett läge, skriv ner det tillsammans med kontot och få nätverksprincipen att matcha. Team som byter läge under felsökning slutar vanligtvis med en brandväggsregeluppsättning som inte uppfyller något av dem.

Att stänga av offentlig åtkomst är en separat brytare

Om kontot ska vara bara privat stänger du av offentlig nätverksåtkomst via kontots stödda inställning och verifierar resultatet. Behandla inte förekomsten av en privat slutpunkt som det fullständiga åtkomstbeslutet, eftersom ett konto med en privat slutpunkt och offentlig åtkomst aktiverad fortfarande svarar på internet.

Verifiera från utsidan av VPN:en såväl som från insidan. En begäran från ett nätverk som borde uteslutas är testet som bevisar att inställningen trädde i kraft, och det är testet som de flesta ändringsfönster hoppar över.

Nåbarhet är inte tillstånd

En tillåten SDK-operation från VPN-datorn är acceptanstestet, med kontots vanliga URL och den avsedda identiteten. VPN-nåbarhet ger inte Cosmos-datatillstånd; dataplanet kontrollerar sina egna roller eller nycklar.

Kör sedan avvisningarna: en annan identitet och en nätverksväg som inte längre ska nå kontot. Om någon av dem lyckas är gränsen du dokumenterade inte gränsen du byggde.

Skriv ner fyra fakta när du är klar: slutpunktens privata adresser, DNS-zonen som svarar för kontonamnet, anslutningsläget med dess portkrav och om offentlig åtkomst är avstängd. De fyra förklarar uppsättningen för nästa person, och var och en av dem misslyckas oberoende.