Por qué conviene evitar la redirección del puerto 1433
Tienes un SQL Server en la oficina. Alguien fuera de esa red — un analista remoto, una herramienta de reportes en la nube, una app que tu equipo quiere construir — necesita leerlo. La solución rápida que todos sugieren es redirigir el puerto TCP 1433 del router al servidor y permitirlo en el firewall.
Funciona, y es rápido. También es lo que casi cualquier persona de seguridad te dirá que no hagas:
- Tu pantalla de login queda pública. Cualquier cosa en internet puede llegar al SQL Server e intentar autenticarse. Hay escáneres automáticos buscando el 1433 abierto todo el día, probando usuarios como
sacon listas de contraseñas. - La base de datos se vuelve tu perímetro. Cada parche pendiente y cada login débil ahora se alcanzan desde afuera.
- Limitar por IP ayuda, pero es frágil. Restringir el 1433 a las IPs de un proveedor reduce la exposición, pero esas IPs cambian y alguien tiene que mantener la lista.
Lo que de verdad quieres es que algo de afuera lea esa base sin ningún puerto de entrada. Hay cuatro formas de hacerlo.
Opción 1: una VPN
Una VPN mete a quien está afuera "dentro" de tu red. Una VPN de cliente conecta la laptop de una persona; una VPN sitio a sitio une dos redes de forma permanente.
Ideal para personas. Un contador remoto que necesita SQL Server Management Studio es justo el caso para el que se hicieron las VPN.
No sirve para herramientas SaaS. La mayoría de los servicios en la nube no pueden entrar a tu VPN. Y el gateway de la VPN suele escuchar en un puerto de entrada: cambias una base expuesta por un endpoint de VPN expuesto (mucho mejor protegido, eso sí).
Opción 2: un túnel SSH a través de un bastión
Muchas herramientas en la nube ofrecen "conectar por túnel SSH". Montas una pequeña máquina Linux (bastión) a la que la herramienta entra por SSH, y el tráfico hacia SQL Server pasa por esa sesión.
Muy soportado, y SSH con llaves es un protocolo conocido y auditado.
El detalle: sigue necesitando un puerto de entrada — normalmente el 22 — abierto a internet o a las IPs del proveedor, en una máquina que ahora tienes que parchar y vigilar. Si tu oficina no tiene dirección pública, encaja mal, porque el bastión tiene que ser alcanzable desde afuera.
Opción 3: un túnel saliente (Cloudflare Tunnel, ngrok, Tailscale)
Los túneles salientes invierten la dirección: un pequeño proceso dentro de tu red se conecta hacia afuera, y el tráfico vuelve por esa conexión saliente.
- Cloudflare Tunnel corre
cloudflareden tu red, hace conexiones solo salientes a Cloudflare y controlas quién entra con sus políticas de acceso. - ngrok abre una conexión saliente y te da un endpoint público que reenvía a tu servicio local. Cómodo para pruebas, pero ese endpoint es alcanzable desde internet si no le pones controles.
- Tailscale arma una red privada WireGuard entre los equipos que inscribes. Solo los miembros de tu red llegan al SQL Server.
Sin reglas de entrada ni IP pública. Funcionan en una oficina que no tiene ninguna de las dos.
Pero es acceso a la red, no a la base. Lo que llegue al túnel habla con SQL Server con los permisos de su login. Tú sigues a cargo de las políticas, los logins y el monitoreo. Y la herramienta SaaS del otro lado tiene que poder usar el túnel, cosa que muchas no pueden.
Opción 4: un agente de proveedor que sale hacia afuera
Algunos productos traen su propio agente para este caso. Lo instalas en una máquina que ve la base, se conecta hacia la nube del proveedor y el producto manda las consultas por esa conexión.
- El on-premises data gateway de Microsoft es el más conocido. Corre en Windows, sale hacia Azure y sirve a Power BI, Power Apps, Power Automate y Logic Apps. Si tu equipo vive en Microsoft, es la opción por defecto. (Lo comparamos a fondo en nuestra guía de alternativas al on-premises data gateway.)
- El Conector de AgentUI hace lo mismo para las apps y dashboards de AgentUI, con un alcance más acotado a propósito.
Por qué es ordenado: sin puerto de entrada, sin dirección pública, y el agente solo sirve a los productos de ese proveedor, así que no hay un camino de red general del que preocuparse.
La contrapartida: cada uno sirve solo a los productos de su proveedor, y estás confiando en el agente del proveedor: lee qué puede y qué no puede hacer antes de instalarlo.
Lado a lado
| Opción | ¿Abre puerto de entrada? | ¿Funciona sin IP pública? | Quién llega a la base | Ideal para |
|---|---|---|---|---|
| Redirigir el 1433 | Sí (1433) | No | Cualquiera que llegue al puerto | Nada a largo plazo |
| VPN | Normalmente, en el gateway | Depende | Cualquiera en la VPN | Personas con acceso completo |
| Túnel SSH por bastión | Sí (22, en el bastión) | No | Quien tenga llave del bastión | Herramientas que soportan SSH |
| Túnel saliente (Cloudflare Tunnel, Tailscale) | No | Sí | Quien permita tu política | Equipos que gestionan políticas de acceso |
| Agente de proveedor (gateway, Conector de AgentUI) | No | Sí | Solo los productos de ese proveedor | Usar las herramientas de un proveedor sobre los datos |
Si lo que quieres son apps y dashboards sobre esos datos
Si el objetivo son herramientas internas, reportes o dashboards sobre la base de la oficina, importa más el conector que el túnel. Para eso existe el conector de AgentUI para SQL Server on-premise:
- Solo saliente. Sale por HTTPS en el puerto 443. Sin reglas de entrada, sin cambios en el firewall, sin IP pública.
- Solo lectura. Solo corren consultas
SELECTyWITH, y cada una se revierte al terminar. - La contraseña no se mueve. Se guarda solo en ese servidor (cifrada en Windows). AgentUI guarda apenas una huella de la llave del conector.
- Revocable. Lo revocas en dos clics; la llave deja de funcionar en menos de 25 segundos.
- Límites. Solo Microsoft SQL Server. Consultas bajo demanda, hasta 1.000 filas y 30 segundos cada una. No copia ni sincroniza la base.
Se instala en Windows, macOS o Linux como servicio. Un caso típico es SAP Business One en un servidor Windows. Si estás comparando constructores de apps en este punto, también explicamos cómo se conecta Retool a un SQL Server on-premise.
¿Cuál elegir?
- Una persona necesita acceso completo desde casa: VPN.
- Una herramienta en la nube solo soporta túneles SSH: un bastión limitado a las IPs del proveedor, y trátalo como un servidor más que mantener.
- Tu equipo sabe gestionar políticas de acceso y quiere un camino general: un túnel saliente como Cloudflare Tunnel o Tailscale.
- Quieres que un solo producto lea los datos y nada más: el agente saliente de ese producto — el gateway de Microsoft para Power Platform, el Conector de AgentUI para apps de AgentUI.
Si eres de este último grupo, conecta tu SQL Server con el Conector de AgentUI. Solo lectura, y lo revocas en dos clics.