Edge Lync: Configuración de Red (Parte I)

En este caso el EDGE está bajo un router Cisco haciendo PAT y tiene un pool de IP Públicas configuradas para ofrecer los servicios de Lync. Lo primero que tenemos que hacer es configurar el port forwarding (abrir  puertos) hacia las IP internas en la cuales tenemos configurados los distintos servicios de nuestro EDGE. Aquí os muestro una tabla de los puertos que debemos tener abiertos desde el exterior hacia nuestro EDGE:

Según el esquema que os muestro deberíamos configurar el port forwarding de la siguiente forma:

Estos son puertos accesibles desde Internet, ahora nos tocaría dar acceso al EDGE a Internet a ciertos protocolos y puertos que son los siguientes:

Desde el ACCESS: DNS, SIP/MTLS y HTTP

Como vemos necesitamos el DNS para poder revolver nombres de dominio, que utilizaremos, por ejemplo para resolver los otros servidores con los que nos queramos federar. Para ello tenemos que poder utilizar el SIP/MTLS y poder conectarnos a través del 5061 del parter con el que queremos federarnos y utilizar la Mutual Authetication. El HTTP no es necesario para Lync pero si para poder acceder a sitios web por ejemplo Windows Update.

Desde el AV: RTP/UDP, RTP/TCP y STUN/UDP

Para el servicio de AV, lo lógico es poder enviar tráfico RTP (Real Time Protocol) para poder emitir nuestro audio y video. Además, del puerto 3478 para que usuarios internos puedan enviar tráfico media a los usuarios externos.

Esto es todo lo que debemos hacer sobre las interfaces declaradas como EXTERNAS en el EDGE. Ahora debemos ver que tenemos que configurar en la interface INTERNA del EDGE. Primero debemos saber algo muy importante sobre equipos de host múltiple (equipos con varias tarjetas de red y rangos de IP diferentes), que por defecto pueden recibir una comunicación por una interface hacia una subred de la otra interface y recibirla o enviarla sin problemas. Esto es un grave problema de seguridad, porque alguien podría querer enviar una petición de conexión con destino una IP del rango de la interface interna pasando por la externa a la cual tiene acceso y podría tener éxito sino lo evitamos.

Os muestro un esquema básico de un host seguro habilitado en la interfaz de origen

Windows XP y Windows Server 2003 usan el modelo de host no seguro para envíos y recepciones de todas las interfaces IPv4 y el modelo de host seguro para envíos y recepciones de todas las interfaces IPv6. Este comportamiento no se puede configurar. La pila TCP/IP de  Windows Vista y Windows Server 2008 es compatible con los envíos y las recepciones de host seguro tanto para IPv4 como para IPv6 de forma predeterminada en todas las interfaces salvo para la interfaz de túnel Teredo para una retransmisión específica del host Teredo. Para configurar este comportamiento tenemos los siguientes comandos:

• netsh interface ipv4 set interface [Nombre_Interface] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [Nombre_Interface] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [Nombre_Interface] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [Nombre_Interface] weakhostreceive=enabled|disabled

Esto da para otro artículo, así que lo dejaremos aqui. Solo comentar que si queremos aportar algo más de seguridad sobre esto asunto podemos trasladar la interface INTERNA del EDGEA a una VLAN diferente y aplicar las medidas de seguridad necesarias.

Una vez comentado todo este “rollete” vamos a ver que puertos debemos permite desde la red INTERNA del EDGE  hacia la red Interna:

Como vemos tenemos que permitir varios protocolos,  unos hacia la red interna (o distintas subredes internas de nuestra LAN) y el Front-END. Las conexiones con el Front-END son las siguientes:

Una vez que esto lo tenemos correctamente configurado, bien sea con el FW de Windows o un Router o un Firewall por hardware o software, debemos tener en cuenta una cosa muy importante. Si tenemos subredes dentro de nuestra red, debemos hacer que sean alcanzables por nuestra interface INTERNA del EDGE, sino cuando intentemos algo diferente a la IM nos dará un error. Como la interface INTERNA NO debe tener configurado un gateway debemos crear las correspondientes rutas estáticas. Vamos a plantear un hipotético caso de que tenemos en una red local las siguientes subredes:

172.29.0.0 /16

172.30.0.0 /16

172.31.0.0 /16

………………….

Lo que debemos tener muy claro es que cuando creemos la ruta estática en el EDGE debemos indicarle porque interface debe llegar a dichas subredes, para eso primero identificaremos cual es las interface que tiene configurado la IP interna. Esto lo hacemos con el comando ROUTE PRINT:

Os muestro las interfaces que nos muestra el comando route print y os remarco el número con el cual el sistema identifica cada interface

Si por el nombre no identificamos la Interface solo tenemos que ir al centro de redes y recursos compartidos y ver las interfaces que tenemos:

Aqui vemos que la interface interna es la “Adaptador de red Microsoft Hyper-V #11, y en el router print la identica con el código 26, por lo que el comando quedaría así para llegar a la subred 172.29.0.0 /16

route add 172.29.0.0 mask 255.255.0.0 192.168.250.62 if 26

Nuestro gateway es el 192.168.250.62 y la interface por la que le indicamos como vamos a llegar es por la 26 que se corresponde con la interface que tiene la IP INTERNA del EDGE. Si solo tuviéramos una subred local y estuviese en el mismo rango que nuestra interface INTERNA del EDGE no tenemos que hacer nada, en caso contrario SI

Una vez que hemos introducido el comando, el resultado es el siguiente:

Como vemos la subred IP de destino es la 172.29.0.0/16 el GW es la IP 192.168.250.62 y la interface la Interna con la IP 192.168.250.39, y con esto tenemos todo en cuanto a comunicación IP se refiere y filtrados.

Para terminar este artículo y que no quede sin comentar la parte de DNS, recordaros que debéis tener los siguientes DNS Internos y Externos configurados:

También se necesitan los registros SRV necesarios:

Autodescubrimiento del servidor por parte del cliente Windows de Lync: _sip._tls.dominio.mcom

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

Os recuerdo que para que los usuarios externos puedan conectarse con los internos, debe existir un registros DNS Tipo A que haga referencia a la IP INTERNA del EDGE, muy importante sino no funcionará la conexión!!!

En cuanto a la resolución de nombres solo me falta comentaros que para que el EDGE pueda resolver nombres internos (que obligatoriamente solo necesita el del Front-END o Pool) debemos editar el fichero HOST de nuestro EDGE, PORQUE NO DEBE TENER NINGÚN DNS CONFIGURADO

Como veis yo tengo un registro más que me resuelve el nombre de la CA para poder solicitar online los certificados a mi CA interna (si la tenéis).

El resto de configuraciones de Topología, Certificados, etc.. lo comentaré en otros artículos una vez que termine con los dos siguientes a este sobre la implentación de un EDGE de Lync en cuanto a la parte de Red

Espero que os sea de utilidad y si queréis que ampliemos información o hable de otra tema, dejar vuestros comentarios por favor!!!