Problema con la federación de dominio por socio detectado
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”:
-
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)
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!!!
