SQL via VPN: directe client of interne werkplek?

Teams willen SSMS op hun laptops, en de snelle oplossing is de SQL-poort naar de VPN-pool publiceren. Het langzamere antwoord vraagt waar het clientproces moet draaien, omdat directe toegang en een interne werkplek verschillende bronadressen, endpointvertrouwen en datapaden opleveren. Geen van beide is automatisch veilig, en VPN-lidmaatschap alleen beslist niets. Vergelijk de ontwerpen voordat er een toestemmingsregel bestaat.

Twee paden, twee bronadressen

Bij directe toegang draagt de laptop de clientconfiguratie en opent de databaseverbinding zelf. Bij een externe werkplek opent de laptop een desktopsessie, en de werkplek maakt de SQL-verbinding vanaf zijn eigen adres. De database ziet dus de VPN-pool of een vertaalde gateway in het eerste ontwerp, en het adres van de werkplek in het tweede. Dat verschil bepaalt welke firewallregel en welke SQL-rechten werkelijk gelden.

De laptop bestuurt nog steeds de externe sessie, dus een werkplek vervangt gebruikersauthenticatie of sessiebeleid niet.

Controleer wat de database werkelijk ziet

Het bronadres is iets om te meten in plaats van uit een diagram af te leiden. Lees het aan de serverzijde van een actieve verbinding.

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"

De verbindingstest bewijst dat de listener TCP van dat netwerk accepteert, terwijl de query bewijst welke login en welke database de sessie bereikte. Om het adres te zien dat de server vastlegde, vraag sys.dm_exec_connections op voor de huidige sessie; dat geeft het clientadres terug na elke vertaling. Als die waarde een gateway is en niet de laptop, kan een hostregel per gebruiker niet werken op de databasemachine. Noteer de waargenomen waarde naast het gekozen ontwerp, omdat herverbindingen en poolwijzigingen die verplaatsen.

Open de listener en niets meer

Open alleen de dienst die de implementatie nodig heeft. De bekende 1433 is de poort van de standaardinstantie, geen universele constante.

Get-NetTCPConnection -State Listen -LocalPort 1433

Benoemde instanties luisteren vaak op een dynamische poort, waarbij SQL Server Browser ontdekking op UDP 1434 beantwoordt, en die afhankelijkheid is een aparte blootstelling die verantwoord moet worden. Een vaste poort aan de instantie koppelen haalt de behoefte aan Browser weg en maakt firewallregels stabiel. Behoud de versleutelings- en certificaatcontroles die de client al uitvoert, in plaats van ze uit te zetten om een test te laten slagen. Geef daarna databaserollen voor de werklast in plaats van de hele VPN-groep aan een serverrol toe te voegen.

Bewijs het toegestane pad en het geweigerde

Open een nieuwe sessie als gewone goedgekeurde gebruiker, en bevestig de serveridentiteit, de database en de vereiste bewerking. Bevestig daarna de uitsluiting: een bron of account buiten het beleid moet dezelfde test falen. Voor het werkplekontwerp, verifieer dat de laptop de grens niet kan omzeilen door de database rechtstreeks te bereiken. Voor directe toegang, verifieer dat de route en de bronregel na een herverbinding nog gelden.

Leg vast waar de client liep, welke bron de database waarnam en welke regel het toestond. Dat is het bewijs dat de volgende beoordeling zal vragen.