El último esquema de red (Esquemas de red para nuestras implementaciones de Lync Server (Parte I)) era algo muy simple, pero que se da en muchos entornos de IT de muchos clientes. Un entorno sencillo, adecuado a la dimensión de la empresa y con escasos recursos de hardware, pero que realizando ciertos ajustes como podéis apreciar se puede implementar Lync otros muchos servicios de forma más o menos sencilla.
En este segundo artículo, tendremos una topología muy parecida a la anterior con la diferencia que ahora tendremos dos IP Públicas y que mostraré dos escenarios diferentes. Uno tendrá un único router con las dos IP Públicas y otro tendremos dos routers, cada uno con una dirección IP Pública y veremos que configuraciones podemos realizar. Empezaremos por el primer escenario, un router dos direcciones IP Públicas (pulsar en la imagen para ver a tamaño real):
En este escenario se nos presenta una mejora con respecto al anterior (Esquemas de red para nuestras implementaciones de Lync Server (Parte I)), que al tener dos IP Públicas podemos publicar alguno de los servicios del EDGE por su puerto nativo. En el EDGE debemos publicar varios servicios:
- Acceso
- Conferencias Perimetrales
- A/V
Como únicamente tenemos una IP Pública para todos los servicios, seguimos sin poder publicar todos los servicios por el puerto nativo (TCP 443), y habíamos publicado todos los servicios cambiando los puertos de cada uno de ellos. Yo en este caso cambiaría el puerto del servicio de Acceso, que se había puesto el 5061 que se comparte con las federaciones. De tal forma que quedaría de la siguiente forma:
Cambiando el puerto 5061 por el 443 por lo menos nos permitirá utilizar el puerto por defecto para la autenticación de los usuarios externos, no suele estar filtrado si nos conectamos desde redes externas y además nos permite filtrado a nivel de Router/Firewall la comunicación con otro extermo federador al utilizar entonces el puerto 5061 únicamente para las federaciones. Tendríamos que tener el registro DNS de Tipo SRV de la siguiente forma:
Servicio de Acceso
_sip._tls.dominio.com SRV service location:
priority = 0
weight = 0
port = 443
svr hostname = sip.dominio.com
Servicio de Federaciones
_sipfederationtls._tcp.dominio.com SRV service location:
priority = 0
weight = 0
port = 5061
svr hostname = sip.dominio.com
Como tenemos dos IP Públicas, utilizaremos una IP para los servicios web de Lync, Exchange, Office Web App y la otra para los servicios del EDGE que hemos comentado. Además, ahora que tenemos dos IP Pública sobre la que utilizaremos para las conexiones del EDGE podremos aplicar restricciones de salida y entrada para permitir únicamente los puertos necesarios para que funcionen todos los servicios (tabla ajustada a la configuración que estamos comentando, cada uno luego tendrá sus propios puertos e IP Públicas):
En cuanto al resto del esquema de red, seguimos con el mismo modelo de doble IP interna en el router, etc.. puesto que la configuración es similar y solo disponemos de un hardware que no permite crear VLAN ni tiene Interfaces L3. Ahora bien, podemos encontrarnos con este esquema algo más avanzado, en el cual el cliente tienes dos routers y cada uno tiene una IP Pública (pulsar en la imagen para ver a tamaño real):
Aquí el modelo de configuración de configuración de doble IP Privada, cambio de puerto del servicio de Acceso en el EDGE es lo mismo que lo visto en el esquema anterior, pero ahora jugamos con la ventaja de que podemos tener dos routers en Alta Disponibilidad o Balanceo de Carga (pulsar en la imagen para verla a tamaño real)
Con esto podríamos configurar los dos routers para que los usuarios de la red local utilizasen ambos routers para salir a Internet o bien tener un modelo de Activo–Pasivo. La configuración en Cisco sería algo similar a esto:
Activo – Pasivo
 |
 |
|
Router1(config)# interface fa0/0
Router1(config-if)# ip address 192.168.0.2 255.255.255.0
Router1(config-if)# standby ip 192.168.0.1
Router1(config-if)# standby preempt
|
Router2(config)# interface fa0/0
Router2(config-if)# ip address 192.168.0.3 255.255.255.0
Router2(config-if)# standby ip 192.168.0.1
Router2(config-if)# standby priority 95 |
Activo – Activo
| |
 |
Router1(config)# interface fa0/0
Router1(config-if)# ip address 192.168.0.2 255.255.255.0
Router1(config-if)# glbp 10 ip 192.168.0.1
Router1(config-if)# glbp 10 priority 120
Router1(config-if)# glbp 10 timers 5 18
Router1(config-if)# glbp 10 load-balancing host-dependent |
Router2(config)# interface fa0/0
Router2(config-if)# ip address 192.168.0.3 255.255.255.0
Router2(config-if)# glpb 10 ip ip 192.168.0.1
Router2(config-if)# glbp 10 preempt
Router2(config-if)# glbp 10 priority 100
Router2(config-if)# glbp 10 timers 5 18
Router2(config-if)# glbp 10 load-balancing host-dependent |
No voy a entrar en el detalle de estas configuaciones, porque se pueden configurar muchas más pero para un escenario básico es suficiente. El que quiera ampliar más información, aquí os dejo los enlaces de Cisco en donde tendréis el material que queráis:
Esta configuración tendrá una VIP (Virtual IP) que será la que se configurará como puerta de enlace (192.168.0.1) a los clientes de la LAN, y ya se encargará HSRP o GLBP de enviar la petición al router que corresponda. Si utilizamos GLBP tendremos los dos routers activos a la vez y podremos aprovechar ambas conexiones. En el caso de HSRP, podríamos implementarlo de tal forma pusiésemos como PASIVO el router que tenga la línea con menos caudal y en caso de caída que el servicios siguiese funcionando. En este caso sería recomendable que el ACTIVO sea el que hemos utilizado para publicar los servicios Web de Lync, Exchange, Office Web App, pero ojo, me refiero como ACTIVO para que los usuarios de la red local puedan salir a internet. En Cisco, al igual que en otras tecnologías, podemos configurar varios protocolos de alta disponibilidad en varias interfaces de un mismo dispositivo, porque lo la configuración se haría solo sobre la subred 192.168.0.0/24, la subred 172.26.0.0/28 la dejaríamos sin configuración de alta disponibilidad (de momento) para que siempre estuviesen operativos ambos routers para ofrecer los distintos servicios (Reverse-Proxy y EDGE). Aquí la idea es gestionar las comunicaciones de los equipos de la LAN para conectarse a internet, pero valorar que router tenemos como activo y cual como pasivo si así queremos la configuración.
El tener dos routers, también nos ofrece la posibilidad de enviar el tráfico de red por el router que queramos, de tal forma que optimicemos en la medida de lo posible las comunicaciones del cliente. Si configuramos HSRP dejando como PASIVO para la red LAN (192.168.0.0/24) el router por donde hemos publicado los servicios del EDGE (Router 2), también garantizamos una conectividad total para los clientes que utilizan el acceso externo. De esta forma, tendríamos una conexión a internet "dedicada" (mientras no se caiga el Router 1) para las conexiones externas. Si elegimos esta configuración, también podemos configurar un TRUNK SIP con un ITSP para cursar las llamadas a la PSTN vía Voip desde nuestro Mediation Serve, para ello configuraríamos una segunda tarjeta de red en el Mediation Server y le configuraríamos una IP del rango 172.26.0.0/28. El Mediation SErver tendría dos interfaces, una conectada a la red local sin default gatewa y una segunda tarjeta de red con un default gateway que apuntará al router R2 que será quien lo conecte con el ITSP. Os recuerdo que el router R2 estaría como PASIVO para la red 192.168.0.0/24 no para la red 172.26.0.0./28. La red 172.26.0.0/28 no tendría configuración alguna de HSRP o GLBP, y sobre esta red en el Router 2 publicaríamos el puerto 5067 (o que el que configuréis) para conectarnos con el ITSP. Aquí os dejo algunos artículos sobre un TRUNK SIP que pueden ser de vuestro interés:
Con esta configuración y sin mucha complación, tenemos Alta Disponibilidad (HRSP) o Balanceo de Carga (GLBP) nuestras líneas de datos para la red local, y además sin un costo superior en hardware hemos optimizado en la medida de lo posible las comunicaciones de A/V de nuestra topología de Lync. Si queremos implementar también HSRP o GLBP para la red de las interfaces WAN del Reverse-Proxy y EDGE podemos hacerlo sin problema, pero de esta forma dejaríamos el tráfico de los servicios Web vía Reverse-Proxy por el Router 1 (172.26.0.1 sería el Gateway de la interface Externa del Reverse-Proxy) y los servicios de Acceso, Conferencia, AV, Federaciones y TRUNK SIP vía Router 2 (172.26.0.2 sería el Gateway de la interface Externa del EDGE). La publicación de puertos se haría en cada uno de ellos, en el Router 1 el puerto 443 para todos los servicios Web y para el Router 2 todos los servicios del EDGE y el TRUNK SIP hacia el Mediation Server. Luego jugaremos con las configuraciones de Alta Disponibilidad o Balanceo y tendremos un sistema torlerante a fallas para la red lan (192.168.0.0./24) y optimizada dentro de las posibilidades del hardware para el EDGE. Pensad que si queremos implementar QoS como mucho podremos configurar a nivel de Router las colas necesarias, pero una vez que el router envíe los datos por su interface WAN ya es el operador quien tiene que darle continuidad (y la misma) al QoS y esto se tiene que pagar a parte, porlo que para una empresa del estilo que comentamos, esto les vendría muy bien tener una configuración similar.
Ahora os cuento porque no hemos configurado de HSRP o GLBP en la red 172.26.0.0/28, básicamente porque para que funcionen los servicios Web y los del EDGE por ambos routers (tendríamos que dejar la configuración de puertos igual que en el artículo anterior: Esquemas de red para nuestras implementaciones de Lync Server (Parte I)). Esto por un lado, por otro tendríamos que configurar los registros DNS apuntando a las dos IP Públicas, y ahí nos encontramos con varios problemas:
-
DNS no ofrece alta disponibilidad, solo consultas "balanceadas" con Round Robin. A algunos usuarios los conectará por una IP y a otros por otra porque así es como le ha resuelto el nombre su servidor DNS de su interface local
-
Si configuramos HSRP las peticiones que llegasen por el router PASIVO no funcionarían, porque el tráfico de retorno que tienen los servidores es el router ACTIVO. Pero igualmente, la petición no se enviaría al la interface Externa del Reverse-Proxy o EDGE, funcionamiento de HSRP
-
Si configuramos GLBP tendremos problemas con SIP y las sesiones, además de que tenemos que tener un proveedor que soporte un TRUNK SIP con dos IP (cualquier proveedor certificado lo soporta) pero tratará una de las IPs como la principal. Esto nos genera otro problema, si utilizamos GLBP las conexiones serían balanceadas a través de los dos routers y tendríamos sesiones en ambas IP Públias
-
Si utilizamos GLBP como el HOST de origen con las conexiones internas siempre es la interface WAN del Reverse-Proxy o EDGE y el destino siempre es el mismo, no tendremos forma de enviarlo por los dos enlaces o decirle a GLBP que utilice un mecanimo de balanceo eficiente.
-
En el TRUNK SIP el Mediation Server si utilizamos HSRP utilizará siempre el router activo y en caso de caída el PASIVO, pero el ITSP tiene que ofrecernos la posibilidad de un failover no solo para cursar la llamada sino sobre todo par las llamadas entrantes (se puede hacer sin problema, pero el proveedor debe tener esa característica). Si utilizamos GLBP no habremos ganado mucho, porque en el TRUNK SIP siempre jugamos con la misma IP del Mediation Server y la misma IP del ITSP, por que aunque configurásemos GLBP en balanceo siempre utilizaríamos el mismo router en cada sesión, etc…
Yo he hablando de HSRP y GLBP porque es lo que utiliza Cisco y es lo que manejo, pero vamos hay más protocolos en función de cada Router/Firewall, etc.. pero también es cierto que los protocolos tienen un funcionamiento claro y eso si que es único para todos.
Espero que os sea de utilidad!!
