Esquemas de red para nuestras implementaciones de Lync Server (Parte V)
El esquema es igual que el anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte IV)) pero con la incorporación de las sedes remotas que tenemos conectadas mediante VPN vía IPSec (Cisco VPN IPSec Site-to-Site con Certificados Digitales). En un modelo con una topología simple de Lync, prácticamente no aumenta la complejidad de configuración si añadimos nuevos elementos a la red, estén directamente conectados o mediante VPN (pulsar en la imagen para verla a tamaño completo)
Con respecto al esquema y configuración anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte IV)) únicamente debemos crear una ruta estática en el EDGE para que los usuarios que están conectadas en las sedes remotas se pueden comunicar con usuarios externos. Pensad que los usuarios en las sedes remotas, lo normal es que tengan acceso directo a los servicios que tenemos en la sede central, para esto hemos configurado la VPN entre las sedes. De esta forma, la resolución DNS será interna y como tenemos configurado la VPN, los usuarios de las sedes remotas se conectarán a los distintos servicios de forma “directa”:
- Front-END de Lync
- Exchange Server
- Office Web App
- Dominio
Pero debemos recordar, que cuando un usuario que se conecta de forma directa a los Front-END para conectarse con usuario externos, lo hará si o si mediante el EDGE, esté donde esté el usuario localizado. Siempre que un cliente resuelva el DNS con registros con las direcciones IP internas y se conecte, las conexión externa es siempre a través del EDGE. Ahora bien, como el EDGE tiene la interface conectada a una VLAN interna, debemos configurar la ruta estática necesaria para que pueda llegar a las otras subredes vía VPN. Esto es así, porque como en esa interface NO DEBEMOS configurar un Gateway, tenemos que indicarle quien será el dispositivo de próximo salto para esta interface que podrá llevarlo a la subred indicada:
Como todas las subredes de las VPN pertenecen a la subred 172.20., podemos configurar directamente la ruta estática siguiente: route add 172.20.0.0 mask 255.255.0.0 172.26.1.1 if N. También si queremos podemos afinarlo mucho más con rutas sumarizadas, pero para no complicaros muchos lo dejamos lo más amplio posible. Con esta ruta estática, todas las subredes para la red 172.20.0.0 serían accesibles desde el EDGE sin tener que volver a configurar más rutas estáticas.
Todos los equipos de la red que tienen como servidor DNS, el servidor DNS interno, resolverán el FQDN edge.dominio.com con la IP interna (172.26.1.5) y tienen que ser alcanzable por todos los equipos que se conecten de forma intena. El resto de configuraciones no las completaremos aquí, pero sería básicamente que el enrutamiento estuviese correctamente configurado en los Switchs L3 de la red, sino no tendríamos conexión de forma alguna con las sedes remotas. Pero esto es algo que ya forma parte de la configuración de red, que tendría que realizarse para tener conectividad desde cualquier sede a los servicios centrales y al revés. Si quisiéramos configurar una VPN con Alta Disponibilidad (vamos que los dos routers de la sede Central fuesen los terminados de VPN de las sedes remotas), tendríamos que ir adaptando la configuración y sería más que recomendable utilizar protocolos de enrutamiento (siempre recomendabas para mantener una convergencia de la red lo más óptima posible).
Como véis, si queremos conectar sedes remotas y extender los servicios que se ofrecen en la sede principal, debemos tener en cuanta pocas cosas a nivel de Lync. La conectividad con los Front-END y el resto de host de la red (servidores, equipos, impresoras, ETC..) ya viene implícito con la configuración de la VPN, lo único es que crear la rutas estáticas en el EDGE. También doy por hecho que no tenemos filtrados de algún otro tipo para tener que obligar a los equipos de las sedes a ir por las conexión externa, pero bueno, esto sería más una resolución DNS que no fuesen los servidores internos, entonces los equipos resolverían los nombres públicos de los registro DNS que nos permiten encontrar los servidores de Lync y trataríamos de conectarnos por las interfaces del EDGE y el Reverse-Proxy, etc.. pero vamos, aquí contamos con resolución DNS interna (¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?) y acceso “directo” a los servidores vía VPN con IPSec (Site-to-Site, DMVPN, MPLS, etc..).
Ya nos os comento nada de la configuraciones de los routers (NAT, Puertos, etc..), swtichs, etc.. porque esto debería estar igual que en los artículos anteriores en donde ya teníamos esta configuración de red con varias subredes, etc… aquí solo hemos añadido la sedes conectadas por VPN.
Espero que os sea de utilidad!!!
