SQL por VPN: ¿cliente directo o estación de trabajo interna?

Los equipos quieren SSMS en sus portátiles, y la solución rápida es publicar el puerto SQL en el pool de VPN. La respuesta más lenta pregunta dónde debe ejecutarse el proceso cliente, porque el acceso directo y una estación de trabajo interna producen direcciones de origen, confianza del extremo y rutas de datos distintas. Ninguna es segura automáticamente, y la pertenencia a la VPN por sí sola no decide nada. Compare los diseños antes de que exista una regla de permiso.

Dos rutas, dos direcciones de origen

Con acceso directo el portátil lleva la configuración del cliente y abre él mismo la conexión a la base de datos. Con una estación de trabajo remota el portátil abre una sesión de escritorio, y la estación hace la conexión SQL desde su propia dirección. Por eso la base de datos ve el pool de VPN o una puerta de enlace traducida en el primer diseño, y la dirección de la estación en el segundo. Esa diferencia decide qué regla de cortafuegos y qué permiso de SQL se aplican realmente.

El portátil sigue controlando la sesión remota, así que una estación de trabajo no sustituye la autenticación de usuario ni la política de sesión.

Compruebe qué ve realmente la base de datos

La dirección de origen se mide, no se deduce de un diagrama. Léala en el lado del servidor de una 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"

La prueba de conectividad demuestra que el escucha acepta TCP desde esa red, mientras que la consulta demuestra a qué inicio de sesión y a qué base de datos llegó la sesión. Para ver la dirección que registró el servidor, consulte sys.dm_exec_connections para la sesión actual, que devuelve la dirección del cliente después de cualquier traducción. Si ese valor es una puerta de enlace y no el portátil, una regla de host por usuario no puede funcionar en la máquina de la base de datos. Anote el valor observado junto al diseño elegido, porque las reconexiones y los cambios de pool lo mueven.

Abra el escucha y nada más

Abra solo el servicio que necesita el despliegue. El conocido 1433 es el puerto de la instancia predeterminada, no una constante universal.

Get-NetTCPConnection -State Listen -LocalPort 1433

Las instancias con nombre suelen escuchar en un puerto dinámico, con SQL Server Browser respondiendo al descubrimiento por UDP 1434, y esa dependencia es una exposición aparte que hay que justificar. Fijar un puerto concreto para la instancia elimina la necesidad de Browser y hace estables las reglas de cortafuegos. Mantenga las comprobaciones de cifrado y certificados que el cliente ya realiza en lugar de desactivarlas para que pase una prueba. Después conceda roles de base de datos para la carga de trabajo en lugar de añadir todo el grupo de VPN a un rol de servidor.

Demuestre la ruta permitida y la denegada

Abra una sesión nueva como usuario aprobado corriente y confirme la identidad del servidor, la base de datos y la operación requerida. Después confirme la exclusión: un origen o una cuenta fuera de la política debe fallar la misma prueba. Para el diseño con estación de trabajo, verifique que el portátil no puede saltarse el límite llegando directamente a la base de datos. Para el acceso directo, verifique que la ruta y la regla de origen siguen vigentes tras una reconexión.

Registre dónde se ejecutó el cliente, qué origen observó la base de datos y qué regla lo permitió. Esa es la evidencia que pedirá la próxima revisión.