Punct final privat, același nume de server: șiruri de conectare Azure SQL

Private Link schimbă locul unde ajunge o conexiune, nu modul în care este numită conexiunea. Pentru Azure SQL Database, această distincție este întregul design: serverul logic își păstrează numele, iar punctul final privat oferă o intrare de rețea către care se rezolvă numele. Înlocuirea numelui cu o adresă IP este singura schimbare care strică simultan TLS, acreditările și instrumentele. Două șiruri de conectare pot părea echivalente și se pot comporta complet diferit.

Păstrați orders-db.database.windows.net și oferiți clientului un răspuns privat pentru el.

Numele și adresa au sarcini diferite

Numele identifică serviciul SQL, iar certificatul și autentificarea se așteaptă exact la asta. Adresa privată oferă o intrare de rețea în interiorul rețelei virtuale conectate. Confundarea uneia cu cealaltă produce o conexiune care ajunge la ceva și nu se autentifică față de nimic.

Îndrumările Microsoft pentru Azure SQL cer numele normal de server de la clienți. Un IP direct, și la fel numele cu prefixul privatelink, nu este o țintă de autentificare interschimbabilă. Instrumentele care acceptă un IP îl vor accepta și apoi vor eșua la TLS sau la autentificare, ceea ce ascunde eroarea reală. Acele eșecuri se citesc ca probleme de acreditări până când te uiți la numele de gazdă din eroare.

Ce schimbă de fapt zona privată

Zona DNS privată înregistrează o adresă pentru server în spațiul de nume privatelink, iar zona este legată de rețeaua virtuală care ar trebui să o folosească. Rezolvarea se mută; șirul de conectare nu. Forma de mai jos este o ilustrație, nu o înregistrare de lipit într-o zonă publică.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Mențineți acea înregistrare și legătura ei de zonă ca infrastructură, cu un proprietar și o dată de revizuire.

Două zone cu aceeași origine și răspunsuri diferite sunt starea finală normală, nu un conflict. Clienții publici păstrează răspunsul public, iar clienții privați primesc adresa punctului final. Modul de eșec de urmărit este propagarea parțială a vederii private, unde o subrețea se rezolvă privat, iar alta, în tăcere, nu.

Clienții din afara Azure au nevoie de o cale în acea zonă

Un client VPN stă în afara resolverului Azure, așa că zona privată trebuie să fie accesibilă din calea hibridă. Un forwarder DNS Azure sau Azure DNS Private Resolver pot deservi interogările care sosesc prin acea rețea. Îndrumarea Microsoft este să redirecționați zona publică de serviciu relevantă prin această aranjare, în loc să presupuneți că clienții interoghează direct numele privatelink. Clienții care nu pot rezolva răspunsul privat revin la cel public fără să se plângă.

Păstrați scopul redirecționării intenționat, deoarece înlocuirea unei zone publice în uz strică nume pe care înlocuirea nu le conține.

Furnizați într-o ordine care menține identitatea fixă

Pașii au proprietari separați: creați și aprobați punctul final, furnizați ruta VPN, integrați DNS-ul privat, apoi configurați clientul cu numele său normal de server. A face DNS înainte de rută produce expirări de timp care arată ca eșecuri DNS. A face clientul ultimul menține o singură variabilă în mișcare odată. Fiecare pas are un rezultat observabil, așa că niciunul nu trebuie testat ghicind.

O pictogramă VPN conectată nu selectează singură o destinație privată.

Ce nu oprește un punct final privat

Crearea unui punct final privat nu dezactivează automat accesul public la serverul logic. Aceasta este o decizie separată de implementare și intervine după ce clienții privați prevăzuți sunt confirmați ca funcționali. Păstrați o cale de recuperare și țineți cont de aplicațiile care încă folosesc intrarea publică. Oprirea mai întâi a accesului public este modul în care un serviciu funcțional devine o întrerupere cu o urmă de audit ordonată.

Verificați și ce politică de conexiune folosește serverul.

Redirect trimite clientul la un port de pe nod după o conexiune inițială la gateway, ceea ce schimbă ce trebuie să permită rețeaua clientului. Proxy menține traficul pe gateway. O strângere de mână TCP reușită pe un port nu este întregul flux de autentificare.

Acesta este Azure SQL Database, nu SQL Managed Instance, care are propriul model de conectivitate și nicio poveste echivalentă de punct final privat. În ambele cazuri, păstrați trei lucruri etichetate separat: numele, intrarea de rețea și acreditarea. Schimbarea locului în care călătorește o conexiune nu ar trebui să schimbe niciodată cu ce serviciu crede clientul că vorbește.