Requisitos técnicos para la movilidad en Lync Server 2013

 

Última modificación del tema: 2014-07-24

Some information in this topic pertains to Cumulative Updates for Lync Server 2013: February 2013.

Los usuarios móviles se encuentran con varios escenarios de aplicaciones móviles que requieren planeación especial. Por ejemplo, alguien podría empezar a usar una aplicación móvil mientras está fuera del trabajo conectándose a través de la red 3G, cambiar a la red de Wi-Fi corporativa al llegar al trabajo y luego volver a 3G al salir del edificio. Debe planear su entorno para admitir estas transiciones de red y garantizar una experiencia de usuario coherente. En esta sección se describen los requisitos de infraestructura que debe tener para admitir aplicaciones móviles y la detección automática de recursos de movilidad.

Nota

Aunque las aplicaciones móviles también pueden conectarse a otros servicios de Lync Server 2013, el requisito de enviar todas las solicitudes web de aplicaciones móviles al mismo nombre de dominio completo (FQDN) web externo solo se aplica al Servicio de movilidad de Lync Server 2013. Otros servicios de movilidad no requieren esta configuración.

El requisito de afinidad de cookies en los equilibradores de carga de hardware se reduce considerablemente y sustituye la afinidad del Protocolo de control de transmisión (TCP) si usa Lync Mobile entregado con Lync Server 2013. La afinidad de cookies aún se puede usar, pero los servicios web ya no lo requieren.

Importante

Todo el tráfico del Servicio de movilidad pasa por el proxy inverso, independientemente de dónde se encuentre el punto de origen: interno o externo. En el caso de un único proxy inverso o una granja de servidores proxy inversos, o un dispositivo que proporciona la función de proxy inverso, puede surgir un problema cuando el tráfico interno sale a través de una interfaz e intenta entrar inmediatamente en la misma interfaz. Esto suele conducir a una infracción de la regla de seguridad conocida como suplantación de identidad de paquetes TCP o simplemente suplantación de identidad. El anclaje del cabello (la salida y la entrada inmediata de un paquete o serie de paquetes) debe permitirse para que funcione la movilidad. Una forma de resolver este problema es usar un proxy inverso que sea independiente del firewall (la regla de prevención de suplantación de identidad siempre debe aplicarse en el firewall, por motivos de seguridad). La horquilla puede ocurrir en la interfaz externa del proxy inverso en lugar de en la interfaz externa del firewall. Detectas la suplantación de identidad en el firewall y relajas la regla en el proxy inverso, permitiendo así la horquilla que requiere la movilidad.
Utilice el host del Sistema de nombres de dominio (DNS) o los registros CNAME para definir el proxy inverso para el comportamiento de la horquilla (no el firewall), si es posible.

Lync Server 2013 admite servicios de movilidad para clientes móviles de Lync 2010 Mobile y Lync 2013. Ambos clientes usan el servicio de detección automática de Lync Server 2013 para encontrar su punto de entrada de movilidad, pero difieren en qué servicio de movilidad usan. Lync 2010 Mobile usa el Servicio de movilidad conocido como Mcx, introducido con la actualización acumulativa para Lync Server 2010: noviembre de 2011. Los clientes móviles de Lync 2013 usan la API web de comunicaciones unificadas o UCWA como su proveedor de servicios de movilidad.

Configuración DNS interna y externa

El Mobility Services Mcx (introducido con la actualización acumulativa para Lync Server 2010: noviembre de 2011) y UCWA (introducido en la Novedades acumulativa para Lync Server 2013: febrero de 2013) usan DNS de la misma manera.

Al usar la detección automática, los dispositivos móviles usan DNS para buscar recursos. Durante la búsqueda de DNS, se intenta primero establecer una conexión con el FQDN asociado al registro DNS interno (lyncdiscoverinternal).< nombre> de dominio interno). Si no se puede establecer una conexión mediante el registro DNS interno, se intenta realizar una conexión mediante el registro DNS externo (lyncdiscover).< sipdomain>). Un dispositivo móvil interno a la red se conecta a la dirección URL interna del servicio de detección automática y un dispositivo móvil externo a la red se conecta a la dirección URL externa del servicio de detección automática. Las solicitudes de Detección automática externa pasan por el proxy inverso. El servicio de detección automática de Lync Server 2013 devuelve todas las direcciones URL de servicios web del grupo de usuarios, incluidas las direcciones URL del Servicio de movilidad (Mcx y UCWA). Sin embargo, tanto la DIRECCIÓN URL del servicio de movilidad interno como la URL del servicio de movilidad externo están asociados con el FQDN externo de los servicios web. Por lo tanto, independientemente de si un dispositivo móvil es interno o externo a la red, el dispositivo siempre se conecta al Servicio de movilidad de Lync Server 2013 externamente a través del proxy inverso.

Nota

Es importante comprender que la implementación puede constar de varios espacios de nombres distintos para uso interno y externo. El nombre de dominio SIP puede ser diferente del nombre de dominio de implementación interna. Por ejemplo, el dominio SIP puede estar contoso.com, mientras que la implementación interna puede estar contoso.net. Los usuarios que inicien sesión en Lync Server usarán el nombre de dominio SIP, como john@contoso.com. Al dirigirse a los servicios web externos (definidos en el Generador de topologías como servicios web externos), el nombre de dominio y el nombre de dominio SIP serán coherentes, tal y como se define en DNS. Al dirigirse a los servicios web internos (definidos en el Generador de topología como servicios web internos), el nombre predeterminado de los servicios web internos será el FQDN del servidor front-end, el grupo de servidores front-end, el director o el grupo de directores. Tiene la opción de invalidar el nombre de los servicios web internos. Debe usar el nombre de dominio interno (y no el nombre de dominio SIP) para los servicios web internos y definir el host DNS A (o, para IPv6, AAAA) registro para reflejar el nombre invalidado. Por ejemplo, el FQDN predeterminado de los servicios web internos puede estar pool01.contoso.net. Es posible que se webpool.contoso.net un FQDN de servicios web internos invalidados. La definición de los servicios web de esta manera ayuda a garantizar que se observa la localización interna y externa de los servicios, y no la localidad del usuario que los está utilizando.
Sin embargo, dado que los servicios web se definen en el Generador de topologías y el nombre de los servicios web internos se puede invalidar, siempre que el nombre de los servicios web resultante, el certificado que lo valida y los registros DNS que lo definen sean coherentes, puede definir los servicios web internos con cualquier nombre de dominio (incluido el nombre de dominio SIP) que desee. En última instancia, la resolución para el nombre de la dirección IP está determinada por los registros de host DNS y un espacio de nombres coherente.
Para los fines de este tema y los ejemplos, el nombre de dominio interno se utiliza para ilustrar la topología y las definiciones dns.

En el siguiente diagrama se muestra el flujo de solicitudes web de aplicaciones móviles para mobility service y para el servicio de detección automática al usar una configuración DNS interna y externa.

flujo de servicio Mobility con Detección automática

Nota

El diagrama ilustra los servicios web genéricos. Un directorio virtual llamado Movilidad representa los Servicios de movilidad Mcx y/o UCWA. Si no ha aplicado la Novedades acumulativa para Lync Server 2013: febrero de 2013, puede o no tener el directorio virtual Ucwa definido en sus servicios web internos y externos. Tendrá un directorio virtual Detección automática y es posible que tenga un directorio virtual Mcx.
La detección automática y el descubrimiento de servicios funcionan del mismo modo, independientemente de la tecnología de servicios de movilidad que haya implementado.

Para admitir usuarios móviles tanto dentro como fuera de la red corporativa, los FQDN web internos y externos deben cumplir algunos requisitos previos. Además, es posible que deba cumplir otros requisitos, dependiendo de las características que elija implementar:

• Nuevos registros DNS, CNAME o A (host, si IPv6, AAAA) para la detección automática.

• Nueva regla de firewall, si desea admitir notificaciones de inserción a través de la red Wi-Fi.

• Somete nombres alternativos a los certificados de servidor internos y a los certificados de proxy inversos para la detección automática.

• La configuración del equilibrador de carga de hardware front-end server cambia la afinidad de origen.

La topología debe cumplir los siguientes requisitos para admitir el servicio de movilidad y el servicio de detección automática:

• El FQDN web interno del grupo de servidores front-end debe ser distinto del FQDN web externo del grupo de servidores front-end.

• El FQDN web interno solo debe resolverse y ser accesible desde dentro de la red corporativa.

• El FQDN web externo solo debe resolverse y ser accesible desde Internet.

• Para un usuario que se encuentra dentro de la red corporativa, la dirección URL del servicio de movilidad se debe dirigir al FQDN web externo. Este requisito es para el Servicio de movilidad y se aplica solo a esta url.

• Para un usuario que se encuentra fuera de la red corporativa, la solicitud debe ir al FQDN web externo del grupo de servidores front-end o director.

Si admite la detección automática, debe crear los siguientes registros DNS para cada dominio SIP:

• Un registro DNS interno para admitir usuarios móviles que se conecten desde la red de su organización.

• Un registro DNS externo o público para admitir usuarios móviles que se conectan desde Internet.

La URL de detección automática interna no tiene que ser direccionable desde fuera de su red. La dirección URL de detección automática externa no tiene que ser direccionable desde dentro de su red. Sin embargo, si no puede cumplir este requisito para la dirección URL externa, es probable que el cliente móvil no se vea afectado funcionalmente, ya que siempre se intenta primero la dirección URL interna.

Los registros DNS pueden ser registros CNAME o registros A (host, si IPv6, AAAA).

Nota

Los clientes de dispositivos móviles no admiten varios certificados de Capa de sockets seguros (SSL) de diferentes dominios. Por lo tanto, el redireccionamiento CNAME a diferentes dominios no es compatible con HTTPS. Por ejemplo, un registro CNAME de DNS para lyncdiscover.contoso.com que redirija a una dirección de director.contoso.net no es compatible con HTTPS. En esta topología, un cliente de dispositivo móvil necesita usar HTTP para la primera solicitud, de modo que el redireccionamiento CNAME se resuelva a través de HTTP. Las solicitudes posteriores usan HTTPS. Para admitir este escenario, debe configurar el proxy inverso con una regla de publicación web para el puerto 80 (HTTP). Para obtener más información, consulte "Para crear una regla de publicación web para el puerto 80" en Configurar el proxy inverso para la movilidad en Lync Server 2013.
El redireccionamiento CNAME al mismo dominio se admite a través de HTTPS. En este caso, el certificado del dominio de destino cubre el dominio de origen.

Para obtener más información sobre los registros DNS necesarios para su escenario, consulte Resumen DNS: Detección automática en Lync Server 2013.

Requisitos de puerto y firewall

Si admite notificaciones de inserción y quiere que los dispositivos móviles de Apple reciban notificaciones push a través de su red de Wi-Fi, también debe abrir el puerto 5223 en la red de Wi-Fi empresarial. El puerto 5223 es un puerto TCP saliente usado por el Servicio de notificaciones de inserción de Apple (APN). El dispositivo móvil inicia la conexión. Para obtener más información, consulta http://support.apple.com/kb/TS1629 .

Advertencia

Un dispositivo Apple que usa el cliente de Lync 2013 Mobile no requiere notificaciones de inserción.

Tenga en cuenta que si un usuario está alojado en un dispositivo de sucursal con funciones de supervivencia (SBA), se necesitan los puertos siguientes:

• UcwaSipExternalListeningPort requiere el puerto 5088

• UcwaSipPrimaryListeningPort requiere el puerto 5089

Para obtener más información e instrucciones sobre los requisitos de puertos y protocolos para la detección automática, vea Resumen del puerto: Detección automática en Lync Server 2013.

Requisitos de certificado

Si admite la detección automática para clientes móviles de Lync, deberá modificar las listas de nombres alternativos del asunto en los certificados para admitir conexiones seguras de los clientes móviles. Debe solicitar y asignar nuevos certificados, agregando las entradas de nombre alternativo del asunto descritas en esta sección, para cada servidor front-end y director que ejecute el servicio de detección automática. El enfoque recomendado es modificar también las listas de nombres alternativos de asunto en los certificados de los servidores proxy inversos. Debe agregar entradas de nombre alternativo del asunto para cada dominio SIP de su organización.

La reescripción de certificados mediante una entidad de certificación interna suele ser un proceso sencillo, pero agregar varias entradas de nombres alternativos al asunto a los certificados públicos que usa el proxy inverso puede resultar costoso. Si tiene muchos dominios SIP, lo que hace que la adición de nombres alternativos de asunto resulte muy cara, puede configurar el proxy inverso para que la solicitud de servicio de detección automática inicial sobre el puerto 80 use HTTP, en lugar del puerto 443 con HTTPS (la configuración predeterminada). La solicitud se redirige al puerto 8080 en el Director o grupo front-end. Al publicar la solicitud de servicio de detección automática inicial en el puerto 80, no es necesario cambiar los certificados del proxy inverso, ya que la solicitud usa HTTP en lugar de HTTPS. Este enfoque es compatible, pero no lo recomendamos.

Requisitos de Internet Information Services (IIS)

Se recomienda usar IIS 7.5, IIS 8.0 o IIS 8.5 para la movilidad. El instalador del servicio de movilidad establece marcas en ASP.NET para mejorar el rendimiento. IIS 7.5 está instalado de forma predeterminada en Windows Server 2008 R2, IIS 8.0 está instalado en Windows Server 2012 y IIS 8.5 está instalado en Windows Server 2012 R2. El instalador del servicio de movilidad cambia automáticamente la configuración del ASP.NET.

Requisitos del equilibrador de carga de hardware

En el equilibrador de carga de hardware que admite el grupo de servidores front-end, las DIRECCIONES virtuales (VIP) de servicios web externos para el tráfico de servicios web deben configurarse para el origen. La afinidad de origen ayuda a garantizar que varias conexiones de un único cliente se envían a un servidor para mantener el estado de la sesión. Para obtener más información sobre los requisitos de afinidad, consulte Requisitos de equilibrio de carga para Lync Server 2013.

Si planea admitir clientes móviles de Lync solo a través de su red interna de Wi-Fi, debe configurar los VIP de servicios web internos para el origen, tal y como se describe para las VIP de servicios web externos. En esta situación, debe usar source_addr (o TCP) afinidad para las VIP internas de servicios Web en el equilibrador de carga de hardware. Para obtener más información, consulte Requisitos de equilibrio de carga para Lync Server 2013.

Requisitos de proxy inversos

Si admite la detección automática para clientes móviles de Lync, deberá actualizar la regla de publicación actual de la siguiente manera:

• Si decide actualizar las listas de nombres alternativos del asunto en los certificados de proxy inverso y usar HTTPS para la solicitud inicial del servicio de detección automática, debe actualizar la regla de publicación web para lyncdiscover.< sipdomain>. Normalmente, esto se combina con la regla de publicación de la dirección URL externa de servicios web en el grupo de servidores front-end.

• Si decide usar HTTP para la solicitud de servicio de detección automática inicial para que no sea necesario actualizar la lista de nombres alternativos del asunto en los certificados de proxy inverso, debe crear una nueva regla de publicación web para el puerto HTTP/TCP 80, si aún no existe. Si ya existe una regla para HTTP/TCP 80, puede actualizarla para que incluya lyncdiscover.< entrada sipdomain> .