SQL su VPN: client diretto o workstation interna?

I team vogliono SSMS sui propri portatili, e la soluzione rapida è pubblicare la porta SQL nel pool VPN. La risposta più lenta chiede dove deve girare il processo client, perché l'accesso diretto e una workstation interna producono indirizzi di origine, fiducia dell'endpoint e percorsi dati diversi. Nessuno dei due è automaticamente sicuro, e l'appartenenza alla VPN da sola non decide nulla. Confrontate i progetti prima che esista una regola di autorizzazione.

Due percorsi, due indirizzi di origine

Con l'accesso diretto il portatile porta la configurazione del client e apre da sé la connessione al database. Con una workstation remota il portatile apre una sessione desktop, e la workstation effettua la connessione SQL dal proprio indirizzo. Il database vede quindi il pool VPN o un gateway tradotto nel primo progetto, e l'indirizzo della workstation nel secondo. Questa differenza decide quale regola del firewall e quale permesso SQL si applicano davvero.

Il portatile controlla ancora la sessione remota, quindi una workstation non sostituisce l'autenticazione utente né la policy di sessione.

Verificate che cosa vede davvero il database

L'indirizzo di origine si misura, non si deduce da uno schema. Leggetelo dal lato server di una connessione attiva.

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"

Il test di connettività dimostra che il listener accetta TCP da quella rete, mentre la query dimostra quale login e quale database ha raggiunto la sessione. Per vedere l'indirizzo registrato dal server, interrogate sys.dm_exec_connections per la sessione corrente, che restituisce l'indirizzo del client dopo qualsiasi traduzione. Se quel valore è un gateway e non il portatile, una regola host per utente non può funzionare sulla macchina del database. Annotate il valore osservato accanto al progetto scelto, perché le riconnessioni e i cambi di pool lo spostano.

Aprite il listener e nulla di più

Aprite solo il servizio che serve al deployment. Il famoso 1433 è la porta dell'istanza predefinita, non una costante universale.

Get-NetTCPConnection -State Listen -LocalPort 1433

Le istanze con nome ascoltano spesso su una porta dinamica, con SQL Server Browser che risponde all'individuazione su UDP 1434, e questa dipendenza è un'esposizione separata da giustificare. Fissare una porta stabile per l'istanza elimina la necessità di Browser e rende stabili le regole del firewall. Mantenete i controlli di cifratura e certificato che il client già esegue invece di disattivarli per far passare un test. Poi concedete ruoli del database per il carico di lavoro invece di aggiungere l'intero gruppo VPN a un ruolo server.

Dimostrate il percorso consentito e quello negato

Aprite una nuova sessione come utente ordinario approvato, e confermate l'identità del server, il database e l'operazione richiesta. Poi confermate l'esclusione: un'origine o un account fuori policy deve fallire lo stesso test. Per il progetto con workstation, verificate che il portatile non possa aggirare il confine raggiungendo direttamente il database. Per l'accesso diretto, verificate che la route e la regola di origine valgano ancora dopo una riconnessione.

Registrate dove è stato eseguito il client, quale origine ha osservato il database e quale regola lo ha consentito. È la prova che chiederà la prossima revisione.