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

El primer escenario que vamos a ver es el más simple, un escenario típico para empresas de menos de 50 usuarios. Se dispone de pocos recursos para poder disponer de una infraestructura recomendaba, pero que igualmente si contamos con los componentes básicos podemos desplegar nuestra topología de Lync con todos los servicios. A continuación os comento la infraestructura con la que contamos según el esquema de red que se muestra en la imagen (pulsar en el esquema para verlo a tamaño original):

• 1 Controlador de dominio
• 1 Exchange Server 2013
• 1 Front-END de Lync Server 2013
• 1 Edge de Lync Server 2013
• 1 Reverse-Proxy IIS ARR 2.5
• 1 Router
• 1 Switch
• 1 Punto de Acceso Inalámbrico
• 1 Conexión a Internet y una dirección IP IPública
• 1 Subred IP 192.168.0.0 /24 para los equipos de la red
• 1 Subred IP 172.26.0.0 / 29 para las interfaces WAN del EDGE y Reverse-Proxy

Como os comentaba al principio nos centraremos únicamente en la parte de red y los servicios que queremos publicar hacia internet, de tal forma que podamos disponer de todos los servicios operativos desde dentro y fuera de la empresa. Como solo tenemos una dirección IP Pública lo que tenemos que hacer es adaptar nuestra configuración pública de Lync a este entorno, para ello en su momento había publicado un artículo de como podéis publicar los servicios Web de Lync y los del EDGE con una sola IP Pública, aquí os lo dejo para que podáis ver como sería: Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública Pero para realizar esta configuración debemos tener también unos mínimos en cuanto al hardware a utilizar, básicamente a nivel de Router/Firewall. Como es una empresa con menos de 50 equipos, solo tenemos una subred (192.168.0.0 /24) y no tenemos ninguna VLAN  configurada, por lo que es una red básica a nivel de enrutamiento. Ademmás, el Router o Firewall que tengamos tiene habilitado el protocolo NAT para que el resto de equipos de la empresa puedan conectarse a internet a través de el. Hasta aquí todo normal, pero ahora viene lo “complicado” en este entorno, sabemos que el EDGE requiere una configuración específica en cuanto a las direcciones IP que tendrá y que interfaces tiene. El rol del EDGE dispone de una interfaces de red interna y otra externa, y debe tener un rango de direcciones IP diferentes en cada interface. Además, solo puede tener un default gateway y será en la interface externa y además tiene que poder comunicarse con los equipos de la red vía interface interna. Dicho esto, ya nos hemos dado cuenta de el router debe tener la posibilidad de configurar en sus interface interna más de una subred IP, para que los equipos de la red se puedan conectar a Internet vía la subred 192.168.0.0/24 y el EDGE pueda hacerlo por otro rango diferente (yo he puesto que sería una subred 172.26.0.0/29). Como no tenemos posibilidad de crear una DMZ a nivel hardware lo haremos (salvando todas las distancias posible) vía subred. El router deberá soportar NAT en las dos subredes y tomárlas como internas, sino no sería posible esta configuración. De esta a nivel lógico los equipos en la subred 192.168.0.0/24 se podrían conectar a Internet y los de la subre 172.26.0.0/29 también tendrían esa posibilidad. En los routers que nos presta el ISP para darnos acceso a internet suelen tener varios puertos para conectarlo a nuestro swithc local y que así todo los equipos de la red puedan conectarse a internet a través suyo, pero esos puertos son tal cual puertos de switch y no son L3 para poder configurar diferentes subredes IP a nivel de interface. De esta forma, el router tendrá una interface virtual asignada a cualquier interface física de los puertos que tiene disponibles, de tal forma cuando lo conectemos a la red local vía switch nos podemos conectar a cualquiera de las IPs de cada subred cambiando únicamente la subred IP de nuestro PC. No es lo recomendable, pero es la única forma que tenemos de poder simular una DMZ y que el EDGE pueda tener dos interfaces con distintas subredes IP y tenga acceso a internet por una IP diferente a la subred local en donde se encuentran todos los equipos de la red. Explicarlo es un poco lioso, pero la idea es que un router que no tiene soporte de L3 en las interfaces LAN, que no tiene posibilidad de crear VLAN para separar el tráfico entre interfaces, etc.. pueda dar servicio a diferentes subredes IP para que podamos configurar los servicios del EDGE y también el Reverse-Proxy que también tiene dos interfaces que necesitan direccionamiento IP diferente. Aquí os muestro el direccionamiento que podríamos tener en nuestros equipos:

El esquema de conexión sería algo similar a este, conexiones físicas entre el router y los servidores EDGE y Reverse-Proxy y entre el router y el switch de la red local

El route tendría que conectarse por un lado al switch de la empresa para dar servicio a la subred IP 192.168.0.0/24 que es donde están los servidores y estaciones de trabajo, de tal forma que los equipos tienen acceso a Internet. Y por otro lado si es posible dos interfaces de red deberían conectarse directamente a los servidores EDGE y Reverse-Proxy en su interface externa, de esta forma los dos servidores comentados tendrían acceso a Internet igualmente por el mismo router pero con una subred local diferente a la de la red de la empresa. Esto es así, porque necesitamos configurar subredes diferentes en cada interface de red de los dos servidores que vamos a publicar directamente a internet. Y como además, necesitan tener acceso a la red local en donde están los servidores para publicar también sus servicios, por esto tenemos que conectarlo por otra interface al switch de la empresa y que tenemos configurada la subred 192.168.0.0/24. Lo que estamos haciendo no es más que dividir la red en dos subredes y configurar los equipos en un u otra subred en función de nuestro esquema de direccionamiento IP. El rango de IPs podéis poner los que queráis, mientras podáis tener rangos diferentes cada uno que elija los que quiera. Pero siempre es recomendable que para la subred IP que utilizaremos para las interfaces externas tanto del EDGE como del Reverse-Proxy que la subred IP sea lo más pequeña posible, de tal forma que evitaremos (con las herramientas que contamos es lo que hay) tener muchos host en esa subred y que algún usuario pueda cambiarse de subred IP y salir a internet de forma libre si por alguna de las subredes configuradas hemos dejado libre acceso. En este caso la subred de las interfaces externas está limitada a 6 host (/29). Del tal forma que en nuestro caso utilizaremos 3, una para el router, otra para el Reverse-Proxy y 1 para el EDGE. Por lo que quedaría bien ajustado, sobrando tres direcciones IP minimizando el riesgo.

Antes de dar por finalizada la configuración de las distintas subredes IP, deberíamos configurar en el router (si lo soporta) que no permite conexiones entre los equipos de las distintas subredes. Esto es vital para mantener la seguridad entre los distintos equipos de las diferentes subredes, está claro que sino es posible tenemo más alternativas  vía GPO (reglas de firewall locales), pero no es lo más recomendable. Una vez finalizada esta configuración, ya podríamos publicar los distintos servicios de Lync, Exchange, Office Web App mediante el reverse-proxy y EDGE. Para ello se tendrían que configurar las siguientes redirecciones de puertos en el router:

Recordaros que aquí la dificultad estaba en que solo tenemos una dirección IP y no podemos redireccionar un mismo puerto utilizando la misma combinación de misma IP Pública. De tal forma que tenemos que cambiar los puertos estandar de los servicios de Lync para poder publicar los servicios web por el puerto 443, puesto que este puerto es vital para los servicios Web de Lync y Exchange. Además, no podemos cambiarlo porque por ejemplo en el cliente Lync móvil no podemos especificarle el puerto de conexión, por lo que tiene que ir por defecto (HTTPS 443), pero no así los de Lync por lo que los podemos cambiar sin “problema” alguno (Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública)

En vez de utilizar varias IPS y nombres para los servicios, se utilizará el mismo nombre sip.dominio.com (la imagen es de otro artículo) y se utilizarán puertos diferentes al 443. EL 5061 que se utiliza para las federaciones se utilizará también para que los  usuarios puedan iniciar sesión desde Internet, y el resto de puertos se cambia sin problema pero revisad que no ocupéis un puerto que ya está utilizándos en el sistema operativo del servidor. Con esto cambios, debéis revisar el registro DNS de Tipo SRV creado para la autoconfiguración del cliente, porque el puerto para el acceso no es el 443 sino el 5061:

_sip._tls.dominio.com       SRV service location:
priority       = 0
weight         = 0
port           = 5061
          svr hostname   = sip.dominio.com

Con las federaciones no tendréis problema con el registro DNS de Tipo SRV, lo dejáis tal cual se crea por defecto porque se utiliza el puerto 5061

_sipfederationtls._tcp.dominio.com       SRV service location:
priority       = 0
weight         = 0
port           = 5061
          svr hostname   = sip.dominio.com

Como os comentaba el único puerto que no debéis modificar es el 443 para los servicios web, de ahí que se reservarse para redireccionar las peticiones que lleguen al router a ese puerto a la interface externa del Reverse-Proxy.  Por último comentaros, que como el EDGE ya tiene una interface con una dirección IP de la subred LAN (192.168.0.0/24) no necesitáis crear rutas estáticas, que visto alguna configuración así no tiene sentido, está en la misma subred IP y la interface interface tiene el cable de red conectado la switch de la empresa es más que suficiente.

Comentaros que en el Reverse-Proxy no es obligatorio tener dos interfaces  de red con dos subredes IP, funcionaría igualmente si configuráis la subred IP de la LAN (eso si, sino no llegaría a conectarse con los servidores internos) y no tiene porque estar en el dominio para publicar los servicios que utilizar Lync (Servicios Web de los Front-END, EWS de Exchange y Office Web App).

Resumiendo, cuando tenemos los recursos limitados un esquema similar a este hará que os funcionen todos los servicios perfectamente. Crear dos subredes, asignar direcciones IP diferentes a los servidores van a publiar los distintos servicios de la empresa (Reverse-Proxy y EDGE) y redireccionar posteriormente los puertos en el router que tengamos. Si el router no tiene la posibilidad de tener dos IPs privadas, tendríamos que buscar alternativas, que las tenemos. Se podría configurar un servidor para implementar NAT a nivel de Window Server, la interface pública en ese NAT tendría una dirección IP del mismo rango que el router y los equipos de la red tendrían que cambiar a otra subred IP. Esa misma subred IP se tiene que configurar en el segunda tarjeta de red del servidor que hemos configurado con NATA, para que su interface interna pertenezca a la misma subred y pueda conectarse con los equiipos de la LAN (Windows Server 2012, Instalación y Configuración de NAT). De tal forma que la puerta de enlace los equipos de la red seria la interface LAN de ese servidor, y el servidor se encargaría de conectarnos a internet vía la interface externa configurada.

El resto de servicios como DNS, DHCP, etc.. de los distintos servidores no tienen porque modificarse, simplemente que están en la subred IP de la LAN y poco más. El DHCP entregará direccionamiento IP a los equipos, los parámetros importante son DNS (Servidor DNS de la red, lo normal es que sea el controlador de dominio) y el Gateway (tiene que ser la IP privada del router, que para eso hemos configurado dos IPs en el router, una de cada subred). Los servidores de nuestra organización también tienen que tener como puerta de enlace el router que tenemos para darnos conectividad con internet, lo mismo que lo anterior, para eso hemos configurado dos Ips en el router. Una IP para dar servicios a la red local y la otra para las interfaces externas del EDGE y Reverse-Proxy.

Como véis es cuestión de darle algunas vueltas, pero nada complicado si tenemos el hardware adecuado. Hoy en día cualquier router tiene la posibilidad de configurar más de una IP local, etc…  Luego el resto de configuraciones vienen dadas ya por cada producto, pero lo importante es que tengamos claro que con un router, una IP Pública únicamente podemos ofrecer todos  publicar todos los servicios para lync sin problema.

Espero que os sea de utilidad y en breve publicaré el segundo esquema de red: LYNC ON-PREMISES | INFRAESTRUCTURA DE RED | 2 IP Públicas | 1 Subred IP Interna