Reenvío SSH, VPN o RD Gateway: ¿qué camino para un escritorio RDP?
Un puerto reenviado, un espacio de trabajo enrutado o una puerta de escritorio: compare la accesibilidad que ofrece cada uno y quién debe operarlo antes de elegir.
Las tres opciones transportan RDP, así que el protocolo no es el factor decisivo. La verdadera pregunta es cuánta accesibilidad debe recibir un usuario y quién opera lo que la concede. Un puerto TCP reenviado, una red privada enrutada y una puerta de escritorio responden a esa pregunta en tres tamaños distintos. Elija primero el tamaño y el producto vendrá después.
La pregunta es el alcance, no el protocolo
Anote qué necesita tocar realmente el usuario. Si la respuesta es un escritorio, un diseño que concede una subred es demasiado amplio. Si la respuesta es un escritorio más recursos compartidos más una consola de administración, un diseño que reenvía un puerto volverá el mes que viene por dos reenvíos más. La lista de destinos es el requisito; todo lo demás es implementación.
Mantenga la identidad de entrada separada de la cuenta de Windows que inicia sesión en el escritorio. Todos los diseños siguientes tienen ambas, y confundirlas es como una cuenta de host de salto acaba con más autoridad de la que nadie pretendía.
Un servicio TCP reenviado
Un host de salto SSH aprobado puede reenviar un escucha local al servicio RDP que puede alcanzar. Ate ese escucha a loopback cuando solo existe para la máquina del propio usuario, que es la intención normal de un reenvío local. El reenvío es una comodidad para una persona, no un servicio para un equipo.
El inicio de sesión SSH autentica el acceso a la ruta de reenvío, y nada más. La autenticación de Windows y la autorización RDP siguen ocurriendo en el destino, así que una cuenta de salto válida no es una sesión de escritorio válida. Son dos puertas independientes y ambas deben abrirse.
Restrinja los destinos de reenvío de la cuenta de salto en lugar de conceder un shell sin restricciones. Este diseño encaja con un conjunto pequeño y enumerado explícitamente de máquinas, y añade un host, una identidad y un ciclo de vida que operar. Ese host adicional es la parte que la gente olvida al compararlo con una puerta: alguien tiene que parchearlo, monitorizarlo y poseer sus claves.
Un espacio de trabajo privado enrutado
Una VPN proporciona DNS privado y acceso a varios servicios usados en conjunto, y ese es su valor real. Ocultar un puerto de escritorio es un efecto secundario, no la razón para construirla. Esa distinción importa cuando alguien pregunta por qué existe la VPN.
Restrinja las rutas y los permisos de recursos a los destinos previstos. Un usuario conectado no merece automáticamente toda la LAN, y el cortafuegos de destino más los derechos de inicio de sesión de Windows siguen siendo límites separados que la VPN no sustituye.
Esta disposición es cómoda para un espacio de trabajo gestionado ya establecido. El coste es que la incorporación, los requisitos de dispositivo, el comportamiento del resolutor y la política de conexión pasan a formar parte del entorno de trabajo del usuario, y alguien debe poseerlos. Compare ese coste con la licencia de la puerta antes de suponer que la VPN es la opción más barata.
Una puerta específica para RDP
Remote Desktop Gateway ofrece un límite específico para RDP en lugar de uno de red. Su política de autorización de conexiones decide quién puede conectarse, y su política de autorización de recursos decide a qué recursos internos pueden llegar a través de ella. Ambas políticas forman parte del producto, no son extras opcionales.
Planifique los certificados, la integración de identidad y los transportes necesarios en conjunto. La puerta no es un relé TCP anónimo, y desplegarla como tal omite las políticas que la justifican. También conlleva requisitos de licencia y operativos que un solo puerto reenviado no tiene. Presupuestelos antes de la revisión de diseño, no después.
Donde un equipo ya opera acceso centralizado a escritorios, ese coste ya está pagado. Donde una persona necesita una máquina, es una máquina grande para un trabajo pequeño.
Lo que las tres siguen necesitando
Conserve las comprobaciones de identidad del host en cada diseño. Un alias local o un túnel no hacen inofensivo un certificado inesperado, y aceptar uno que no coincide para atravesar un proxy anula el sentido del túnel. El nombre del cliente y el nombre del certificado deben conciliarse deliberadamente.
Aplique MFA en el punto de entrada donde la política lo exija, y mantenga los controles de cuenta del destino. Los dos se complementan: el primero decide quién puede llegar a la puerta, el segundo quién puede abrirla. Omitir cualquiera deja un diseño que parece completo y no lo está.
Elija el límite que encaja con el trabajo y el modelo operativo que realmente tiene. Descripción general de los roles de RDS describe el lugar de la puerta entre el host de sesión y otros componentes, y ese es el contexto que hace legible su coste.