SQL Server bindet eine VPN-Adresse, die beim Start nicht vorhanden ist

Lesen Sie eine SQL-Server-Protokollzeile über eine fehlgeschlagene Bindung, während der Dienst noch läuft, und Sie haben eine Abhängigkeit von der Startreihenfolge gefunden, keinen Absturz. Diese Kombination ist der Hinweis: Die Engine startete, bevor die Adresse, auf der sie lauschen sollte, auf dem Rechner existierte. Ein VPN-Adapter, der erst nach der Anmeldung erscheint, ist eine schlechte Voraussetzung für einen unbeaufsichtigten Datenbankdienst, also gehen Sie den Fehler in der Reihenfolge durch, in der die Engine ihn sieht.

Beginnen Sie beim Startprotokoll, nicht beim Client

Öffnen Sie das Fehlerprotokoll der Instanz und lesen Sie die Einträge rund um die Netzwerkinitialisierung, nicht nur die letzte Zeile. Die Engine meldet, welche Adressen sie versucht und welche Protokolle sie aktiviert hat, und diese Aufzeichnung stammt von vor jeder Clientverbindung. Sehen Sie sich nun an, was auf dem Host gerade existiert. Wenn die Schnittstelle, die die konfigurierte Adresse besitzt, erst erscheint, nachdem sich ein Benutzer anmeldet und einen Client startet, fehlte die Adresse beim Start, und der Bindungsfehler ist vollständig erklärt.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Passen Sie den Pfad der Instanz an Ihre Installation an und lesen Sie die Schnittstellenliste, bevor Sie Schlüsse ziehen. Eine Adresse, die existiert, aber dem falschen Adapter gehört, ist ein anderes Problem als eine Adresse, die noch nicht existiert.

Gehen Sie die Bindungsreihenfolge durch, die die Engine tatsächlich befolgt

Die Engine liest ihre Listener-Konfiguration und bittet dann das Betriebssystem zu binden. Ist die Adresse in diesem Moment nicht lokal, schlägt die Bindung für diese Adresse fehl, während der Rest der Instanz normal weiterlaufen kann. Deshalb können andere Protokolle oder andere Adressen weiterhin funktionieren, und deshalb ist „SQL Server ist ausgefallen“ die falsche Zusammenfassung. Bewahren Sie den genauen Endpunkt aus dem Protokoll auf: Adresse, Port und Protokoll, denn die Korrektur hängt davon ab, welcher der drei falsch ist.

Ein Neustart des Dienstes, nachdem der Adapter erscheint, lässt den Listener meist erfolgreich sein, und genau das ist die Falle. Er beweist die Abhängigkeit, statt sie zu beseitigen, und er unterbricht jeden verbundenen Benutzer jedes Mal, wenn der Tunnel sich neu verbindet.

Lesen Sie den Listener so, wie die Engine ihn liest

Öffnen Sie im SQL Server Configuration Manager die TCP/IP-Eigenschaften der Instanz und beachten Sie die Einstellung Listen All, bevor Sie einzelne Adressen bearbeiten. Ist Listen All auf Yes gesetzt, werden die Enabled-Werte pro Adresse ignoriert, sodass deren Bearbeitung nichts ändert, was der Listener verwendet. Notieren Sie drei Dinge der Reihe nach: die Adresse, die Sie bedienen wollen, den Port und ob der Listener alle Adressen oder nur eine abdecken soll. Wenden Sie die Änderung dann über das unterstützte Neustartverfahren an und lesen Sie das nächste Startprotokoll, um zu bestätigen, dass die Engine gebunden hat, was Sie verlangt haben.

Auf jeder Adresse zu lauschen ist keine Zugriffskontrolle. Wenn ein breiter Listener wirklich erforderlich ist, braucht jede erreichbare Schnittstelle ihre eigene Firewall- und Datenbankautorisierungsentscheidung, einschließlich jeder Schnittstelle, die ins Internet zeigt.

Geben Sie dem Client ein stabiles Ziel

Der Client braucht nicht, dass der Datenbankhost eine Pooladresse trägt. Ein geroutetes Design funktioniert, indem der Server auf seiner stabilen privaten Adresse lauscht, während das VPN-Gateway den Datenverkehr des Clients dorthin weiterleitet und die Antwort zurückbringt.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

Erreicht der Client 10.80.0.15, ist der Pfad bewiesen und die Datenbank muss nur diesen Client autorisieren. Wenn nicht, korrigieren Sie Routing und DNS, bevor Sie den Listener erneut anfassen, denn ein Bindungsproblem auf dem Server war nie der Grund, warum ein Client ihn nicht findet. Eine falsche Pooladresse zum Server hinzuzufügen oder ein zweites Standardgateway, um den Listener zufriedenzustellen, erzeugt ein neues Netzwerkproblem obendrauf. Halten Sie die Adressierung des Servers statisch und lassen Sie den Tunnel die Clients zu ihm bringen.

Überprüfen Sie den Endpunkt, den der Client verwendet hat

Schließen Sie mit einer Prüfung auf Anwendungsebene ab, nicht mit einem Porttest. Verbinden Sie sich vom Client mit dem Konto, das die Anwendung verwendet, und lesen Sie die Verbindungsdetails auf Serverseite, die die lokale Adresse zeigen, auf der Ihre Sitzung gelandet ist.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Vergleichen Sie diese Adresse mit dem Listener, den Sie konfiguriert haben. Eine Abweichung bedeutet einen zweiten Listener oder einen Namen, der irgendwo unerwartet aufgelöst wird, und beides ist es wert, vor dem nächsten Neustart zu wissen, der Ihre Korrektur für Sie testet. Starten Sie dann den Host ohne angemeldeten Benutzer neu und bestätigen Sie, dass die Bindung gelingt. Dieser eine Test ist der Unterschied zwischen einem reparierten Listener und einem Workaround, der in der nächsten Patchnacht scheitert.