Endpoint privato, stesso nome del server: stringhe di connessione Azure SQL

Private Link cambia dove arriva una connessione, non il nome della connessione. Per Azure SQL Database questa distinzione è tutto il progetto: il server logico mantiene il suo nome, e l’endpoint privato fornisce una voce di rete a cui il nome si risolve. Sostituire il nome con un indirizzo IP è l’unica modifica che rompe TLS, credenziali e strumenti allo stesso tempo. Due stringhe di connessione possono sembrare equivalenti e comportarsi in modo del tutto diverso.

Mantieni orders-db.database.windows.net e fornisci al client una risposta privata per esso.

Il nome e l’indirizzo hanno compiti diversi

Il nome identifica il servizio SQL, ed è ciò che il certificato e l’accesso si aspettano. L’indirizzo privato fornisce una voce di rete all’interno della rete virtuale connessa. Confondere l’uno con l’altro produce una connessione che raggiunge qualcosa e non si autentica contro nulla.

Le indicazioni Microsoft per Azure SQL richiedono il nome server normale dai client. Un IP diretto, e allo stesso modo il nome con il prefisso privatelink, non è una destinazione di accesso intercambiabile. Gli strumenti che accettano un IP lo accettano e poi falliscono su TLS o sull’autenticazione, il che nasconde l’errore reale. Quei fallimenti si leggono come problemi di credenziali finché non si guarda il nome host nell’errore.

Cosa cambia davvero la zona privata

La zona DNS privata registra un indirizzo per il server nello spazio dei nomi privatelink, e la zona è collegata alla rete virtuale che dovrebbe usarla. La risoluzione si sposta; la stringa di connessione no. La forma sotto è un’illustrazione, non un record da incollare in una zona pubblica.

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

Mantieni quel record e il suo collegamento di zona come infrastruttura, con un proprietario e una data di revisione.

Due zone con la stessa origine e risposte diverse sono lo stato finale normale, non un conflitto. I client pubblici mantengono la risposta pubblica, e i client privati ottengono l’indirizzo dell’endpoint. Il modo di guasto da sorvegliare è la propagazione parziale della vista privata, in cui una sottorete si risolve privatamente e un’altra, silenziosamente, no.

I client fuori da Azure hanno bisogno di un percorso verso quella zona

Un client VPN si trova fuori dal resolver di Azure, quindi la zona privata deve essere raggiungibile dal percorso ibrido. Un forwarder DNS di Azure o Azure DNS Private Resolver possono servire le query che arrivano attraverso quella rete. L’indicazione Microsoft è di inoltrare la zona di servizio pubblico pertinente tramite questa disposizione invece di presumere che i client interroghino direttamente il nome privatelink. I client che non riescono a risolvere la risposta privata ricadono su quella pubblica senza lamentarsi.

Mantieni intenzionale l’ambito dell’inoltro, perché sostituire una zona pubblica in uso rompe nomi che la sostituzione non contiene.

Esegui il provisioning in un ordine che mantiene fissa l’identità

I passaggi hanno proprietari separati: crea e approva l’endpoint, fornisci la rotta VPN, integra il DNS privato, poi configura il client con il suo normale nome server. Fare il DNS prima della rotta produce timeout che sembrano guasti DNS. Fare il client per ultimo mantiene una variabile in movimento alla volta. Ogni passaggio ha un risultato osservabile, quindi nessuno deve essere testato tirando a indovinare.

Un’icona VPN connessa non seleziona da sola una destinazione privata.

Cosa non disattiva un endpoint privato

Creare un endpoint privato non disattiva automaticamente l’accesso pubblico al server logico. È una decisione di distribuzione separata, e arriva dopo che i client privati previsti sono stati confermati funzionanti. Mantieni un percorso di ripristino e considera le applicazioni che usano ancora l’ingresso pubblico. Disattivare per primo l’accesso pubblico è il modo in cui un servizio funzionante diventa un’interruzione con una traccia di controllo ordinata.

Controlla anche quale criterio di connessione usa il server.

Redirect invia il client a una porta sul nodo dopo una connessione iniziale al gateway, il che cambia ciò che la rete client deve consentire. Proxy mantiene il traffico sul gateway. Una stretta di mano TCP riuscita su una porta non è l’intero flusso di accesso.

Questo è Azure SQL Database, non SQL Managed Instance, che ha il proprio modello di connettività e nessuna storia equivalente di endpoint privato. In entrambi i casi, mantieni tre cose etichettate separatamente: il nome, la voce di rete e la credenziale. Cambiare dove viaggia una connessione non dovrebbe mai cambiare a quale servizio il client crede di parlare.