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

En los últimos dos esquemas de red para nuestras implementaciones de Lync vamos a meter en juego a los clientes VPN (SSTP, PPTP, etc..) y DirectAccess, algo muy común en empresas que están comprometidas con la seguridad de los usuarios itinerantes y en la seguridad en general. Muchas empresas ofrece acceso remoto a los servicios IT de la compañía mediante conexiones VPN, bíen con tecnología Microsoft o de otros fabricantes (Cisco, 3Com, HP, etc…). En nuestro caso vamos a centrarnos en un escenario con clientes VPN vía SSTP (Windows Server 2012, Configuración VPN con SSTP, Windows Server 2012: VPN SSTP con NAP) con Windows 7/8 que se conectarán a la red corporativa vía VPN para consumir los distintos servicios que tiene la compañía (Exchange, SharePoint, Ficheros, CRM, ERP, etc..). Además, también la empresa tiene distintas sedes conectadas mediante VPN Site-to-Site (Cisco VPN IPSec Site-to-Site con Certificados Digitales) para ofrecer servicios a sus distintas sedes (pulsar en la imagen para verla a tamaño real):

Inicialmente contamos con la misma infraestructura de red que el esquema V (Esquemas de red para nuestras implementaciones de Lync Server (Parte V)), por lo que la configuración del entorno de red no viará. Ahora como hemos introducido los clientes VPN, debemos tener en cuenta varios aspectos importantes como son:

Vamos por partes, todos los que llevamos implementaciones de Lync sabes que no necesitamos (ni recomendamos) estar conectados vía VPN a la empresa para utilizar Lync con todas sus funciones disponibles, para ello tenemos un rol llamado EDGE que nos permite tener acceso a Lync sin tener que para ello establecer una VPN. Microsoft no recomienda establecer una VPN previa para iniciar sesión en Lync, porque tendríamos problemas con el jitter y la latencia de red, puesto que el equipo debe cifrar y descrifrar cada paquete a enviar y recibir de la red de servidores de Lync. Para ello, Microsoft ha preparado el ROL de EDGE que permite justamente esto, conectarnos desde internet sin tener que utilizar una VPN, pero esto no quiere decir que no podamos tener conexión VPN hacia la red corporativa y a la vez conectarnos a Lync vía Internet sin pasar por la VPN, como si se tratase de un usuario externo. De tal forma que utilicemos la conexión VPN para acceder a los servicios de la compañía y a su vez a través del EDGE nos podamos conectar a Lync y disponer de todos los servicios. Pensad que Lync ya tiene su propio sistema de cifrado (TLS, MTLS, SRTP), de ahí que no necesite añadirle una segunda capa de seguridad que podría afectar al rendimiento  de las comunicaciones (RTP, etc). Teniendo esto en cuenta, veamos como podemos hacer para que los clientes que se conectan por VPN puedan a su vez estar conectados al dominio (vía VPN) y utilizar los servicios de Lync como un usuario externo a todos los efectos (a través del EDGE). Para ello debemos familiarizarnos con varios terminos, uno es el Split-Tunneling, evitando así que todo el tráfico de nuestro equipo una vez conectado a la VPN pase por la sede central. Lo que queremos es definir que tráfico si queremos que vaya por la VPN y cual no, para esto debemos implementar Split-Tunneling. Esto es un proceso que en cada fabricante se realiza de “forma diferente”, por lo que no voy a entrar en esto ahora (si alguien tiene curiosidad de como implementarlo, por favor dejar un comentario). Una vez conectados a la VPN lo más normal es que la resolución de nombres sea a través de los servidores DNS internos, que llegaremos a ellos mediante la VPN, de tal forma que podamos conectarnos a los servicios internos a través de sus direcciones IP internas resolviendo sus direcciones IP a través del servidor DNS interno. Hasta aquí todo correcto, pero que ocurre cuando nuestro dominio SIP es igual que el dominio interno y externo de la compañia? pues que aparentemente tendremos un problema, puesto que un equipo conectado a la VPN tratará de buscar los registros DNS (¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?) necesarios para iniciar sesión en Lync a través del servidor DNS interno. Esto lo que hará es resolver las direcciones IP internas de los servidores de Lync, justamente lo que no queremos para los clientes VPN si queremos que utilicen el EDGE como vía de acceso para iniciar sesión en Lync. Para ello tenemos dos alternativas:

La configuración manual no tiene sentido, por varias razones: 1 es un cambio manual en los equipos que utilicen la conexión VPN (no tiene sentido), 2 solo podemos configurar registros tipo A si fuese un servidor DNS, por lo que tampoco nos vale si queremos utilizar el descubrimiento automático de los servidores de Lync (¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?). Por lo que debemos irnos a una configuración automática que se desplegará en todos los portátiles de la organización (en donde se utilice la conexión VPN) a través de Directivas de Grupo y configurando las Directivas de Resolución de Nombres (NRPT). Esto es algo que también utiliza DirectAccess (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) para indicarle al equipo que tráfico se enviará a través del túnel IP-HTTPS o irá directamente a través de Internet. La idea es que un equipo conectado a la VPN tenga claro que servidor DNS deberá utilizar para resolver las consultas DNS de nuestro equipo, si el servidor interno al cual llegaremos vía VPN o utilizará servidores DNS específicos para la resolución de nombres públicos pero como el mismo dominio que el dominio interno. Aquí un ejemplo, queremos que el registro internet.dominio.com se resuelva vía el servidor DNS interno y el registro meet.dominio.com (registro DNS que existe en interno) se resuelva con la IP Pública que hemos configurado en el DNS externo. Para ello el equipo debe tener claro como resolver  los distintos registros DNS, esto lo haremos creando una GPO aplicada únicamente los equipos que utlicen la conexión VPN. Para ello creamos una directiva de Grupo, la editamos y nos vamos a Configuración del Equipo – Directivas – Configuración de Windows – Directiva de resolución de nombres, lo que debemos hacer es crear los registros DNS que queremos que sean resueltos por un servidor DNS determinado. En este caso configuraremos los registros DNS que necesita un cliente Lync cuando está conectado a través de Internet, simplemente creamos una regla por cada FQDN tal cual os muestro en la siguiente captura  desde la pestaña de Servidor DNS Genérico:

FQDN: Escribimos el nombre del registro DNS que el equipo debe resolver

Habiltar la configuración DNS: Debemos añadir la dirección IP del servidor DNS que queramos utilizar para resolver el nombre especificado en la sección de ¿A qué parte del espacio de nombres se aplicará esta regla?

Una vez que hemos introducido el nombre y dirección IP del servidor DNS que resolverá este FQDN, pulsamos en  Crear

Ahora ya tenemos nuestra primera directiva de resolución de nombres, debemos hacerlo así con todos los registros necesarios:

• _sip._tls.dominio.com
• sip.dominio.com
• webconf.dominio.com
• meet.dominio.com
• pool.dominio.com
• av.dominio.com
• dialin.dominio.com
• lyncdiscover.dominio.com
• mail.dominio.com

Yo además de los registros de Lync, también he aprovechados para hacer lo mismos con el servidor de correo (Exchange: mail.dominio.com), pero vosotros podéis evitarlo sino habéis publicado el Exchange hacia internet. Con esto, ya tenemos resuelto  uno de los problemas, pero aún así tenemos otro problema, que el cliente de Lync si podrá resolver los registros DNS internos a través del servidor DNS interno al cual estamos conectados mediante VPN. Para resolver esto, tenemos que hacer que el protocolo ICE (Interactive Connectivity Establishment) entre en acción, para los que no tengáis claro que hace ICE (http://tools.ietf.org/html/rfc5245), básicamente lo que permite es decidir al cliente Lync si puede establecer una ruta de conexión entre usuarios de Lync en una sesión de media, transferencia de ficheros, compartir escritorio, etc..  o deben utilizar el EDGE para ello (explicación muy muy muy reducida). En Lync tenemos la parte ICE Cliente (Cliente Lync de Windows, Front-END AVMCU, Mediation Server, etc..) y como servidor el EDGE. Además ICE provee dos niveles de protocolo, el STUN (permite al cliente ICE el cual está detrás de un dispositivo NAT descubrir la IP pública que tiene para enviársela al otro cliente para conectar vía IP Públicas) y el TURN (permite al ICE Server (Edge en nuestro caso) especificar su propia IP Pública para actuar como enlace entre dos o más clientes para las sesiones de datos, media, etc..). De ahí que si hemos iniciado sesión en Lync a través de un dispositivo (router, firewall, etc..) que esté haciendo NAT y queremos iniciar una transmisión de datos con otro usuario de Lync tratará de hacerlo de forma directa, pero si ambos clientes están en oficinas diferentes sin conexión directa ambos serán conectados entre sí vía EDGE. En el caso de que estuviesen conectadas ambas oficinas vía VPN (Cisco VPN IPSec Site-to-Site con Certificados Digitales) la comunicación no pasaría por el EDGE puesto que tienen la posibilidad de conectarse directamente y previamente se ha verificado por parte del cliente. Ahora bien, sino se pueden conectar de forma directa entonces utilizarán el EDGE, y ahí está la clave con el cliente VPN y las sesiones de media en ese momento. Una vez que nos hemos conectado a  la VPN, lo normal es tener acceso a las subredes IP de la organización, por lo que tendríamos acceso a comunicarnos vía IP con el resto de equipos de la empresa. Por lo que, una vez que quisiéramos hablar con algún usuario de Lync que esté dentro de las oficinas, el tráfico de media iría directamente a través de la VPN y eso es lo que queremos evitar. Dicho todo esto (un poco enrollado), lo que debemos hacer es evitar que puedan tener comunicación entre los clientes VPN y los clientes de la red local y además los servidores de Lync. Si utilizamos Split-Tunneling debemos definir las diferentes reglas para evitar que se llegue desde los clientes VPN hacia las diferentes subredes (Clientes y Servidores Lync), pero sino es así lo que debemos hacer es configurar una nueva directiva de Grupo configurando el firewall local de los equipos para bloquear el acceso a la subred de VPN (equipos internos) por un lado y por otro a la red local (equipos de la VPN). Su configuración es muy sencillla, simplemente creamos una directiva de grupo la cual tendrá una regla de Firewall que evitará tener acceso a la red local y a los clientes VPN, de tal forma que cuando un usuario de Lync inicie una sesión de datos o media en los siguientes sentidos debemos bloquearla para que entre en acción ICE:

• Cliente VPN –> Cliente Red Local
• Cliente Red Local –> Cliente VPN
• Cliente VPN –> Cliente VPN

No lo había comentado, pero tenemos el mismo problema de jitter y latencia entre clientes VPN, por lo que debemos hacer diferentes reglas evitando también el tráfico directo entre clientes VPN. Porque al final, todo el tráfico VPN debe ser cifrado y descrifado en tiempo real, impactando de manera directa en el rendimiento de la sesiones de  audio de los clientes Lync. Una vez comentado esto, veamos las diferentes directivas a crear para los diferents clientes, pero antes os muestro las diferentes subredes IP para tener claro el funcionamiento de la directiva de Firewall:

• Clientes VPN: 10.100.100.0/24
• Clientes Red Local: El resto de subredes expuestas en el esquema

Ahora crearemos varias directivas de grupos aplicadas a los distintos equipos en función de cual sea su ubicación física:

Clientes Red Local (usuarios que están en las oficinas centrales de la empresa en donde están los servidores de Lync y a donde se conectan los clientes VPN)

Como queremos que todo el tráfico de Lync entre los clientes VPN y la red local se derive hacia el EDGE, elegiremos directamente que la regla de firewall se definirá a nivel de programa:

Escribimos la ruta del ejecutable del cliente Lync:

Cliente Lync 2010: %ProgramFiles%\Microsoft Lync\Communicator.exe

Cliente Lync 2013: %ProgramFiles%\Microsoft Office\Office15\Lync.exe

Elegimos Bloquear la conexión

Escribimos un nombre lo más descriptivo posible para que sea fácil reconocible y pulsamos en Finalizar

Ahora nos queda ajustar algo más la regla definiendo el ámbito, en este caso como se aplica a equipos locales no nos importa la IP local (si tenemos subredes sobre todo para no tener que declaralas de forma manual) y si especificamos la Direción IP Remota que será la subred de los clientes VPN

Igualmente elegimos que la regla se apliará al tráfico originado por el cliente Lync

El tipo de protocolo será cualquiera (TCP, UPD) y pulsamos en Siguiente

El perfil de la red será la de dominio porque será el perfil que por defecto se configure cuando establezcamos la VPN y pulsamos en Siguiente

Ahora ya tendremos bloqueado el tráfico desde los clientes VPN hacia la red local, vía interface de acceso remoto, en el ámbito de dominio y como destino las subredes internas de la VPN. Por último nos faltaría bloquear el acceso entre sí de los clientes VPN para evitar lo mismo de siempre, el cifrado y descifrado del tráfico de red generado con las sesiones de Lync. La regla sería la misma que la de Clientes VPN hacia Red Local pero cambiando las subredes y que ambas sean la red VPN:

Ahora se aplicarán a los equipos vía Active Directory y ya tendríamos lo que queremos, evitar que el tráfico de datos o media entre usuarios de Lync en distintas ubicaciones (Clientes VPN, Red Local) tengan comunicación directa y vayan a través del EDGE. Comentaros que esto también deberíamos hacerlo para las sedes conectadas de forma permante con relación a los clientes VPN, sino los clientes VPN se conectarían a través de la VPN. Pero aquí se supone que con el Split-Tunneling ya le hemos definido únicamente el tráfico permitido (subredes IP). Yo creo que la idea está clara, filtrar el tráfico de los clientes Lync entre los clientes VPN y el resto de usuarios que están dentro de la sede principal o conectadas vía VPN permanentes y que todo vaya a través del EDGE. Pero recordad sería para evitar el cifrado y descrifado del tráfico de los clientes VPN de acceso remoto, no de los que están conectados mediante VPN configurada con ROUTERS o FIREWALLs, porque ya son los equipos de seguridad quienes realizan el cifrado/descifrado y no tendremos problemas.

Espero que os sea de utilidad!!