Cerrar
InicioEsquemasEsquemas de red para nuestras implementaciones de Lync Server (Parte IX)

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:

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):

Topologias_Lync_2013_Esquema_9.jpg

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

Topologias_Lync_2013_Esquema_9_1.jpg

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

Topologias_Lync_2013_Esquema_9_3.jpg

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.

Topologias_Lync_2013_Esquema_9_4.jpg

Topologias_Lync_2013_Esquema_9_2.jpg
De esta forma la resolución hacia el dominio interno irá a través de DirectAccess hacia los servidores DNS internos, pero los registros que hemos configurado ahora se resolverán directamente con los servidores DNS de la tarjeta de red del equipo. De esta forma, siempre que esté fuera de la organización utilizará servidores DNS públicos para resolver los distintos registros DNS, de tal forma que las direcciones IP que devolverá siempre serán las públicas del EDGE o Reverse-Proxy que hayamos configurado en su momento. Esto hará que nuestro cliente Lync pueda iniciar sesión en Lync a través del EDGE que es el objetivo, que todo el tráfico de Lync vaya a través del EDGE.

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:

Topologias_Lync_2013_Esquema_9_5.jpg
Ahora ya tenemnos todo preparado para probarlo, simplemente iniciamos sesión en Lync y veremos que se conectará directamente a través del EDGE porque la resolución de nombres resolverá los servicios de Lync con las direcciones IP Públicas  que hemos configurado en el servidor DNS, etc.. También comentaros que cuando el equipo esté dentro de la red local, estas directivas de resolución de nombres no tendrán efecto, puesto que el equipo no estará ejecuanto DirectAccess porque sabrá que está dentro de la red coporativa, por lo que una vez dentro de la red el equipo se conectará a Lync de forma interna.
Cada uno deberá realizar los ajustes necesarios, porque aún podemos hacer muchas más cosas, pero bueno como idea espero que haya quedado clara

Espero que os sea de utilidad!!!

Esquemas de red para
Actualizaciones de S

sbuytrago@asirsl.com

1 COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This