El concepto de federación es unas de las cosas que más me gusta de Lync, puesto que nos permite tener contacto con otros usuarios Lync (On-Premises y On-Line) y de sistemas de mensajería público. Su configuración es my sencilla, tanto la federación con otros sistemas de Lync como con sistemas de mensajería públicos, únicamente debemos cumplir una serie de requisitos (Registro DNS de Tipo SRV, Puerto 5061 en TCP, Cerificado Público (para sistemas de IM Públicos es obligatorio, con Lync On-Premises no sería 100% requisito obligatorio) o Privado (para federaciones con Lync On-Premises) , 1 Edge y configurar un directiva para permitir el acceso la federación. Fuera de que sea simple o no, es posible que a veces nos encontremos con algún problema que otro problema, en algunas ocasiones más dífiles que otras de resolverlos. En algunos casos porque no tenemos acceso a toda la infraestructura del cliente (Firewall, DNS) nos encontramos con problemas con cierta "complejidad":
En este caso que os voy a comentar, no tengo acceso a la parte de red (Routers, Firewall, Esquema de la red, etc..) , por lo que os contaré los pasos que he seguido para solucionar e problema en una instalación de un cliente. No ha sido algo muy complicado de solucionar, simplemente se ha tenido que ir dando algunas vueltas por falta de acceso a elementos claves de la red por lo que tienes que ir solicitando ciertas revisiones. El problema básicamente se centraba en que las federaciones automáticas no funcionaban, si configuras una federación de forma manual entonces todo iba perfecto y a la primera, en caso contrario mi EDGE encontrada el EDGE del otro dominio, yo podía ver el estado de un usuario del dominio del cliente pero él no me podía ver a mi, y claramente los mensajes no se podían enviar ni recibir por parte de nadie.
Una vez que verifiqué que todo estaba correcto a nivel de topología, se configuró la federación de forma manual y así todo iba perfecto, pero cuando lo cambiamos y queríamos que fuese por descubrimiento vía DNS no había manera. Desde mi equipo he verificado que los registros SRV estaban creados correctamente, para ello he utilizado nslookup:
nslookup – 8.8.8.8 (consultando a los DNS de Google directamente)
> set type=ns (quiero preguntar por los registros NS del dominio del cliente para que me devuelva los registros DNS el directamente)
> nombre_dominio
"En el ejemplo he puesto mi propio dominio, claramente no puedo mostrar el del cliente, pero para el ejemplo nos servirá "
> exit (salgo del nslookup para ejecutar nuevamente el nslookup pero ya hacia el servidor DNS del dominio del cliente)
nslookup – dns11.servidoresdns.net
> set type=all (para que el NSLOOKUP me responda a las consultas en base a cualquier tipo de registro DNS que le solicite)
> _sipfederationtls._tcp.dominio.com
Al consultarle directamente al servidor DNS (dns11.servidoresdns.net) de nuestro dominio (asirsl.com), me aseguro de que me responde con los datos que el mismo tiene, por lo que no habrá lugar a duda de que Google u otros servidores DNS me puedan mostrar alguna información errónea (cacheada o que no haya sido capaz de resolverlo). Pensad que le estamos solicitando una serie de registros DNS al propio servidor DNS del dominio sobre el cual tiene la zona DNS para nuestro dominio. Con esto vamos descartando problemas, porque ahora otra cosa será de que los DNS públicos a los que yo le consulte por el registro SRV del dominio en cuestión ya lo pueda resolver, pero vamos, seguro que no habrá problema y así fue realmente. Por lo que a nivel de DNS Público no habría problema, ambos servidores DNS Públicos tiene los registros DNS de tipo SRV bien configurado. Por lo que de manera inmediata lo que hice fue verificar los siguientes puntos, teniendo a mano herramientas básicas de diagnótico, pero que siempre muy útiles (pensad que no tenía acceso a los Firewall del cliente, así vamos a ciegas en ese punto):
-
Acceso al puerto 5061 de cada EDGE: para ello lancé un telnet hacia el nombre público del EDGE hacia el puerto 5061 y conectaba sin problema: telnet sip.dominio.com 5061
- Certificados: En este caso los certificados de ambos EDGE son públicos, ya no hay posibilidad de que el certificado no se vea como de confianza desde otro EDGE. Y si así fuese únicamente deberíamos instalar el certificado raiz correspondiente y listo.
-
Topología: se había revisado la topología y todo estaba correcto a nivel de definición del EDGE, de la utilización del EDGE para la federación y la configuración de IP, etc.. estaba todo correcto. Esta parte podíamos obiarla, puesto que la federación manual funcionaba así que ya no había lugar a dudas aqui.
Llegado a este punto y utilizando la lógica si la federación manual funciona, a todos los niveles está funcionando bien a excepción del DNS y el registro SRV. Pero si bien había ejecutado el NSLOOKUP desde mi equipo de trabajo, no lo había hecho desde el EDGE del cliente. Cuando realmente quien debe ser capaz de resolver a través de los DNS el registro SRV del otro dominio el cual quiere federarse vía descubrimiento DNS con nosotros es el EDGE, no nuestro equipo. Yo utilicé mi equipo para realizar las pruebas de forma más rápida y teniendo en cuenta de que no tiene filtrado alguno ni cosas similares, de tal forma que me pueda asegurar que no hay inconveniente alguno. Además, como el EDGE tenia internet sin problemas porque podía navegar, lanzar un telnet hacia el FQDN de mi EDGE, etc.. no había indicios de que el EDGE tuviese algún problema con el DNS. Pero aún así, y teniendo claro que el problema era el DNS y los registros SRV, desde el EDGE del cliente ejecuté un NSLOOKUP y traté de resolver el registro SRV de mi dominio y … TIMEOUT!!!
Ya estaba claro cual era el problema, no teníamos resolución DNS para registros SRV. Ahora bien, volví a ejecutar el NSLOOKUP pero hacia el DNS interno de la red, puesto que quería verificar que podía resolver registros DNS de tipo SRV internos por lo menos. Y tal cual, no tenía problemas en resolver registros SRV internos, pero externo ni uno. Claramente no se puede "acusar" o "asegurar" que el problema está en otro sitio sin antes hacer las pruebas correspondientes. Pero viendo que ni tan siquiera el servidor DNS interno podría resolver registros SRV externos, el "problema" (o exceso de filtrado) tenía que estar en los Firewall del cliente o de su ISP que estaría filtrando las consultas DNS de tipo SRV. Para que mis argumentos tuvieran más peso, ejecuté las Microsoft Lync Server 2013 Debugging Tools y me encontré con esto:
Claramente vemos que el EDGE del cliente no puede encontrar el EDGE para el dominio ASIRSL.COM vía consulta DNS para encontrar los registros SRV (SIPPROXY_E_EPROUTING_MSG_DNSSRV_FAILED)
Y aquí a nivel de conversación vemos claramente que yo encuentro el dominio de cliente, pero cuando tiene que conectarse a mi ya dice claramente que no me encuentra:
Con esto ya tenía suficiente para entregárselo al cliente y que pudies revisar sus firewalls, routers, etc. .y tal cual en unos minutos quitaron algún filtro (el cual desconozo porque se me facilitó esa información) y el EDGE resolvía los registros SRV sin problema. A partir de ahí la federación automática ha funcionado sin problemas.
Luego por curiosidad revisé algunos eventos del EDGE y me encontré con este ID de evento 14499, que más que ayudar me hubiese despistado totalmente. Porque tendrá relación con el problema, pero eso de que "el socio no tiene permiso para enviar o si el socio envía mensajes a dominios de los que esta organización no es responsable" me hubiese llevado a revisar si el dominio SIP estaba configurado en el Lync (claramente si lo estaba), etc…
Por resumir, las federaciones es algo muy sencillo de implementar y buscar los distintos problemas que podamos tener, pero desde luego siempre tirando de conocimiento del funcionamiento de las federaciones. Me refiero en cuanto a los puertos, registros DNS, certificados, etc.. porque teniendo esto claro no tendrás problema en resolver cualquier problema que tengas y que esté a tu alcance. Claramente, el visor de eventos es importantisimo, pero me repito, teniendo el conocimiento del funcionamiento del sistema con herramientas triviales habéis visto que se puede encontrar el problema sin mucha dificultad. Otra cosa será que luego tengamos que adaptar la configuración necesaria, eso ya depende del hardware que tengamos, etc…
Aquí os dejo algunos enlaces a artículos sobre federaciones con Lync:
- Federación y Acceso de Usuarios Externos
- Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones
- Federación con Skype: Problemas con las llamadas de Voz y la Federación
- Federación Lync – Skype: Opciones disponibles para el usuario final
- Federar Lync OnLine con tu Lync On Premise
- Federar Lync 2013 con Google Talk
- Lync Server: Enviar declinación de responsabilidades de archivado a los socios federados
- Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones (Actualizado 12-06-2013)
Los problemas a veces los complicamos nosotros, si tiramos de conocimiento (mejor de que Google :-)) teórico que seguro que encontráis el problema a la primera. Es cuestión de tener claro el concepto de puertos, certificados, DNS, etc.. y el resto vendrá solo.
Espero que os sea de utilidad!!!
