Remote Desktop – Escritorio Remoto: Instalación y Configuración de “RD-Gateway” (Nota 6)

En esta sexta nota, y continuando con la serie, veremos la instalación y configuración de la funcionalidad “Remote Dekstop Gateway” (Puerta de Enlace de Escritorio Remoto), describiremos su funcionalidad y por supuesto demostraremos su utilización

Es muy importante tener en claro cuál es su funcionalidad, y qué tipo de acceso permite, y sobre todo las diferencias con “Remote Desktop Web Access” (Acceso Web a Escritorio Remoto) y el uso de cada uno

Además, y no tan conocido, es que “RD-Gateway” permite que se limite qué usuarios se podrán conectar y a qué equipos podrán acceder, entre otras cosas

Así que en este caso veremos primero que nada estas diferencias

Es un error muy común pensar que teniendo configurado “RD-Web Access” que permite el acceso a aplicaciones publicadas (RemoteApp) y Escritorio Remoto y verificando que funciona en la red interna, esto va a permitir el acceso desde otras redes, y esto normalmente no es así

“RD-Web Access” crea un sitio web que funciona bajo HTTPS pero que se limita a presentar las aplicaciones al cliente, pero luego cuando el cliente va a ejecutar una aplicación o conectarse a un Escritorio Remoto, utiliza protocolo RDP, y por supuesto, por motivos de seguridad básicos, este no está permitido en los cortafuegos. Por lo tanto no es accesible desde “afuera”

Para evitar este problema es que existe la funcionalidad “RD-Gateway” que permite encapsular el tráfico de protocolo RDP en HTTPS y por lo tanto pasar a través de los cortafuegos

Y por lo tanto permite que el cliente usando solamente HTTPS pueda hacer conexiones de Escritorio Remoto. Atención con algo, no estoy nombrando RemoteApp, esta es una limitación a tener en cuenta, sólo Escritorio Remoto

Comencemos entonces en DC1, donde hemos centralizado toda la administración de Escritorio Remoto, instalando la funcionalidad “RD-Gateway” en la máquina “rd-wa-cb-gat”

Recordemos que todos los iconos en color verde son los componentes no instalados, así que pulsando sobre el correspondiente comenzará el asistente

Como había propuesto al principio instalaré la funcionalidad en el mismo equipo donde ya está “RD-Web Access” y “RD-Connection Broker”, así que lo selecciono

¿Recuerdan que ya habíamos puesto el certificado con el nombre público que se utilizará para accederlo externamente? Hay que escribir ese justamente

Y cuando finaliza debemos configurar el certificado correspondiente, que servirá para que el cliente pueda autenticarlo

No he capturado todas las pantallas para que no sea tan larga esta nota, pero procederemos análogamente a lo que hemos hecho con los otros roles

Debe quedar así

Y podemos ver que ahora que ya está instalado el componente el icono se ha grisado, igual a los otros ya instalados

Repasemos algunas de las configuraciones que se hicieron anteriormente

Podemos ver que el sistema ha cambiado automáticamente la configuración para que se comience a utilizar “RD-Gateway”

Para comenzar a configurar esta funcionalidad, necesitamos una herramienta que por omisión no se instala en el equipo donde estamos centralizando todo, y tiene su motivo. Para hacer la instalación de esta consola, entre otros componentes se necesita instalar IIS, lo cual no sería una buena idea que esté en cualquier máquina

Si lo deseamos se puede instalar en DC1, yo prefiero ir directamente a la máquina que tiene la funcionalidad (rd-wb-cb-gat) y hacerlo desde allí. Debemos seleccionar “Remote Desktop Gateway Manager”

Vamos a ver qué opciones tenemos para configurar. Comencemos con las propiedades del servidor

En la ficha “General” podemos, como importante, seleccionar cuál es límite máximo de conexiones simultáneas, o deshabilitar nuevas conexiones, por ejemplo si está prevista una parada del servicio por mantenimiento

En “SSL Certificate”, no tenemos nada que hacer ya que tenemos el certificado correcto

En “Transport Settings”, podríamos configurar en cuáles direcciones IP atíende el sistema y que protocolos y puertos se usarán

En “RD CAP Store” (ya veremos qué son las RDCAPs) podemos seleccionar usar un NPS (“Network Policy Server”) separado. NPS tiene funcionalidad RADIUS y más

En “Server Farm” en nuestro caso no lo he implementado, pero se podría usar una granja de servidores para proveer tolerancia a fallas o balance de carga

En “Auditing” podemos seleccionar qué acciones se auditarán

“SSL Bridging” permitiría “puentear” las conexiones SSL para comunicarse con otro servidor, por ejemplo si el “RD-Gateway” estuviera en una DMZ

Y por último en “Messaging” podemos poner dos mensajes para que muestre a los usuarios. El primero por ejemplo avisando que está programada una interrupción del servicio, y el segundo de uso aceptable. Aunque en este caso me he permitido hacer algo de humor, ya lo veremos cuando muestre la conexión desde un usuario ;)

Antes de continuar, aclaro dos abreviaturas muy usadas, y que el propio sistema las utiliza

CAP = “Connection Authorization Policies”: permiten limitar qué usuarios podrán conectarse

RAP = “Resource Authorization Policies”: configuran a qué recursos de la red podrán acceder los usuarios que se conecten a través de “RD-Gateway”

Comencemos viendo la CAP creada por omisión

En “General” sólo cambiar el nombre, y si la habilitamos o no

En “Requirements” vemos que por omisión están autorizados todos los usuarios del Dominio, podríamos limitar a un determinado grupo. Lo mismo se pueden limitar qué máquinas del Dominio, por omisión todas

En “Device Redirection” se explica por sí mismo

Y en “Timeouts” la duración de las sesiones activas y ociosas

 

Vamos ahora a las propiedades de la RAP por omisión

En “General” es análogo a la CAP

En esta demostración, no he puesto limitaciones, así que en “User Groups” no muestra limitaciones

En “Network Resource” es donde se puede limitar a qué máquinas podrán acceder los usuarios, por supuesto que en este caso no he puesto limitaciones

Y finalmente en “Allowed Ports” que puertos estarán permitidos

 

Entonces resumiendo: el uso de “RD-Gateway” es para acceso desde una red externa, pero también puede funcionar en la red interna, así que antes de hacer el movimiento de las máquinas clientes a una red externa, lo pruebo desde un cliente y controlo que todo siga funcionando bien por “RD-Web Acces” en ambos clientes (no vaya a suceder que por agregar algo, estropeemos algo que ya funciona :))

Observen que ya utilizo el nuevo URL (https://rd.guillermod.com.ar/RDWeb)

Todo bien

Recuerdo que habíamos dejado desde la primera nota que tanto en RDSH1 como RDSH2 habíamos permitido el acceso a todos los usuarios a Escritorio Remoto, incluyendo a “Domain Users” en el correspondiente grupo local “Remote Desktop Users”

 

Ahora moveré a los clientes a una red externa, simulando Internet, aunque disculpen que esté usando direccionamiento privado por limitaciones de mi ambiente de laboratorio

Agregué un equipo con Windows Server 2012 R2 que está cumpliendo funciones de NAT y compartir Internet, simulando un Router, interconectando la red del Dominio con esta Internet simulada. Si alguien tiene dudas cómo configurarlo puede consultar la siguiente nota: “Windows Server 2012: Compartir Conexión a Internet

La única configuración adicional, fue redirigir todo el tráfico HTTPS recibido en la interfaz externa, a la del equipo “rd-wa-cb-gat” en la red interna. Todo lo que llegue a 192.168.0.14-TCP443 enviarlo a 192.168.1.103-TCP443

En cada uno de los clientes (CL1 y CL2) los conecté a la red de tipo externa del NAT (gracias VMware), les asigné dirección IP válida para esta red externa (192.168.0.0/24) eliminando las otras configuraciones como servidor DNS y Puerta de Enlace

Y agregué a mano en el archivo HOSTS de cada máquina los mapeos de nombre a dirección IP, para no tener que poner otra máquina virtual simulando un DNS de Internet. La dirección IP 192.168.0.14 corresponde a la interfaz externa de NAT

Verifico la conectividad con “rd.guillermod.com.ar” para cerciorarme que está todo correcto, antes de probar el Escritorio Remoto

No lo muestro, pero he hecho también la configuración en CL2, por supuesto con otra dirección IP

Comienzo la configuración del cliente de Escritorio Remoto en CL1, ya que debemos indicar que se utilizará “RD-Gateway”

En la ficha “General” no hay nada especial, salvo que tengan en cuenta que hay que ingresar el nombre interno de la máquina a la cual nos conectaremos (rdsh1.ad.guillermod.com.ar)

Pero debemos configurar el uso del “RD-Gateway” como se muestra a continuación

Ingresamos el nombre del “RD-Gateway” acá

Y nos conectamos …

Ahí vemos el mensaje que configuré antes :) Podemos ver que no conviene usar vocales acentuadas :)

En este caso da nuevamente la advertencia de la falta de confiabilidad del certificado. Esto se debe a que como usamos una Autoridad Certificadora propia e interna, no se tiene acceso a la CRL, pero podemos configurar que no se vuelva a mostrar

Y podemos ver que la conexión fue exitosa

Si hacemos una configuración análoga en CL2 veremos que también podemos ingresar exitosamente

Aprovecho para mostrar, por las dudas si alguien no se dio cuenta, que podemos guardar la configuración de la conexión, para evitar tener que escribirla cada vez

Resumiendo lo conseguido en esta nota: hemos configurado y demostrado el acceso externo, a través de una Internet simulada, el acceso de los clientes a Escritorio Remoto, usando exclusivamente protocolo HTTPS

Continuaremos en la próxima nota instalando, configurando y activando el licenciamiento de Escritorio Remoto: “Remote Desktop – Escritorio Remoto: Instalación y Activación de las Licencias (RD-CAL) (Nota 7)”

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Jorge  On 08/04/2016 at 01:16

    Excelente toda la tanda de notas, justo estoy configurando esto en la empresa que laburo, tenia el servidor de licencias parado esperando que compren las rdcal, entre tanto se pasó el periodo de gracia y de un dia para el otro no pude hacer acc remoto ni con la cuenta administrador. Desinstale el rol para reinstalarlo, volvió a conectar y como ahora tengo las licencias quise instalar de nuevo pero me da un error de que no puede instalar el rol Agente de conexión al escritorio remoto. Veré mañana reiniciar el server y volver a intentar. Gracias por el laburo que te tomas para hacer esto. Espero con ansias la 7ma nota. Un abrazo. Jorge

    • Guillermo Delprato  On 08/04/2016 at 12:01

      Hola Jorge, me alegro te sirvan :)
      Respecto al tema del licenciamiento cuando se vence, a veces no es tan facil. He visto mas de una pregunta en los foros de Technet

  • Cristian Fontenla  On 12/04/2016 at 14:52

    En mi empresa tenemos varios servidores que accedemos desde afuera a travez de diferentes puetos RDP. Si utilizara RD-Gateway debo tener los servidores con el puerto por defecto ? o se añadiria a la ruta al escribirlo en el cliente? eso no me queda muy claro.
    Y sobre todo que ventaja me ofrece esto?, como para saber si vale la pena convertir lo que ya tengo.

    Gracias por tu trabajo y el tiempo que le dedicas.

    • Guillermo Delprato  On 12/04/2016 at 16:10

      Hola Crisitian, aunque RDP cifra la información, se obtiene más seguridad si a la vez se lo encapsula en HTTPS
      Además con RD-GAT hay más opciones para configurar y restringir a los clientes
      Y por último viene a solucionar el problema si se utiliza RD-Web Acccess

  • CHOQUE CHOQUE  On 02/06/2016 at 19:36

    tengo un problema con esto no me deja acceder desde afuera me sale un mensaje de error y creo que es por el certificado

    “ESTE EQUIPO NO PUEDE COMPROBAR LA IDENTIDAD DE PUERTA DE ENLACE DE ESCRITORIO REMOTO dominio.com. No es seguro conectarse a servidores que no se pueden identificar”

    porque me sale ese mensaje alguien sabe???

    • Guillermo Delprato  On 03/06/2016 at 08:51

      Justamente, es un problema con RD-Gateway. Revisa los pasos, o pon la pregunta en un foro de soporte, Technet por ejemplo, dando todos los datos que puedas para que te puedan ayudar mejor

  • Coldfran  On 09/09/2016 at 19:50

    Hola Guillermo, buen día!
    He seguido toda la configuración y me funciona muy bien, pe he intentando conectarme por Web Access desde la red externa y no he podido, me muestra la página web con las aplicaciones y la pestaña para conexión a los PC pero me da error, me dice que no se puede conectar al RD-Gateway, falta alguna configuración adicional para Web Access? (ya que en la nota no has probado esta opción)

    • Guillermo Delprato  On 10/09/2016 at 06:40

      Hola Coldfran, tiempo que no te veía por acá :)
      Para acceso desde el exterior con WebAccess se debe conectar directamente, ignorando el RDG. Lo que sí hay que configurar es que en el NAT hay que redirigir la dirección IP externa puerto TCP-443 a la dirección IP interna puerto TCP-443. Revísalo si está bien, tratando de acceder directamente a la interfaz web

      • Coldfran  On 11/09/2016 at 01:19

        Hola, si, estoy retomando el buen camino :)
        Lo estaba haciendo directamente como mencionas pero no me conectaba y salia error del RDG, así que lo removí y lo volví a agregar por si me había saltado algún paso, pero igual me seguía dando el error, reinicié todas las virtuales y el error persistía…, pero al día siguiente lo volví a intentar antes de eliminar toda la infraestructura y por fin conecto sin problemas a las aplicaciones mediante Web Access desde una máquina externa.
        Creo que estos problemas me surgen porque no tengo suficiente memoria para las VMs :(

      • Guillermo Delprato  On 12/09/2016 at 07:48

        No es por falta de memoria, es porque seguramente era tarde y las máquinas estaban fuera de horario de trabajo :D
        Ahora en serio, seguramente el problema estaba en la máquina física, no creo que sea por falta de RAM, se pone todo lento pero debería funcionar. No sé como lo haces o con qué aplicación de virtualización usas, pero yo he montado labs donde los servidores tenían 1024, o aún 512 de RAM. En el aprovechamiento de la RAM suele tener mejor resultado VMware que Hyper-V

  • Julio Maldonado  On 06/04/2017 at 22:07

    Hola Guillermo buenas noches! muy bueno el instructivo. Solo tengo una duda, yo hice un mergue entre este procedimiento y el anterior que hiciste con servidores dedicados por rol. Instale cada rol en servidores dedicados hasta el gateway y por lo visto salio todo muy bien. El problema o duda que tengo es la siguiente, un servidor es el rdweb (que tiene el acceso por web a las app) y otro es el servidor gateway, que tiene un nombre publico, esta todo NATEADO como correspondes, pero al publicarlo solo veo la pagina de inicio de IIS, el rdweb no funciona en ese server, entonces estoy en duda a cual apuntar desde afuera… al mismo tiempo publique el server rdweb y puedo acceder al sitio pero al intentar levantar alguna aplicacion me dice que no encuentra el gateway…
    Entonces nose donde esta el error,… ¿como hace el gateway para mostrar el rdweb?

    gracias.

    slds.-

    [Guillermo] Unifico los dos comentarios

    Me olvide de comentar que tanto mi dns interno como externo apuntan al gateway.

    • Guillermo Delprato  On 07/04/2017 at 06:07

      Hola Julio, es difícil desde acá, habría que revisar muchas cosas más. Y el RD-Gateway es bastante “quisquilloso” :)
      El RD-Gateway, lo que hace es permitir que el tráfico RDP y HHTPS (al RD-Web) que llega encapsulado en HTTPS sea “desencapsulado” al pasarlo a la red Interna
      Por otro lado, no importa el nombre real de RD-Gateway, lo que importa es que el nombre público y el certificado coincidan
      También hay que revisar la configuración al RD-Gateway en el cliente RDP para que lo use
      Si ves la página de inicio del IIS, revisa si cuando pones el URL no te olvidas de poner al final el “rdweb” :)
      Por otro lado, es lógico que si publicas el RD-Web, aunque lo accedas no puedes ejecutar aplicaciones. El motivo es que el RD-Web le dice cuál es el RD al que debe conectarse, y el cliente utiliza RDP (que no está abierto ni nateado)
      Y respecto a lo último, que unifiqué desde el otro comentario, no termino de comprender totalmente, pero lo primero a revisar es que todas las máquinas apunten a un DNS que pueda resolver los nombres necesarios, y el RD-Gateway no es DNS

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: