SQL por VPN: cliente directo ou estación de traballo interna?

Os equipos queren SSMS nos seus portátiles, e a solución rápida é publicar o porto SQL no pool de VPN. A resposta máis lenta pregunta onde debe executarse o proceso cliente, porque o acceso directo e unha estación de traballo interna producen enderezos de orixe, confianza do extremo e camiños de datos distintos. Ningún é seguro automaticamente, e a pertenza á VPN por si soa non decide nada. Compare os deseños antes de que exista unha regra de permiso.

Dous camiños, dous enderezos de orixe

Con acceso directo o portátil leva a configuración do cliente e abre el mesmo a conexión á base de datos. Cunha estación de traballo remota o portátil abre unha sesión de escritorio, e a estación fai a conexión SQL desde o seu propio enderezo. Por iso a base de datos ve o pool de VPN ou unha pasarela traducida no primeiro deseño, e o enderezo da estación no segundo. Ese diferente decide que regra de cortafogos e que permiso SQL se aplican realmente.

O portátil segue controlando a sesión remota, así que unha estación de traballo non substitúe a autenticación de usuario nin a política de sesión.

Comprobe que ve realmente a base de datos

O enderezo de orixe mídese, non se deduce dun diagrama. Léao no lado do servidor dunha conexión 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"

A proba de conectividade demostra que o oínte acepta TCP desde esa rede, mentres que a consulta demostra a que inicio de sesión e a que base de datos chegou a sesión. Para ver o enderezo que rexistrou o servidor, consulte sys.dm_exec_connections para a sesión actual, que devolve o enderezo do cliente despois de calquera tradución. Se ese valor é unha pasarela e non o portátil, unha regra de host por usuario non pode funcionar na máquina da base de datos. Anote o valor observado xunto ao deseño elixido, porque as reconexións e os cambios de pool móveno.

Abra o oínte e nada máis

Abra só o servizo que necesita o despregamento. O coñecido 1433 é o porto da instancia predeterminada, non unha constante universal.

Get-NetTCPConnection -State Listen -LocalPort 1433

As instancias con nome adoitan escoitar nun porto dinámico, con SQL Server Browser respondendo ao descubrimento por UDP 1434, e esa dependencia é unha exposición aparte que hai que xustificar. Fixar un porto concreto para a instancia elimina a necesidade de Browser e fai estables as regras de cortafogos. Manteña as comprobacións de cifrado e certificados que o cliente xa realiza en lugar de desactivalas para que pase unha proba. Despois conceda roles de base de datos para a carga de traballo en lugar de engadir todo o grupo de VPN a un rol de servidor.

Demostre o camiño permitido e o denegado

Abra unha sesión nova como usuario aprobado corrente e confirme a identidade do servidor, a base de datos e a operación necesaria. Despois confirme a exclusión: unha orixe ou unha conta fóra da política debe fallar a mesma proba. Para o deseño con estación de traballo, verifique que o portátil non pode saltar a fronteira chegando directamente á base de datos. Para o acceso directo, verifique que a ruta e a regra de orixe seguen vixentes tras unha reconexión.

Rexistre onde se executou o cliente, que orixe observou a base de datos e que regra o permitiu. Esa é a evidencia que pedirá a próxima revisión.