VPN-ul tău nu face Cosmos DB privat de unul singur

Conectezi laptopul la VNet printr-un VPN, deschizi URL-ul contului Cosmos DB, iar cererea iese în continuare prin internetul public. Tunelul și-a făcut treaba. Ce nu a făcut a fost să creeze un punct final privat, să publice înregistrarea DNS privată sau să dezactiveze accesul public, pentru că acestea sunt trei modificări separate ale contului, nu proprietăți ale conexiunii tale de rețea. Acest exemplu folosește Azure Cosmos DB pentru NoSQL, un punct final privat într-un VNet și un laptop conectat la acel VNet prin VPN, și păstrează adresa aplicației neschimbată.

Mitul: prezența în VPN face baza de date privată

Prezența în VNet înseamnă doar că pachetele tale pot ajunge la adrese private din acel VNet. Nu spune nimic despre locul unde se rezolvă numele contului și nu spune nimic despre dacă contul mai acceptă trafic public.

Un punct final privat este o resursă separată cu adresa proprie, cu pasul propriu de aprobare și cu propria cablare DNS. Până când nu există și nu este aprobat, numele se rezolvă la punctul final public, iar traficul tău merge acolo indiferent de tunel.

Ce face de fapt ca numele să se rezolve privat

Păstrează punctul final obișnuit al contului din SDK, ceva de genul https://ACCOUNT.documents.azure.com. DNS-ul privat ar trebui să rezolve acel nume prin lanțul Private Link la adresele private ale punctului final. Nu îl înlocui cu un URL numeric și nu dezactiva verificările certificatelor, pentru că asta schimbă o problemă DNS cu o problemă de securitate.

Acele valori sunt specifice API-ului NoSQL. Celelalte API-uri Cosmos nu sunt intrări interschimbabile în același exemplu, iar copierea numelui subresursei dintr-un alt API produce un punct final care nu se rezolvă niciodată.

Creează și aprobă punctul final prin fluxul de lucru autorizat Azure, apoi folosește integrarea acestuia cu grupul de zone DNS private. Laptopul are nevoie de un resolver care poate răspunde pentru acea zonă, fie direct, fie printr-o redirecționare aprobată, și de o rută de client VPN către fiecare adresă relevantă a punctului final.

Un punct final privat poate avea mai mult de o adresă, inclusiv intrări globale și regionale. Menține integrarea DNS atunci când regiunile contului se schimbă, în loc să fixezi o singură adresă într-un fișier hosts, și ține minte că un răspuns de la un resolver public necorelat nu dovedește nimic despre calea privată. Dacă redirecționezi DNS printr-un hub, confirmă că redirectorul răspunde înainte de a depana clientul. Un redirector învechit returnează răspunsul public, care arată exact ca un punct final lipsă.

Modul Gateway și modul Direct nu sunt interschimbabile

Modul Gateway trimite cererile de serviciu prin HTTPS pe TCP 443. De aceea o politică de firewall doar pentru 443 funcționează cu el și de aceea acest exemplu îl alege în mod deliberat.

Modul Direct prin Private Link are cerințe de conectivitate diferite, inclusiv un interval de porturi TCP mai larg pe care documentația contului îl enumeră. O politică scrisă pentru modul Gateway nu trebuie reutilizată în tăcere pentru un client în modul Direct, altfel SDK-ul se conectează și apoi se blochează la prima operațiune de date.

Alege un singur mod, notează-l împreună cu contul și fă politica de rețea să corespundă. Echipele care schimbă modul în timpul depanării ajung de obicei cu un set de reguli de firewall care nu satisface niciunul dintre ele.

Dezactivarea accesului public este un comutator separat

Dacă contul trebuie să fie doar privat, dezactivează accesul la rețeaua publică prin setarea acceptată a contului și verifică rezultatul. Nu trata existența unui punct final privat ca decizia completă de acces, pentru că un cont cu punct final privat și acces public activat răspunde în continuare pe internet.

Verifică din afara VPN-ului, precum și din interior. O cerere dintr-o rețea care ar trebui exclusă este testul care dovedește că setarea a intrat în vigoare și este testul pe care majoritatea ferestrelor de modificare îl sar.

Accesibilitatea nu este permisiune

O operațiune SDK permisă de pe laptopul din VPN este testul de acceptare, folosind URL-ul normal al contului și identitatea prevăzută. Accesibilitatea prin VPN nu acordă permisiuni pentru datele Cosmos; planul de date își verifică propriile roluri sau chei.

Apoi rulează refuzurile: o identitate diferită și o cale de rețea care nu ar mai trebui să ajungă la cont. Dacă vreuna reușește, granița pe care ai documentat-o nu este granița pe care ai construit-o.

Notează patru fapte la final: adresele private ale punctului final, zona DNS care răspunde pentru numele contului, modul de conectare cu cerințele sale de porturi și dacă accesul public este dezactivat. Aceste patru explică configurarea următoarei persoane, iar fiecare eșuează independent.