Algo que debemos tener en cuenta cuando estamos ante una implementación de Lync, es que a parte de los servidores en donde instalaremos la plataforma necesitaremos una solución de reverse-proxy. Esto lo necesitamos para publicar los distintos servicios web de Lync y otros servidores de nuestra organización:
- Reuniones en línea
- Conferencias telefónicas
- Libreta de direcciones
- Office Web Apps
- Exchange Web Services (EWS)
Existen múltiples fabricantes con soluciones de reverse-proxy, tanto vía hardware como software (F5, KEMP, TMG 2010) y que debemos adquirir. Pero también tenemos alguna solución más «casera» pero funcional como es ARR (Application Request Routing Module), aquí os dejo un enlace para que podáis conocerla en profundidad: http://www.iis.net/learn/extensions/planning-for-arr/using-the-application-request-routing-module. Microsoft no nos obliga a adquirir ninguna solución de reverse-proxy, pero nos muestra los requisitos que debe cumplir para ser compatible con Lync:
- Usar la Capa de sockets seguros (SSL) y la Seguridad de la capa de transporte (TLS) implementadas mediante certificados emitidos por una entidad de certificación pública para conectarse a los servicios web externos publicados del Director, Grupo de directores, Servidor front-end o Grupo de servidores front-end. El Director y el Servidor front-end pueden estar en un grupo de carga equilibrada mediante equilibradores de carga de hardware.
- Poder publicar externamente un sitio web hospedado de forma interna usando su nombre de dominio completo (FQDN).
- Poder publicar todo el contenido del sitio web hospedado. Se puede usar de forma predeterminada la directiva /*, que la mayoría de los servidores web identifica como que significa «Publicar todo el contenido en el servidor web». También se puede modificar la directiva, por ejemplo, /Uwca/*, que quiere decir «Publicar todo el contenido en el directorio virtual Ucwa».
- Debe ser configurable para requerir conexiones de Capa de sockets seguros (SSL) o de Seguridad de la capa de transporte (TLS) con los clientes que soliciten contenido de un sitio web publicado.
- Debe aceptar certificados con entradas de nombre alternativo del firmante (SAN).
- Debe poder permitir el enlace de un certificado a una interfaz o agente de escucha a través del que el FQDN de servicios web externos vaya a resolverse. Se prefiere una configuración de agente de escucha a una de interfaz. Se pueden configurar varios agentes de escucha en una sola interfaz.
- Debe permitir la configuración de control de encabezados de host (Los encabezados host (que también se conocen como nombres de dominio o nombres de host) permiten asignar varios sitios a una sola dirección IP en un servidor web.). Con frecuencia, el encabezado de host original enviado por el cliente solicitante debe pasar de forma transparente, en lugar de modificarse a través del proxy inverso.
- Crear un puente para el tráfico SSL y TLS desde un puerto definido externamente (TCP 443, por ejemplo) a otro puerto definido (TCP 4443, por ejemplo). El proxy inverso puede descifrar el paquete al recibirlo y, seguidamente, volver a cifrarlo en el envío.
- Crear un puente para el tráfico TCP no cifrado desde un puerto (TCP 80, por ejemplo) a otro (TCP 8080, por ejemplo).
- Permitir la configuración para los tipos de autenticación Sin autenticación y Autenticación de paso a través.
Todos los requisitos son indispensables, pero los que he marcado en rojo serían los más importantes a mi entender. En el siguiente esquema trataré de mostraros un reverse-proxy (TMG 2010) que utlizaremos para publicar los servicios web de Lync y las Office Web Apps. Todo ello vía HTTPS para que los usuarios puedan conectarse a los servicios de movilidad y las reuniones en línea con todas las características disponibles.
(pulsa en la imagen para verla a tamaño completo)
Como ya sabemos los servicios Web de nuestro Front-END tenemos dos sitios web, uno para los servicios internos y otro los externos.
Como sabemos las URLs simples configuradas en la topología serán las que se utilicen para conectarse a los distintos servicios web, entre los cuales tenemos las reuniones online (meet.dominio), conferencia telefónica (dialin.dominio.com), servicios web para los dispositivos móvils (lyndiscover.dominio.com y lyndiscoverinternal.dominio.com). Ahora bien, no podemos tener dos sitios web con SSL a la escucha en el mismo puerto (a excepcion de que en Windows Server 2012 utilicemos SNI (Windows Server 2012, Encabezados de Host en SSL con SNI en IIS 8), pero que Lync no los necesita ni utilizará), de ahí que por defecto cuando los instalamos ya están en puertos diferentes:
- Servicios Web Internos
- HTTPS 443
- HTTP 80
- Servicios Web Externos
- HTTPS 4443
- HTTP 8080
Lo normal es que los usuarios se conecten a los distintos servicios por los puertos estándar, de tal forma los usuarios que se conecten desde dentro de la red se conectarán a los servicios web internos y ahí tenemos los puertos 80 y 443 configurados. De esta forma, los usuarios que se quieran conectar al Lync Web App accederán únicamente escribiendo la URL de la reunión sin tener que especificar puerto alguno, puesto que por defecto el puerto para el HTTPS es el 443 y los navegadores será el que utilice. Ahora bien, que ocurrirá con los servicios Web Externos, pues que debemos publicar las distintas URLs desde nuestro reverse-proxy y configurando un cambio de puerto de escucha al de publicación del servidor. Puesto que también queremos que las distintas URLs utlicen puertos estándar y no tengamos problemas con bloqueos de firewalls, etc.. Vamos a ver alguna capturas de pantalla de como se debe configurar la publicación de los distintos servicios web mediante el TMG:
-
Servicios Web de Lync
Escribimos un nombres descriptivo para esta regla de publicación de sitios web y seleccionamos permitir
en función de vuestra topología debéis elegir la mejor opción de la primera pantalla, pero en la segunda sí o sí la primera opción de publicación de sitio web usando SSL
escribiremos el nombre de nuestro servidor de Front-END, el nombre del Pool de servidores Front-END o el FQDN del servidor de Director
En el nombre público escribiremos el fqdn establecido para los servicios web externos definido en la topología, y elegimos el listener HTTPS previsamente configurado con su certificado (Certificados SAN o Wildcard para nuestra implementación de Lync Server)
Importante, debemos elegir la opción No delegación, pero los usuarios podrían autenticar directamente
en la pestaña Nombre Público (Public Name) debemos escribir todos los FQDN de los distintos servicios que vamos a publicar:
-
Conferencia Telefónica: dialin.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
-
Servicio para dispositivos móviles: lyncdiscover.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
-
Reuniones Online: meet.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
-
FQDN de los Servicios Web: pool.dominio.com (las capturas son del dominio ucomsenespanol.com, pero cada uno debe especificar su propio dominio)
Cada uno de vosotros debéis configurar los nombres que tengáis especificados en vuestra topología, por supuesto estos FQDN deben estar creados en los servidores DNS externos como registros DNS de tipo A o CNAME
Otra parte muy importante que debemos tener en cuenta que es la Ruta, por defecto dejaremos que se pueda acceder a cualquier directorio del Sitio Web Externo de los servicios web de Lync. Y por último debemos configuar a que puertos enviaremos las conexiones que recibamos sobre esta regla, recodarmos que el Sitio Web Externo de los servicios Web de Lync utlizan los puertos 4443 para SSL y el 8080 para HTTP. Claramente recomiendo únicamente utilizar SSL, por lo que aquí le indicamos que la conexión se enviará al servidor de destino previamente especificado al puerto 4443. De esta forma, enviaremos las conexiones al sitio web correcto.
Por último podemos pulsar en Test Rule y verificar que todo funciona correcatmente. Logicamente para estar seguros al 100% de que todo está correcto, debemos probar a acceder alguno de los distintos servicios publicados
-
Office Web Apps (WAC)
Con esta configuración cuando tratásemos de publicar alguna presentación de PowerPoint obtendríamos el siguiente error:
Y si vamos al registro de TMG vemos el siguiente error e información que nos ayudará a solventar el problema
Para solventar este problema, debemos realizar la siguiente configuración adicional desde la regla de publicación del WAC
desmarcamos las dos casillas que muestro en verde (con la primera debería ser suficiente)
y ahora si tendríamos acceso a ver el contenido de las presenteaciones de PowerPoint publicadas en Lync
-
Servicios Web de Exchange (EWS)
Una vez configurada nuestra regla de publicación, debemos realizar ciertos ajustes adicionales que os expongo a continuación. Para que todo funcione adecuadamente, debéis tener el Exchange correctamente configurado, DNS Internos y Externos, etc… en la guía de Lync que había publicado en su momento tenéis toda la información al detalle (Guía de Implementación de Lync 2013 Standard en Español)
En la primera configuración hemos elegido una configuración diferentes, pero lo suyo es autenticación básica (no por Exchange sino por lo que va a necesitar Lync de este servicio)
Ahora ya tenemos todos los servicios web publicados de Lync, Exchange y Office Web App para tener nuestra implementación completamente operativa. Como podéis apreciar, la necesidad de un reverse-proxy es vital, puesto que necesitamos poder leer los encabezados de host (Los encabezados host (que también se conocen como nombres de dominio o nombres de host) permiten asignar varios sitios a una sola dirección IP en un servidor web) de las peticiones que nos llegan para enviarlas posteriormente a los servidores internos. Además, también debe poder escuchar por un puerto (443) y enviarlo al servicio de Lync por ejemplo en otro diferente (443). Además, debemos tener muy en cuenta la delegación de la autenticación, etc.. En mi caso las pruebas se han completado con solo listener en HTTPS y su certificado wildcard correspondiente (Certificados SAN o Wildcard para nuestra implementación de Lync Server).
Luego cada uno tendrá que adptar las distintas configuraciones que sean necesarias en su organizacion:
- Autenticación
- Nombres de Dominio
- Direccionamiento IP
- Certificados
Publicar los distintos puertos se puede hacer directamente desde vuetro firewall, pero sino es capaz de leer los encabezados de host solo podréis enviar una petición HTTPS a un servidor, porque un puerto y una misma IP solo se puede publicar hacia un único servidor. Aquí hemos visto que accediendo al encabezado de host podemos distinguir a que servidor queremos enviarle la petición y a que puerto en interno, autenticación, etc… esto con un router o firewall al uso no es posible. Y además, el reverse-proxy debe ser capaz de enviar el encabezado de host que ha recibido al servidor web correspondiente, de tal forma que el servicio web del servidor de destino sea capaz de presentarnos el servicio demandando. Esto con un router o firewall al uso sería imposible, ellos reciben una petición en el puerto xxx y la dejará pasar o no (según tu configuración) al servidor de destino especificado, pero sin más información adicional.
Lo he comentado anteriormente, pero por si no he sido claro, con la configuración del TMG para la publicación de los servicios web de Lync que os he mostrado, ya tendriamos todo publicado, incluso el acceso para la conexión del cliente móvil: (Lync 2013: Publicar los Servicios de Lync Mobile)
Que la necesidad de un reverse-proxy y aquí bien claro lo deja Microsoft (http://technet.microsoft.com/es-es/library/gg398069.aspx)
Por último comentarios, que sí bien Microsoft no nos obliga a adquirir ninguna solución de reverse-proxy si he visto los que nos recomienda
En próximos articulos trataré de probar (que aún no lo he hecho) el IIS ARR y publicaré las experiencias con esta solución
Espero que os se de utilidad!!!
Santiago!!
Quiero agradecerte por compartir tus conocimientos y experiencias que has tenido con lync..
tengo una pregunta.. has realizado la publicación del WAC con algunos Firewall como Juniper, cisco ó palo alto?. Porque estas marcas realizan reverse proxy pero lo hacen a nivel IP, no a nivel de URLS.
La parte del reverse proxy para Lync , por ahorita no tengo problemas, pero en el WAC es mi dolor de cabeza!! solo sube la presentación pero nunca se visualiza .Se queda en el estado de «cargando» y despues de unos minutos muestra error de red..
Si puedes ayudar con eso, te lo super agradecería
Saludos