Benannte SQL-Server-Instanz über VPN: Ermittlung, nicht Port 1433

Die meisten Menschen behandeln einen SQL-Server-Hostnamen als vollständige Adresse und ein VPN als entweder erlaubt oder nicht. In der Praxis veranlasst eine benannte Instanz den Client zu einer zweiten Abfrage nach DNS, und genau diese Abfrage bricht ein Tunnel am häufigsten. Ein expliziter Endpunkt umgeht sie, weshalb tcp:host,port funktionieren kann, während host\INSTANCE in eine Zeitüberschreitung läuft. Der Unterschied liegt zwischen dem Finden des Dienstes und der Erlaubnis, ihn zu nutzen.

Der Mythos: ein Hostname bedeutet ein Port

Der Hostname wird zu einer Adresse aufgelöst, und dort endet seine Aufgabe. Eine benannte Instanz fügt einen Instanznamen hinzu, den der Server in einen TCP-Port übersetzen muss, und der Client kann ihn nicht erraten. Port 1433 ist der Standard für eine Standardinstanz, keine Eigenschaft jeder Instanz auf dem Rechner. Behandelt man beides als dasselbe, entsteht das klassische Symptom: Ping funktioniert, DNS funktioniert, der Scan von 1433 zeigt nichts, und die Schlussfolgerung ist, dass das Netzwerk SQL blockiert.

Eine zweite Annahme scheitert auf dieselbe Weise: dass das Öffnen von TCP 1433 ausreicht. Lauscht die Instanz woanders, beweist ein offener 1433 nur, dass dort etwas anderes ist. Der Port muss zum Listener passen, und dass der Listener ein Konfigurationsdetail auf der Serverseite ist, das sollte man erfragen statt es zu vermuten.

Was der Client mit einer benannten Instanz tatsächlich tut

Nach der Auflösung des Hosts sendet der Client eine Ermittlungsanfrage an SQL Server Browser über UDP 1434 und fragt, welchen Port die benannte Instanz verwendet. Der Browserdienst antwortet aus der Registry des Servers selbst, und dann öffnet der Client eine TCP-Verbindung zu diesem Port. Zwei Protokolle und zwei Ports sind beteiligt, bevor überhaupt ein Login versucht wird.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Deshalb erzeugt eine reine UDP-Blockade eine Zeitüberschreitung, die wie ein toter Host aussieht. Ist der Browserdienst gestoppt oder deaktiviert, bleibt die Ermittlungsanfrage unbeantwortet, obwohl die Datenbank-Engine läuft und ihr TCP-Port offen ist. Ist die Instanz mit einem statischen Port konfiguriert, fragt der Client trotzdem, es sei denn, ihm wurde der Endpunkt direkt gegeben. Jeder dieser Fehler sieht in der Fehlermeldung der Anwendung gleich aus, und sie brauchen unterschiedliche Korrekturen.

Der Browserdienst ist eine Ermittlungshilfe, nicht die Datenbank. Ihn zu stoppen stoppt nicht die Engine, und ihn zu starten öffnet nicht den TCP-Port der Instanz.

Warum der explizite Endpunkt funktioniert, wenn der Name es nicht tut

Ein expliziter Endpunkt entfernt die Abfrage aus der Reihenfolge: Der Client verbindet sich direkt mit der Adresse und dem Port, die Sie genannt haben. Das ist zuerst eine Diagnose, nicht automatisch eine dauerhafte Lösung, denn der Port kann sich ändern, wenn die Instanz später auf einen dynamischen umkonfiguriert wird. Vergleichen Sie beide Formen mit demselben Client und demselben Konto, bevor Sie Schlüsse ziehen.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Wenn die explizite Form gelingt und die benannte scheitert, ist die Ermittlung die Lücke, und Sie können wählen, wie Sie sie schließen: UDP 1434 durch den Tunnel erlauben oder den Administrator bitten, einen statischen Port festzulegen und den Endpunkt zu dokumentieren. Beides sind bewusste Entscheidungen mit unterschiedlichen Wartungskosten. Jeden Port im Bereich zu öffnen ist keines von beiden, und es ist die Option, die am Ende eines langen Tages vorgeschlagen zu werden pflegt. Halten Sie die Wahl dort fest, wo die Verbindungszeichenfolgen liegen.

Funktioniert keine der Formen, liegt das Problem oberhalb der Ermittlung. Prüfen Sie den Listener, die Route und die Zugriffsregel für den Port, den die Instanz tatsächlich nutzt, bevor Sie dem Browserdienst die Schuld geben.

Nach der Ermittlung: Authentifizierung und Identität sind getrennt

Ein Login-Fehler ist ein anderes Ereignis als eine Zeitüberschreitung, und die VPN-Identität wird durch den Tunnel nicht zu einem SQL-Login. Sobald der Client den richtigen Port erreicht, wendet die Datenbank-Engine ihre eigene Authentifizierung und ihre Berechtigungen an. Beide Phasen in einem Ticket zu vermischen ist der Weg, auf dem ein Ermittlungsproblem beim falschen Team landet. Lesen Sie die Fehlernummer, bevor Sie etwas ändern.

Behalten Sie den dokumentierten Hostnamen, wenn der Treiber das Serverzertifikat prüft, denn die Verbindung über eine numerische Adresse kann diese Prüfung ändern, statt das ursprüngliche Problem zu lösen. Neuere Microsoft-Treiber verschlüsseln standardmäßig, sodass eine Namensabweichung nach einer erfolgreichen TCP-Verbindung als Zertifikatfehler auftaucht. Das ist Fortschritt und kein neuer Fehler.

Der Mythos, den es abzulegen gilt, ist, dass ein SQL-Server-Hostname eine vollständige Adresse ist. Er ist ein Host plus, für eine benannte Instanz, eine Abfrage, die der Tunnel möglicherweise nicht trägt. Nennen Sie den Port, nennen Sie den Ermittlungspfad, und der nächste Fehler sagt Ihnen, welche Schicht zu reparieren ist.