SQL per VPN: client directe o estació de treball interna?

Els equips volen SSMS als seus portàtils, i la solució ràpida és publicar el port SQL al pool de VPN. La resposta més lenta pregunta on ha de córrer el procés client, perquè l'accés directe i una estació de treball interna produeixen adreces d'origen, confiança de l'extrem i camins de dades diferents. Cap dels dos és automàticament segur, i la pertinença a la VPN per si sola no decideix res. Compareu els dissenys abans que existeixi una regla de permetre.

Dos camins, dues adreces d'origen

Amb accés directe el portàtil porta la configuració del client i obre ell mateix la connexió a la base de dades. Amb una estació de treball remota el portàtil obre una sessió d'escriptori, i l'estació de treball fa la connexió SQL des de la seva pròpia adreça. Per tant, la base de dades veu el pool de VPN o una passarel·la traduïda en el primer disseny, i l'adreça de l'estació de treball en el segon. Aquesta diferència decideix quina regla de tallafocs i quin permís SQL s'apliquen realment.

El portàtil continua controlant la sessió remota, així que una estació de treball no substitueix l'autenticació d'usuari ni la política de sessió.

Comproveu què veu realment la base de dades

L'adreça d'origen és una cosa que es mesura, no que s'infereix d'un diagrama. Llegiu-la des del costat del servidor d'una connexió activa.

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"

La prova de connectivitat demostra que l'oient accepta TCP des d'aquella xarxa, mentre que la consulta demostra a quin inici de sessió i a quina base de dades ha arribat la sessió. Per veure l'adreça que el servidor ha registrat, consulteu sys.dm_exec_connections per a la sessió actual, que retorna l'adreça del client després de qualsevol traducció. Si aquest valor és una passarel·la i no el portàtil, una regla d'amfitrió per usuari no pot funcionar a la màquina de la base de dades. Escriviu el valor observat al costat del disseny triat, perquè les reconnexions i els canvis de pool el mouen.

Obriu l'oient i res més

Obriu només el servei que necessita el desplegament. El conegut 1433 és el port de la instància per defecte, no una constant universal.

Get-NetTCPConnection -State Listen -LocalPort 1433

Les instàncies amb nom sovint escolten en un port dinàmic, amb SQL Server Browser responent al descobriment per UDP 1434, i aquesta dependència és una exposició separada que cal justificar. Fixar un port concret per a la instància elimina la necessitat de Browser i fa estables les regles de tallafocs. Mantingueu les comprovacions de xifratge i certificats que el client ja fa en lloc de desactivar-les perquè passi una prova. Després atorgueu rols de base de dades per a la càrrega de treball en lloc d'afegir tot el grup de VPN a un rol de servidor.

Demostreu el camí permès i el denegat

Obriu una sessió nova com a usuari aprovat corrent i confirmeu la identitat del servidor, la base de dades i l'operació necessària. Després confirmeu l'exclusió: una font o un compte fora de la política ha de fallar la mateixa prova. Per al disseny amb estació de treball, verifiqueu que el portàtil no pot saltar-se la frontera arribant directament a la base de dades. Per a l'accés directe, verifiqueu que la ruta i la regla d'origen encara es mantenen després d'una reconnexió.

Registreu on ha corregut el client, quina font ha observat la base de dades i quina regla ho ha permès. Aquesta és l'evidència que demanarà la propera revisió.