SQL über VPN: direkter Client oder interne Workstation?

Teams wollen SSMS auf ihren Laptops, und die schnelle Lösung ist, den SQL-Port in den VPN-Pool zu veröffentlichen. Die langsamere Antwort fragt, wo der Clientprozess laufen soll, weil direkter Zugriff und eine interne Workstation unterschiedliche Quelladressen, Endpunkt-Vertrauen und Datenpfade erzeugen. Keines davon ist automatisch sicher, und die VPN-Mitgliedschaft allein entscheidet nichts. Vergleichen Sie die Entwürfe, bevor eine Allow-Regel existiert.

Zwei Pfade, zwei Quelladressen

Beim direkten Zugriff trägt der Laptop die Clientkonfiguration und öffnet die Datenbankverbindung selbst. Bei einer entfernten Workstation öffnet der Laptop eine Desktop-Sitzung, und die Workstation stellt die SQL-Verbindung von ihrer eigenen Adresse her. Die Datenbank sieht daher im ersten Entwurf den VPN-Pool oder ein übersetztes Gateway und im zweiten die Adresse der Workstation. Dieser Unterschied entscheidet, welche Firewall-Regel und welche SQL-Berechtigung tatsächlich greifen.

Der Laptop steuert weiterhin die Remotesitzung, eine Workstation ersetzt also nicht die Benutzerauthentifizierung oder die Sitzungsrichtlinie.

Prüfen Sie, was die Datenbank tatsächlich sieht

Die Quelladresse muss gemessen werden, statt sie aus einem Diagramm abzuleiten. Lesen Sie sie auf der Serverseite einer aktiven Verbindung ab.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

Der Konnektivitätstest belegt, dass der Listener TCP aus diesem Netzwerk annimmt, während die Abfrage belegt, welches Login und welche Datenbank die Sitzung erreicht hat. Um die vom Server erfasste Adresse zu sehen, fragen Sie sys.dm_exec_connections für die aktuelle Sitzung ab; die Ansicht liefert die Clientadresse nach jeder Übersetzung. Ist dieser Wert ein Gateway und nicht der Laptop, kann eine Host-Regel pro Benutzer auf der Datenbankmaschine nicht funktionieren. Notieren Sie den beobachteten Wert neben dem gewählten Entwurf, weil Wiederverbindungen und Pool-Änderungen ihn verschieben.

Öffnen Sie den Listener und nichts weiter

Öffnen Sie nur den Dienst, den das Deployment braucht. Der vertraute 1433 ist der Port der Standardinstanz und keine universelle Konstante.

Get-NetTCPConnection -State Listen -LocalPort 1433

Benannte Instanzen lauschen oft auf einem dynamischen Port, wobei SQL Server Browser die Erkennung über UDP 1434 beantwortet, und diese Abhängigkeit ist eine eigene Exposition, die begründet werden muss. Ein fester Port für die Instanz beseitigt die Notwendigkeit für Browser und macht Firewall-Regeln stabil. Behalten Sie die Verschlüsselungs- und Zertifikatsprüfungen des Clients bei, statt sie abzuschalten, damit ein Test besteht. Vergeben Sie dann Datenbankrollen für die Arbeitslast, statt die gesamte VPN-Gruppe einer Serverrolle hinzuzufügen.

Beweisen Sie den erlaubten und den verweigerten Pfad

Öffnen Sie eine neue Sitzung als gewöhnlicher genehmigter Benutzer und bestätigen Sie Serveridentität, Datenbank und die erforderliche Operation. Bestätigen Sie dann den Ausschluss: Eine Quelle oder ein Konto außerhalb der Richtlinie muss denselben Test nicht bestehen. Prüfen Sie beim Workstation-Entwurf, ob der Laptop die Grenze nicht umgehen kann, indem er die Datenbank direkt erreicht. Prüfen Sie beim direkten Zugriff, ob Route und Quellregel nach einer Wiederverbindung weiterhin gelten.

Halten Sie fest, wo der Client lief, welche Quelle die Datenbank beobachtet hat und welche Regel es erlaubt hat. Das sind die Nachweise, die die nächste Überprüfung verlangen wird.