Warum hat ein SQL Server-Client die Verbindung zu einem SQL Server abgebrochen, der auf einem anderen Knoten in meinem lokalen Netzwerk ausgeführt wird?
Dies funktioniert schon seit langem einwandfrei. Der Client-PC (PC A) hat sich vor zwei Tagen verbunden. Weder auf PC A noch auf dem PC, auf dem SQL Server gehostet wird (MYSERVER), wurde etwas geändert. Wenn ich versuche, eine Verbindung herzustellen, erhalte ich die Fehlermeldung „Beim Herstellen einer Verbindung zum SQL Server ist ein netzwerkbezogener Fehler aufgetreten. Der Server wurde nicht gefunden oder war nicht erreichbar.“ Ich kann von einem anderen PC, PC B, erfolgreich eine Verbindung zur gleichen SQL Server-Instanz herstellen.
Beide PCs verwenden dieselbe Verbindungszeichenfolge in einem C#-Programm, aber ich habe bestätigt, dass eine Verbindung von SQL Server Management Studio auf PC A ebenfalls fehlschlägt. Auch die Verbindung in SQL Server Management Studio funktioniert, wenn ich den Servernamen in die IP-Adresse des Serverknotens ändere, d. h. 192.168.178.20\SQLEXPRESS stellt eine Verbindung her, aber MYSERVER\SQLEXPRESS kann keine Verbindung herstellen. Es scheint, dass Windows oder SQL Client den Hostnamen nicht auflösen können (obwohl dies bis vor ein paar Tagen der Fall war).
Auf den beiden Client-PCs und dem Server-PC läuft Windows 10. Das lokale Netzwerk ist eine Arbeitsgruppe, keine Domäne. Die beiden Clients verwenden die Windows-Authentifizierung, um eine Verbindung zum Server herzustellen.
Auf PC A habe ich geprüft
die HOSTS-Datei enthält keine Adressen
Ich kann MYSERVER anpingen und es wird die richtige Adresse 192.168.178.20 angezeigt.
Es gibt keine SQL-Aliase
der PC verwendet den richtigen DNS-Server auf dem Router
Als Workaround habe ich MYSERVER in die Hosts-Datei aufgenommen und die IP-Adresse von MYSERVER in die statische Adresse 192.168.178.20 geändert, aber ich möchte dies nicht dauerhaft.
Irgendwelche Vorschläge, warum der Servername nicht aufgelöst wird oder was ich tun könnte, um dies weiter zu untersuchen?
Antwort1
Die Antwort darauf war einfach. Ich habe meinen Router neu gestartet.
Ich habe dies behoben mit Hilfe vonWireshark. Ich habe die Pakete zwischen dem Client-PC und dem Server verglichen, sowohl wenn die Adresse des Servers in der Windows-HOSTS-Datei des Clients stand (wenn die Verbindung zum SQL Server immer funktionierte) als auch wenn die HOSTS-Datei leer war (wenn der Client-PC nie eine Verbindung herstellte). In beiden Fällen konnte ich sehen, dass TCP-Pakete ausgetauscht wurden, aber mit der Serveradresse in der Hosts-Datei gab es auch TLS-Pakete für die verschlüsselte Verbindung. Im anderen Fall schien der Client die Verbindungsanforderung an den Server zu senden, aber es gab keine TLS-verschlüsselten Daten.
Möglicherweise gab es ein DNS-Problem im Router. Ein Ping vom Client zum Server funktionierte, aber es gab eine leichte Verzögerung. Obwohl der Client die Serveradresse vom Router auflösen konnte, um die TCP-Pakete erfolgreich zu senden, glaube ich, dass es beim Versuch, die Windows-Authentifizierung durchzuführen, zu einer Verzögerung gekommen sein könnte, und dass dies dazu führte, dass der Client die Authentifizierungsanforderung nicht korrekt senden konnte.
Wie dem auch sei, durch einen Neustart des Routers wurde das vorhandene DNS-Problem behoben und der Client stellt jetzt eine Verbindung her, ohne dass die Adresse des Servers in der Windows-HOSTS-Datei erforderlich ist.