Privata finpunkto, sama servilnomo: Azure SQL-konektaj ĉenoj

Private Link ŝanĝas, kie konekto alvenas, ne kiel la konekto nomiĝas. Por Azure SQL Database tiu distingo estas la tuta dezajno: la logika servilo konservas sian nomon, kaj la privata finpunkto provizas retan enskribon, al kiu la nomo solviĝas. Anstataŭigi la nomon per IP-adreso estas la sola ŝanĝo, kiu rompas samtempe TLS, akreditaĵojn kaj ilojn. Du konektaj ĉenoj povas aspekti ekvivalentaj kaj konduti tute malsame.

Konservu orders-db.database.windows.net kaj donu al la kliento privatan respondon por ĝi.

La nomo kaj la adreso havas malsamajn taskojn

La nomo identigas la SQL-servon, kaj tion atendas la atestilo kaj la saluto. La privata adreso provizas retan enskribon ene de la konektita virtuala reto. Konfuzi unu kun la alia produktas konekton, kiu atingas ion kaj aŭtentikigas kontraŭ nenio.

La gvidado de Microsoft por Azure SQL postulas la normalan servilnomon de klientoj. Rekta IP, same kiel la nomo kun la prefikso privatelink, ne estas interŝanĝebla salutcelo. Iloj, kiuj akceptas IP, akceptos ĝin kaj poste malsukcesos ĉe TLS aŭ ĉe aŭtentikigo, kio kaŝas la veran eraron. Tiuj malsukcesoj legeblas kiel akreditaĵaj problemoj ĝis vi rigardas la gastigantnomon en la eraro.

Kion la privata zono efektive ŝanĝas

La privata DNS-zono registras unu adreson por la servilo ene de la nomspaco privatelink, kaj la zono ligiĝas al la virtuala reto, kiu devus uzi ĝin. La solvado moviĝas; la konekta ĉeno ne. La formo sube estas ilustraĵo, ne rikordo por alglui en publikan zonon.

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

Prizorgu tiun rikordon kaj ĝian zonligon kiel infrastrukturon, kun posedanto kaj reviziodato.

Du zonoj kun la sama origino kaj malsamaj respondoj estas la normala fina stato, ne konflikto. Publikaj klientoj konservas la publikan respondon, kaj privataj klientoj ricevas la adreson de la finpunkto. La fiaska reĝimo, kiun oni atentu, estas parte disvastiĝinta privata vido, kie unu subreto solviĝas private kaj alia silente ne.

Klientoj ekster Azure bezonas vojon en tiun zonon

VPN-kliento sidas ekster la solvilo de Azure, do la privata zono devas esti atingebla el la hibrida vojo. Azure DNS-plusendilo aŭ Azure DNS Private Resolver povas servi demandojn alvenantajn tra tiu reto. La gvidado de Microsoft estas plusendi la koncernan publikan servozonon tra tiu aranĝo anstataŭ supozi, ke klientoj demandas la nomon privatelink rekte. Klientoj, kiuj ne povas solvi la privatan respondon, silente falas reen al la publika.

Tenu la plusendan amplekson intenca, ĉar anstataŭigi publikan zonon en uzo rompas nomojn, kiujn la anstataŭo ne enhavas.

Provizu laŭ ordo, kiu tenas la identecon fiksa

La paŝoj havas apartajn posedantojn: kreu kaj aprobu la finpunkton, provizu la VPN-vojon, integru la privatan DNS, poste agordu la klienton kun ĝia normala servilnomo. Fari DNS antaŭ la vojo produktas tempolimojn, kiuj aspektas kiel DNS-fiaskoj. Fari la klienton laste tenas unu variablon moviĝanta samtempe. Ĉiu paŝo havas observeblan rezulton, do neniu devas esti testita per divenado.

Konektita VPN-ikono ne elektas privatan celon per si mem.

Kion privata finpunkto ne malŝaltas

Krei privatan finpunkton ne aŭtomate malŝaltas publikan aliron al la logika servilo. Tio estas aparta deplojdecido, kaj ĝi apartenas post kiam la celitaj privataj klientoj konfirmiĝis funkciantaj. Konservu restarigan vojon kaj konsideru aplikaĵojn, kiuj ankoraŭ uzas la publikan eniron. Malŝalti publikan aliron unue estas la maniero, kiel funkcianta servo fariĝas paneo kun ordigita revizia spuro.

Kontrolu ankaŭ, kiun konektan politikon la servilo uzas.

Redirect sendas la klienton al pordo sur la nodo post komenca pordega konekto, kio ŝanĝas, kion la klienta reto devas permesi. Proxy tenas trafikon sur la pordego. Sukcesa TCP-manpremo sur unu pordo ne estas la tuta salutfluo.

Ĉi tio estas Azure SQL Database, ne SQL Managed Instance, kiu havas sian propran konekteblec-modelon kaj neniun ekvivalentan rakonton pri privata finpunkto. En ambaŭ kazoj, tenu tri aferojn aparte etikeditaj: la nomon, la retan enskribon kaj la akreditaĵon. Ŝanĝi, kien konekto vojaĝas, neniam devus ŝanĝi, kun kiu servo la kliento opinias, ke ĝi parolas.