Nein, eine Verbindungszeichenfolge kann Ihren VPN-Tunnel nicht starten

Entwickler suchen weiter nach der Stelle, an der eine Verbindungszeichenfolge, eine JDBC-URL oder ein tnsnames.ora-Eintrag das VPN auswählt. Diese Stelle gibt es nicht. Der Tunnel wird vom Betriebssystem oder einem Herstellerclient aufgebaut, der einen virtuellen Adapter registriert, und jede Datenbankbibliothek darüber nutzt die daraus folgende Socket-Schicht. Eine Verbindungszeichenfolge benennt einen Host, einen Port und ein Anmeldeinformationsobjekt, und das ist der ganze Wortschatz.

Mythos: Die Verbindungszeichenfolge kann einen Tunnel auswählen

Der Treiber öffnet einen TCP-Socket zu einem Host und Port. Er hat keine API zum Aufbauen eines Tunnels, kein Feld für ein Tunnelprofil und keine Möglichkeit, sich an einem VPN-Gateway zu authentifizieren.

Deshalb verhalten sich die Werkzeuge gleich, sobald eine Route existiert. SSMS, DBeaver, Eclipse Data Tools und ein einfaches sqlcmd benehmen sich, als wäre der Server im lokalen Netz, denn aus Sicht des Sockets ist er das. Der virtuelle Adapter machte das Datenbanksubnetz erreichbar, und der Treiber erfährt nie, wie.

Das erklärt auch, warum eine Verbindungszeichenfolge einen abgebrochenen Tunnel nicht reparieren kann. Wenn die Verbindung stirbt, meldet der Treiber eine Zeitüberschreitung oder einen allgemeinen Netzwerkfehler, und Anwendungscode, der das als Abfrageproblem behandelt, wiederholt für immer die falsche Schicht.

Bringen Sie den Tunnel hoch, bevor der Treiber läuft

Verbinden Sie das VPN auf Betriebssystemebene nach den Anweisungen des Anbieters oder des Netzwerkteams und öffnen Sie erst dann das Werkzeug. Praktisch heißt das, dass eine Route zum Datenbanksubnetz existiert, bevor der Treiber den Hostnamen auflöst.

Halten Sie die Tunnelaufsicht außerhalb der Anwendung. Ein PHP- oder Java-Dienst, der die Verbindung selbst aufbauen will, kodiert das Verhalten eines Anbieters in Geschäftslogik, und jedes Failover wird zu einem Anwendungsrelease. Ein Supervisor, der den Tunnel besitzt, ihn überwacht und neu startet, ist eine getrennte Angelegenheit vom Abfragepfad.

Prüfen Sie die Route, bevor Sie den Treiber beschuldigen: Wenn der Host nicht aufgelöst wird oder der Port aus der Shell nicht antwortet, ändert keine Verbindungszeichenfolge das.

Mythos: Ein Windows-Authentifizierungsfehler bedeutet, die Route ist kaputt

Die Windows-Authentifizierung über ein VPN schlägt oft mit einem Fehler fehl, der wie ein Netzwerkfehler aussieht, und die Route ist in Ordnung. Wenn das Konto zu einer anderen Domäne gehört und der Laptop ihr nicht beitreten kann, starten Sie den Client mit ausdrücklichen Anmeldeinformationen statt mit der Identität der Desktop-Sitzung.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

Der Schalter /netonly behält diese Anmeldeinformationen nur für die Remote-Authentifizierung. Prüfen Sie mit SELECT SUSER_SNAME(), was der Server tatsächlich erhalten hat, statt dem Verbindungsdialog zu vertrauen. Es wird berichtet, dass das Speichern der Anmeldeinformationen für die Serveradresse im Windows Credential Manager bei SSMS funktioniert, aber nicht immer bei einem Dienst, der unter einem anderen Konto läuft; prüfen Sie also, welche Identität der Prozess verwendet, bevor Sie die Anmeldung ändern.

Latenz macht aus einem serverseitigen Cursor eine Zeitüberschreitung

Ein serverseitiger Cursor bittet die Datenbank, das Ergebnis zu halten und es schrittweise abzurufen, was aus einem großen Ergebnis viele kleine Rundreisen macht. In einem LAN ist das billig. Über einen Tunnel mit Dutzenden Millisekunden zusätzlicher Latenz kann dieselbe Abfrage die Befehlszeitüberschreitung überschreiten, ohne dass überhaupt viel übertragen wird.

Wechseln Sie zu einem clientseitigen Cursor oder erhöhen Sie die Abrufgröße und bündeln Sie die Zeilen, und die Zahl der Rundreisen sinkt. Der Engpass ist die Zahl der Austausche, nicht die nominelle Verbindungsgeschwindigkeit; den Durchsatz zu messen wird Sie irreführen, das Messen der Rundreisen nicht. Testen Sie mit dem größten Resultset, das Ihre Nutzer tatsächlich ziehen, nicht mit einer Abfrage über eine Zeile, die sofort zurückkommt. Wenn die Zeitüberschreitung sich verschiebt, aber nicht verschwindet, erhöhen Sie Befehlszeitüberschreitung und Abrufgröße gemeinsam und messen erneut.

Dieselbe Arithmetik gilt für geschwätzige ORMs und für jeden Client, der eine Anweisung pro Zeile absetzt. Wenn der Abfrageplan in Ordnung und die Übertragung klein ist, zählen Sie die Netzwerkaustausche, bevor Sie die Datenbank abstimmen.

Prüfen Sie den Port, die Instanz und den lokalen Filter

Eine benannte Instanz lauscht auf einem dynamischen Port; bestätigen Sie den Port, statt 1433 anzunehmen. Bei einer Standardinstanz lässt sich der Wert aus dem Registrierungswert TcpPort unter dem Schlüssel SuperSocketNetLib der Instanz lesen. Prüfen Sie für Oracle, dass der Host in tnsnames.ora aufgelöst wird, dass die Adresse antwortet und dass der Listener-Port erlaubt ist; 1521 ist ein üblicher Standard, keine Garantie.

Schließen Sie dann die eigene Zugriffsliste des Tunnels aus und schließlich einen lokalen Virenscanner oder eine Host-Firewall, die die Verbindung blockiert, selbst wenn Client und Server derselbe Rechner sind. Halten Sie die fehlschlagende Stufe fest, bevor Sie die Konfiguration ändern, denn Namensauflösung, TCP-Erreichbarkeit und TLS oder Anmeldung schlagen jeweils mit einer anderen Meldung fehl.

Schreiben Sie die Stufe ins Ticket. Sonst wiederholt die nächste Person dieselbe Suche nach der Verbindungszeichenfolge, mit der alles begann.