Esquemas de red para nuestras implementaciones de Lync Server (Parte IX)

Como último esquema de red he querido mostrar otro escenario muy implementado con la llegada de Windows Server 2012, no es más ni menos que usuarios conectados a la red corporativa utilizando DirectAccess. Con DirectAccess los clientes estarán conectados de forma permanente a nuestra organización e iniciar sesión de forma transparente en el dominio, además de estar unido al 100% a la organización. Podremos tener usuarios dispersos por el mundo, pero a su vez se le aplicarán las directivas de seguridad, tendremos acceso a su equipo sin intervención del usuario, el usuario no tiene que conectarse a  ninguna VPN puesto que siempre que el equipo tenga conectividad tendrá conexión vía DirectAccess a la empresa. Desde luego desde la primera vez que he probado DirectAccess he visto una forma diferente de ofrecer seguridad y acceso a los usuarios itinerantes a la red, fácil y transparente para todos (usuarios y técnicos), además de que podemos unir equipos al dominio y configurarlos con DirectAccess sin tener acceso físico al dominio, desde luego una maravilla. Aquí os dejo algunos artículos que había escrito sobre DirectAccess por si queréis iniciaros en este tecnología:

• Windows Server 2012: DirectAccess (Actualizado 15-02-2013)
• Windows Server 2012: DirectAccess en un clúster con Windows NLB
• Cómo unir un equipo a un dominio sin conexión y además configurarlo para DirectAccess
• Como denegar el acceso a la red a equipos conectados vía DirectAccess

Una vez comentado esto, vamos a darle forma a este último esquema de red para nuestras implementaciones de Lync. El esquema de red es el mismo que el artículo anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte VIII)) para aprovecharme de la topología de red y además porque creo que forma parte de uno de los esquemas más comunes entre las empresas (pulsar en la imagen para verla a tamaño completo):

La problemática es la misma que en artículo anterior, debemos evitar que el cliente Lync se comunique con los clientes internos (o externos) vía DirectAccess, puesto que tendríamos problemas de jitter y latencias excesivas para tráfico de media. Por lo que debemos ver como podemos evitar este comportamiento, aquí la solución es más directa por decirlo de alguna forma. Con clientes SSTP teníamos que configurar un GPO para crear directivas de resolución de nombres (NRPT), pero aquí esto ya lo tenemos por defecto cuando implementamos DirectAccess. Esto es así porque es la forma que tenemos de especificarle al equipo cliente que tráfico se enviará vía DirectAccess y cual lo enviará a través de su conexión a Internet. Para ello, desde la consola de administración de acceso remoto en el páso número 3 (Servidores de Infraestructura) debemos añadir los FQDN que no queremos que se resuelvan a través de los DNS internos y si a través de los DNS del equipo en cada momento:

• _sip._tls.asirsl.com
• sip.asirsl.com
• webconf.asirsl.com
• meet.asirsl.com
• pool.asirsl.com
• av.asirsl.com
• lync.asirsl.com
• dialin.asirsl.com

Debemos ir agregando cada sufijo de nombre por individual, puesto que por defecto ya está el nombre dominio al completo que será utilizará el servidor DNS interno para resolver todos los nombres de dominio. En nuestro caso queremos indicarle que nombres no se resolverán a través de DirectAccess, sino a través de los servidores DNS que sean capaces de resolver las direcciones IP Públicas de los servicios de Lync

Escribimos todos los nombres especificados anteriormente y no le damos a detectar, porque si fuese así y el servidor DNS interno lo pudiese resolver (que no es el caso, porque son registros DNS que están en los servidores DNS externos) se añadiría como servidor DNS para resolver ese registros y es justamente eso lo que NO queremos.

Esta configuración es así, porque doy por hecho que el dominio interno y externo coinciden de tal forma que debemos configurar Split-DNS para que podamos resolver sufijos de nombre tanto en interno y externo a la vez en función de lo que queremos. Si el nombre de dominio interno fuese dominiointerno.com y el externo dominio.com, entonces no tendríamos este problema porque el cliente DirectAccess ya resolvería el dominio externo a través de los servidores DNS externos. En muchas organizaciones el nombre de dominio interno y externo coindice (para mi lo ideal, pero no tiene porque ser así), por lo que debemos ser capaces de resolver los mismos nombres pero obteniendo direcciones IP Privadas y Públicas según donde estemos conectados. Si utilizamos DirectAccess, lo que queremos es tener acceso directo a los servicios de la organización de forma transparente, iniciar sesión en el equipo y automáticamente estar dentro de la red y consumir los distintos servicios ya con SSO. Ahora bien, como hemos repetido en varias ocasiones si queremos utilizar Lync deberíamos hacer que las conexiones de media desde los clientes DirectAccess vayan directamente por el EDGE y que los clientes internos también hagan lo mismo para conectarse con los usuarios de DirectAccess. Pues esto es lo que hemos hecho, que los clientes de DirectAccess inicien sesión en Lync a través del EDGE y todo el tráfico de media irá a través del EDGE evitando así que el equipo tenga que cifrar y descifrar cada paquete enviado en las sesiones de media, con el impacto que esto tendría en el equipo y claramente en las comunicaciones que se verían claramente afectadas.

Una vez que hemos configurado DirectAccess a nivel de servidor y de cliente, si editamos (a modo consultar, no debeís modificar nada) la directiva Configuración del cliente de DirectAccess podremos ver con claridad la configuración de directiva de resolución de nombres. Si os fijaís la configuración es diferente a la del artículo anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte VIII)), puesto que esta configuración ya la realizamos para DirectAccess:

Espero que os sea de utilidad!!!