Ahora más que nunca las comunicaciones juegan un papel fundamental en el mundo empresarial, desde recibir el correo en nuestros SmartPhones hasta conectarnos remotamente vía VDI a nuestro equipo personal. Las oficinas o centros de trabajo "permanentes" dejan de ser algo esencial para las empresas, ahora las oficinas son los CPD de los proveedores de servicios de Data Center, nuestras salas de reuniones son las conferencias online de Lync. De ahi que las comunicaciones juegan un papel fundamental en este modelo de negocio, y seguramente en cualquier otro en el cual tengamos usuarios itinerantes. Pero ahora nuestro principal problema es la seguridad y disponibilidad de los servicios. Además, debemos pensar en la "comodidad" de los usuarios para acceder a la información de la empresa, y que el personal de soporte pueda responder con rapidez a las peticiones de los usuarios.

Desde hace muchos años disponemos de diferentes formas de conectarnos a nuestra infraestructura de forma segura, y casi todas ellas pasan por conectarnos mediante una VPN en sus múltiples variantes (IPSec, SSH, SSL, PPTP, SSTP, etc…). Pero esto siempre ha llevado consigo ciertos inconvenientes, como son:

Posteriormente han ido surgiendo nuevas tecnologías o servicios que iban haciendo más sencillo este tipo de implementaciones, cumpliendo por lo menos el objetivo final que era conectarse remotamente a los servidores de la empresa. TS Gateway es uno de esos nuevos servicios que "solucionaba" o  pretendía eliminar la complejidad de las conexiones VPN, además de facilitar la conexión a los usuarios sin que para ello tengamos que comprometer la seguridad de la empresa. Al final no deja de ser una conexión tunelizada hacia servidores RDS exponiendo para ello un servicio bajo el protocolo SSL. Pero en muchas ocasiones queremos que los usuarios remotos trabajen directamente desde sus estaciones de trabajo, lo cual en muchas ocasiones resulta más fácil y ágil. Además, queremos que nuestros equipos del dominio cuando estén físicamente fuera de la organización (si adoptamos el modelo de negocio basado en la nube esto ya es el "por defecto") se encuentren adecuadamente protegidos al igual que nuestros usuarios y su información. Con esta filosofía nació DirectAccess en Windows Server 2008 R2, una tecnología que sin necesidad de VPN nos mantiene conectados a nuestra organización desde antes de iniciar sesión en nuestro equipo. El problema que inicialmente tenía esta tecnología eran los requisitos a nivel de infraestructura, puesto que no todas las empresas podrían optar a esas exigencias técnicas (Requisitos de DirectAccess):

Estos requisitos eran más o menos asequibles por cualquier empresa, el problema era la necesidad de tener direccionamiento IPv6. Puesto que para muchas organizaciones era inviable el adaptar todos los elementos de red y servidores a esta nueva versión de IP.  Está claro que antes o después las empresas cambiarán a IPv6, cuando salió DirectAccess con Windows Server 2008 R2 aún quedaba (y creo que queda) mucho camino por recorrer  en este tema.  Desde luego la tecnología era la adecuada y solventaba todos los problemas de antaño:

Pero con la llegada de Windows Server 2012 todo ha vuelto a dar un giro de 180^o y los requisitos son más asequibles para la mayoría de las empresas:

Una vez que hemos visto muy por encima los requisitos necesarios para implementar Direct Access, vamos a ver su configuración. Primero os muestro el esquema que he montado para este LAB:

Aquí os muetros los datos IP del esquema que utilizaremos en el LAB

 

Ahora debemos elegir la topología de servidor:

Perimetral: debemos tener dos direcciones IP Públicas contiguas (IPv4 o IPv6) si usamos Teredo. Sino utilizamos Teredo podemos utilizar una sola IP v4 o v6

Detrás de un dispositivo perimetral (con dos adaptadores): cada adaptador debe tener una IP v4 o v6, la interface LAN debe ser una IP privada.

Tras un dispositivo perimetral (con un solo adaptador de red): está también detrás de un dispositivo de seguridad pero con una única tarjeta de red, con una IP privada

Nosotros vamos  a escoger la segunda opción y como nombre público para acceder al DirectAccess será vpn.asirsl.com, recordad que este registro DNS debemos tenerlo creado en nuestro servidor DNS externo

Una vez creada la configuración nos muestra el resultado, si existen advertencias nos mostrará cual es el problema. En nuestro caso solo nos comenta que si queremos configurar la opción de multisitio o clúster debemos revisarlo (esto lo veremos en otro artículo)

Nombre del alias: directaccess-WebProbehost

Dirección IP: 192.168.250.96  (DirectAccess)

Podemos elegir las interfaces del servidor para los perfiles externo o interno, además de seleccionar el certificado  autofirmado que utilizaremos para autenticar las conexiones IP-HTTPS. Si queremos utilizar un certificado de nuestra CA debemos desmarcar la casilla Usar un certificado autofirmado…. y seleccionar el certificado que queremos usar desde el almacén de certificados local del equipo. Por lo que previamente debemos instalar el certificado que queremos utilizar, pero si queremos utilizar el autofirmado ya lo tenemos instalado, solo debemos seleccionarlo. Siendo un certificado autofirmado debería mostrarnos una alerta en los equipos clientes porque no será de confianza para el resto de equipos, pero esto se soluciona con la GPO que se ha creado con la configuración del DirectAccess (Configuración del cliente de DirectAccess), que agrega el certificado autofirmado como raíz de confianza para los equipos a los cuales se les aplica la directiva:

Aquí configuramos el split-dns si tenemos el mismo nombre de dominio interno y externo. Podemos definir que host queremos evitar que se resuelvan internamente, si utilizamos Lync debemos establecer las siguientes exclusiones, de tal forma que estos registros el cliente los resolverá en el DNS externo:

Paso 4, configuraremos a que servidores tendrán acceso los clientes DirectAccess

Podemos crear un grupo de seguridad y añadir como miembros a los servidores a los cuales los clientes DirectAccess tendrán acceso

CONFIGURACIÓN, nos muestra el esquema de la configuración del DirectAccess de manera gráfica y podemos editarla en cualquier momento

Ahora debemos configurar ambas opciones, primero vamos a empezar con RADIUS. En mi caso tengo un servidor NPS que utilizo para la autenticación de la red inalámbrica, autenticación de dispositivos de seguridad (Routers, AP, Switchs, etc..) para su administración. La configuración del NPS no la voy a describir en este artículo, únicamente comenta que debemos dar de alta el cliente RADIUS en el NPS que será nuestro servidor de DirectAccess (SRV-DA00). Una vez configurado con su pre-shared-key configuramos el DirectAcces

Configuración del cliente de DirectAccess, configuración aplicada a los equipos que utilizarán DirectAccess y como vemos nosotros la hemos filtrado para que se aplique al grupo de seguridad ACL DA Equipos Remotos

General

 

si ahora vamos al apartado de Asociaciones de seguridad y vamos Modo Principal vemos la conexión completada

si vamos a las propiedades de la conexión veremos como ha identificado la conexión, además podemos ver los registros para tratar de solucionar cualquier problema de conexión.

Si ahora lanzamos un ping a cualquier servidor interno al cual tenemos acceso, debería responder sin problema. Como vemos estamos lanzando un ping a una IPv6 pero que nosotros no hemos configurado, solo hemos dejado habilitar el Protocolo de Internet versión 6. Además en la configuración anterior se ha habilitado NAT64 y DNS64 para la interoperabilidad con nuestra red en la cual solo tenemos IPv4

Como vemos es una maravilla, no tenemos que lanzar la conexión VPN y tenemos todas las funcionalidades como si estuviéramos dentro de la red local. Esto nos permite recibir cualquier cambio  de GPO, actualizaciones mediante WSUS, etc…

Cómo veis es unas maravilla el poder estar conectado desde fuera de la organización y tener acceso desde la misma forma como si estuviéramos dentro de la red. Desde el punto de vista del usuario no tendrá que autenticarse para cada aplicación que quiera conectarse desde Internet, no tiene que conectarse mediante VPN ni tiene que estar conectado a un servido RDS. Desde el punto de vista del personal de IT, tiene múltiples beneficios:

Si dentro de la red de la empresa tenéis varias subredes debéis configurar rutas estáticas en el serivdor de DirectAccess para que pueda llegar a ellas, puesto que en la interface internet no tiene ni debe tener un gateway configurado. En la ruta  estática que creéis debéis especificar la interface por la que se conectará a las otras subredes internas, el comando sería el siguiente:

ROUTE ADD IP_DESTINO MASK MÁSCARA GATEWAY IF Nº_INTERFACE -p

Para conocer el ID de vuestra interface podéis hacerlo escribiendo únicamente el comand router print

Ejemplo: route add 172.21.0.0 mask 255.255.255.0 192.168.250.1 if 25 -p

Creo que sobran los elogios a este servicio porque es una maravilla, y ahora con Windows Server 2012 se nos facilita la posibilidad de instalarlo en casi cualquier cliente por no decir en cualquier cliente.

Espero que os sea de utilidad!!!