Private Endpoint, gleicher Servername: Azure SQL-Verbindungszeichenfolgen

Private Link ändert, wo eine Verbindung ankommt, nicht wie die Verbindung heißt. Bei Azure SQL Database ist dieser Unterschied das ganze Design: Der logische Server behält seinen Namen, und der private Endpoint liefert einen Netzwerkeintrag, auf den der Name aufgelöst wird. Den Namen durch eine IP-Adresse zu ersetzen ist die eine Änderung, die TLS, Anmeldeinformationen und Werkzeuge gleichzeitig bricht. Zwei Verbindungszeichenfolgen können gleich aussehen und sich völlig unterschiedlich verhalten.

Behalten Sie orders-db.database.windows.net und geben Sie dem Client eine private Antwort darauf.

Der Name und die Adresse haben unterschiedliche Aufgaben

Der Name identifiziert den SQL-Dienst, und genau das erwarten das Zertifikat und die Anmeldung. Die private Adresse liefert einen Netzwerkeintrag innerhalb des verbundenen virtuellen Netzwerks. Verwechselt man beides, entsteht eine Verbindung, die etwas erreicht und sich gegen nichts authentifiziert.

Die Microsoft-Empfehlung für Azure SQL verlangt den normalen Servernamen von den Clients. Eine direkte IP und ebenso der Name mit dem Präfix privatelink ist kein austauschbares Anmeldeziel. Werkzeuge, die eine IP annehmen, nehmen sie an und scheitern dann bei TLS oder bei der Authentifizierung, was den eigentlichen Fehler verbirgt. Diese Fehler lesen sich wie Anmeldeinformationsprobleme, bis man den Hostnamen in der Fehlermeldung ansieht.

Was die private Zone tatsächlich ändert

Die private DNS-Zone zeichnet eine Adresse für den Server im Namespace privatelink auf, und die Zone ist mit dem virtuellen Netzwerk verknüpft, das sie nutzen soll. Die Auflösung verschiebt sich; die Verbindungszeichenfolge nicht. Die Form unten ist eine Veranschaulichung, kein Eintrag zum Einfügen in eine öffentliche Zone.

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

Pflegen Sie diesen Eintrag und seine Zonenverknüpfung als Infrastruktur, mit einem Verantwortlichen und einem Überprüfungsdatum.

Zwei Zonen mit demselben Ursprung und unterschiedlichen Antworten sind der normale Endzustand, kein Konflikt. Öffentliche Clients behalten die öffentliche Antwort, und private Clients erhalten die Endpoint-Adresse. Der Fehlermodus, auf den man achten sollte, ist die teilweise Verbreitung der privaten Sicht, bei der ein Subnetz privat auflöst und ein anderes stillschweigend nicht.

Clients außerhalb von Azure brauchen einen Weg in diese Zone

Ein VPN-Client sitzt außerhalb des Azure-Resolvers, also muss die private Zone über den hybriden Pfad erreichbar sein. Ein Azure DNS-Forwarder oder Azure DNS Private Resolver kann Abfragen bedienen, die über dieses Netzwerk eintreffen. Die Microsoft-Empfehlung lautet, die betreffende öffentliche Dienstzone über diese Anordnung weiterzuleiten, statt anzunehmen, dass Clients den Namen privatelink direkt abfragen. Clients, die die private Antwort nicht auflösen können, fallen ohne Beschwerde auf die öffentliche zurück.

Halten Sie den Weiterleitungsumfang bewusst, denn das Ersetzen einer genutzten öffentlichen Zone bricht Namen, die die Ersetzung nicht enthält.

Stellen Sie in einer Reihenfolge bereit, die die Identität festhält

Die Schritte haben getrennte Verantwortliche: den Endpoint erstellen und genehmigen, die VPN-Route bereitstellen, privates DNS integrieren und dann den Client mit seinem normalen Servernamen konfigurieren. DNS vor der Route zu erledigen erzeugt Zeitüberschreitungen, die wie DNS-Fehler aussehen. Den Client zuletzt zu machen hält jeweils eine Variable in Bewegung. Jeder Schritt hat ein beobachtbares Ergebnis, sodass keiner durch Raten geprüft werden muss.

Ein verbundenes VPN-Symbol wählt nicht von selbst ein privates Ziel.

Was ein privater Endpoint nicht abschaltet

Das Erstellen eines privaten Endpoints deaktiviert nicht automatisch den öffentlichen Zugriff auf den logischen Server. Das ist eine separate Bereitstellungsentscheidung und gehört dorthin, nachdem die vorgesehenen privaten Clients als funktionierend bestätigt wurden. Behalten Sie einen Wiederherstellungspfad und berücksichtigen Sie Anwendungen, die noch den öffentlichen Einstieg nutzen. Den öffentlichen Zugriff zuerst abzuschalten ist der Weg, auf dem ein funktionierender Dienst zu einem Ausfall mit sauberem Prüfpfad wird.

Prüfen Sie auch, welche Verbindungsrichtlinie der Server verwendet.

Redirect schickt den Client nach einer anfänglichen Gateway-Verbindung an einen Port auf dem Knoten, was ändert, was das Clientnetzwerk zulassen muss. Proxy hält den Datenverkehr am Gateway. Ein erfolgreicher TCP-Handshake auf einem Port ist nicht der ganze Anmeldeablauf.

Dies ist Azure SQL Database, nicht SQL Managed Instance, die ihr eigenes Konnektivitätsmodell und keine vergleichbare Geschichte privater Endpoints hat. Behalten Sie in beiden Fällen drei Dinge getrennt benannt: den Namen, den Netzwerkeintrag und die Anmeldeinformation. Zu ändern, wohin eine Verbindung reist, sollte nie ändern, mit welchem Dienst der Client zu sprechen glaubt.