Requisitos técnicos para la movilidad
Última modificación del tema: 2013-03-05
Los usuarios móviles experimentan varios escenarios de aplicaciones móviles que requieren una planeación especial. Por ejemplo, un usuario puede comenzar a usar una aplicación móvil fuera del trabajo conectándose a través de la red 3G y, a continuación, cambiar a la red Wi-Fi corporativa al llegar al trabajo y volver a cambiar a 3G al salir del edificio. Debe planear su entorno para admitir estas transiciones de red y garantizar una experiencia del usuario consistente. En esta sección se describen los requisitos sobre infraestructura que debe cumplir para admitir aplicaciones móviles y la detección automática de recursos de movilidad.
Al usar la detección automática, los dispositivos móviles usan el Sistema de nombres de dominio (DNS) para localizar recursos. Durante la búsqueda de DNS, primero se intenta una conexión con un nombre de dominio completo (FQDN) que esté asociado con el registro DNS interno (lyncdiscoverinternal.<sipdomain>). Si no se puede realizar una conexión usando el registro DNS interno, se intenta una conexión usando el registro DNS externo (lyncdiscover.<sipdomain>). Un dispositivo móvil que es interno respecto a la red se conecta a la URL del servicio de Detección automática interna y un dispositivo móvil que es externo respecto a la red se conecta a la URL del servicio de Detección automática externa. Las solicitudes externas circulan a través del proxy inverso. El servicio de Detección automática Microsoft Lync Server 2010 devuelve todas las URL de Servicios web para el grupo inicial del usuario, incluidas las URL del servicio de movilidad. Sin embargo, la URL interna del servicio de movilidad y la URL externa del servicio de movilidad se asocian al 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 Microsoft Lync Server 2010 externamente a través de un proxy inverso.
Nota
Aunque las aplicaciones móviles también se pueden conectar a otros servicios de Lync Server como el servicio de la libreta de direcciones, este requisito de enviar todas las solicitudes web de aplicaciones móviles al mismo FQDN de web externo solo se aplica al servicio de movilidad. Otros servicios no necesitan esta configuración.
El siguiente diagrama ilustra el flujo de solicitudes web de aplicaciones móviles para el servicio de movilidad y el servicio de Detección automática.
Flujo de solicitudes de aplicaciones móviles para el servicio de movilidad y el servicio de Detección automática
.jpg "cdb96424-96f2-4abf-88d7-1d32d1010ffd")
Para admitir usuarios móviles de dentro y de fuera de la red corporativa, los FQDN de web interno y externo deben cumplir algunos requisitos previos. Además, es posible que deba cumplir otros requisitos en función de las características que decida implementar:
Nuevos registros CNAME o A de DNS para la detección automática
Registro DNS SRV, para la federación con el centro de enrutamiento de notificaciones de inserción
Nuevos puertos para servidores internos
Nueva regla de firewall, si desea admitir notificaciones de inserción a través de la red Wi-Fi
Nombres alternativos de firmantes en certificados de servidor interno y en certificados de proxy inverso para la detección automática
Cambios en la configuración del equilibrador de carga de hardware de Servidor front-end para la persistencia basada en cookies
Nuevas reglas de publicación web en el proxy inverso para la detección automática
Requisitos de sitio web
Su topología debe cumplir los siguientes requisitos para admitir el servicio de movilidad y el servicio de Detección automática:
El FQDN de web interno de Grupo de servidores front-end debe ser distinto al FQDN de web externo de Grupo de servidores front-end.
El FQDN de web interno debe resolverse solamente en la red corporativa y ser accesible desde ella.
El FQDN de web externo (excepto para la URL del servicio de movilidad, que trata con solicitudes de usuario internas y externas) solo se debe resolver y estar accesible desde Internet.
Para un usuario que está dentro de la red corporativa, la URL del servicio de movilidad debe dirigirse al FQDN de web externo. Este requisito es para el servicio de movilidad y se aplica solamente a esta URL.
Para un usuario que está fuera de la red corporativa, la solicitud debe ir al FQDN de web externo del Grupo de servidores front-end o del Director.
Si tiene un entorno DNS de cerebro dividido (split-brain) y los clientes de dispositivos móviles se conectan de forma inalámbrica, debe configurar el FQDN de web externo en el DNS interno con la dirección IP pública.
Requisitos de DNS
Su topología debe cumplir los requisitos de DNS descritos en las siguientes secciones para permitir los servicios de movilidad y el servicio de Detección automática.
Requisito de URL del servicio de movilidad
En la configuración predeterminada, un usuario conectado a la red interna mediante Wi-Fi siempre recibirá la URL del servicio de movilidad externo para su grupo principal. El dispositivo del usuario debe poder consultar la zona DNS interna y resolver el FQDN de servicios web de Lync a la dirección IP de la interfaz externa del proxy inverso. Entonces, el usuario realizará una conexión de horquilla de salida al servicio de movilidad a través del proxy inverso.
Detección automática y requisitos de notificaciones de inserción
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 conectan desde la red de su organización
Un registro DNS externo, o público, para admitir usuarios móviles que se conectan desde Internet
Un registro DNS externo o público para permitir la notificación de inserción
La URL de detección automática interna no debería ser direccionable desde fuera de su red. La URL de detección automática externa no debería ser direccionable desde dentro de su red. Sin embargo, si no puede cumplir este requisito para la URL externa, la funcionalidad del cliente móvil no debería verse afectada, porque la URL interna siempre se intenta primero.
Los registros DNS pueden ser registros CNAME o registros A (host).
Necesita crear el siguiente registro DNS interno:
Registros DNS internos
| Tipo de registro | Nombre de host | Se resuelve en |
|---|---|---|
A (host) |
lyncweb.contoso.com (ejemplo de URL de servicio web externos) |
Registro ubicado en el DNS interno que se resuelve en una dirección IP externa de la URL de los servicios web externos, por ejemplo https://lyncweb.contoso.com |
Y uno de los registros DNS internos adicionales:
| Tipo de registro | Nombre de host | Se resuelve en |
|---|---|---|
CNAME |
lyncdiscoverinternal. <sip domain> |
El FQDN de servicios web interno para su Grupo de directores, si tiene uno, o para su Grupo de servidores front-end si no tiene un Director |
A (host) |
lyncdiscoverinternal. <sipdomain> |
Dirección IP de servicios web interna (dirección IP virtual (VIP) si usa un equilibrador de carga) para su Grupo de directores, si dispone de uno, o para su Grupo de servidores front-end si no dispone de Director |
Debe crear uno de los siguientes registros DNS externos:
Registros DNS externos
| Tipo de registro | Nombre de host | Se resuelve en |
|---|---|---|
CNAME |
lyncdiscover. <sipdomain> |
FQDN de servicios web externo para su Grupo de directores, si dispone de uno, o para su Grupo de servidores front-end si no dispone de Director |
A (host) |
lyncdiscover. <sipdomain> |
Dirección IP externa o pública del proxy inverso |
Nota
El tráfico externo circula a través del proxy inverso.
Nota
Los clientes de dispositivos móviles no admiten varios certificados de capa de sockets seguros (SSL) de distintos dominios. Por lo tanto, la redirección de CNAME a distintos dominios no se admite a través de HTTPS. Por ejemplo, un registro CNAME de DNS para lyncdiscover.contoso.com que se redirige a una dirección de director.contoso.net no se admite a través de HTTPS. En una topología así, un cliente de dispositivo móvil necesita usar HTTP para la primera solicitud, de modo que la redirección de CNAME se resuelva a través de HTTP. A continuación, 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, vea "Para crear una regla de publicación web para el puerto 80" en Configurar el proxy inverso para la movilidad.
La redirección de CNAME al mismo dominio se admite a través de HTTPS. En este caso, el certificado del dominio de destino cubre el dominio original.
| Tipo de registro | Definición | Se resuelve en | ||
|---|---|---|---|---|
SRV |
_sipfederationtls._tcp.<nombre de dominio SIP> al registro del Host A de Servicio perimetral de acceso |
por ejemplo _sipfedrationtls._tcp.contoso.com con el puerto definido de TCP 5061 en sip.contoso.com
|
.gif "important")
Importante:Requisitos de puerto y de firewall
El servicio de movilidad requiere los dos siguientes puertos de escucha de servicios web en Servidores front-end o servidores Standard Edition. Debe definir manualmente estos puertos durante el proceso de implementación usando el cmdlet Set-CsWebServer. Para obtener más información, vea Definir puertos de servidor internos para la movilidad.
También debe crear una regla de permiso para TCP 5061 para la federación con el proveedor en línea para la notificación de inserción. Para obtener más información, consulte Arquitectura de referencia.
Puerto 5086, usado para escuchar las solicitudes de movilidad desde dentro de la red corporativa. Este es un puerto SIP usado por el proceso interno del servicio de movilidad.
Puerto 5087, usado para escuchar las solicitudes de movilidad desde Internet. Este es un puerto SIP usado por el proceso externo del servicio de movilidad.
Si admite notificaciones de inserción y desea que dispositivos móviles de Apple las reciban a través de su red Wi-Fi, también debe abrir el puerto 5223 en la red Wi-Fi de su empresa. El puerto 5223 es un puerto TCP saliente usado por el servicio de notificación de inserción de Apple (APNS). El dispositivo móvil o el servicio de notificación pueden iniciar la conexión, que requiere la disponibilidad de un puerto de salida en la red Wi-Fi empresarial. Para obtener más información, consulte http://support.apple.com/kb/TS1629 y http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
Requisitos de certificado
Si admite la detección automática para clientes móviles de Lync, debe modificar las listas de nombres alternativos de sujeto en los certificados para admitir conexiones seguras desde los clientes móviles. Debe solicitar y asignar nuevos certificados, agregando las entradas de nombre alternativo de firmante descritas en esta sección, para cada Servidor front-end y Director que ejecutan el servicio de Detección automática. El enfoque recomendado es modificar también las listas de nombres alternativos de sujeto en certificados para sus proxies inversos. Debe agregar entradas de nombre alternativo de firmante para cada dominio SIP de su organización.
La reemisión de certificados mediante una entidad de certificación interna suele ser un proceso sencillo, pero agregar varias entradas de nombre alternativo de firmante a certificados públicos usados por el proxy inverso puede ser caro. Si tiene muchos dominios SIP, lo que provoca que agregar nombres alternativos de sujeto sea muy caro, puede configurar el proxy inverso para realizar la solicitud inicial del servicio de Detección automática a través del puerto 80 usando HTTP, en lugar del puerto 443 usando HTTPS (la configuración predeterminada). A continuación, la solicitud se redirige al puerto 8080 en el Director o Grupo de servidores front-end. Al publicar la solicitud inicial del servicio de Detección automática en el puerto 80, no debe cambiar los certificados para el proxy inverso, porque la solicitud usa HTTP en lugar de HTTPS. Este enfoque es compatible pero no se recomienda.
Nota
Para obtener más detalles sobre el uso del puerto 80 para la solicitud inicial, vea "Proceso de detección automática inicial usando el puerto 80" en Requisitos del servicio Detección automática en la documentación de Planeación de usuarios externos.
Nota
Si su infraestructura de Lync Server 2010 usa certificados internos que emite una entidad de certificación (CA) interna y planea admitir dispositivos móviles que se conectan de forma inalámbrica, la cadena del certificado raíz de la CA interna debe instalarse en los dispositivos móviles o debe cambiar a un certificado público en la infraestructura de Lync Server.
En esta sección se describen los nombres alternativos de sujeto necesarios para los siguientes certificados:
Servidor perimetral o Grupo de servidores perimetrales
Director o Grupo de directores
Servidor front-end o Grupo de servidores front-end
Proxy inverso
Descripción |
Entrada de nombre alternativo de firmante |
Servicio perimetral de acceso |
SAN=sip.<sipdomain> |
Requisitos de certificado de grupo de directores
| Descripción | Entrada de nombre alternativo de firmante |
|---|---|
URL de servicio de Detección automática interna |
SAN=lyncdiscoverinternal.<sipdomain> |
URL de servicio de Detección automática externa |
SAN=lyncdiscover. <sipdomain> |
Nota
De forma alternativa, puede usar SAN=*.<sipdomain> solo para los registros de Detección automática (lyncdiscover y lyncdicoverinternal).
Requisitos de certificado de grupo de servidores front-end
| Descripción | Entrada de nombre alternativo de firmante |
|---|---|
URL de servicio de Detección automática interna |
SAN=lyncdiscoverinternal.<sipdomain> |
URL de servicio de Detección automática externa |
SAN=lyncdiscover. <sipdomain> |
Nota
De forma alternativa, puede usar SAN=*.<sipdomain> solo para los registros de Detección automática (lyncdiscover y lyncdicoverinternal).
Requisitos de certificado (CA pública) de proxy inverso
| Descripción | Entrada de nombre alternativo de firmante |
|---|---|
URL de servicio de Detección automática externa |
SAN=lyncdiscover. <sipdomain> |
Nota
Debe asignar este certificado a la escucha de SSL en el proxy inverso.
Requisitos de Internet Information Services (IIS)
Se recomienda que use IIS 7.5 para la movilidad. El instalador del servicio de movilidad define algunas marcas de ASP.NET para mejorar el rendimiento. IIS 7.5 se instala de manera predeterminada en Windows Server 2008 R2, y el instalador del servicio de movilidad cambia automáticamente la configuración de ASP.NET. Si usa IIS 7.0 en Windows Server 2008, debe cambiar manualmente estos parámetros. Para obtener más información, vea Instalar los servicios de movilidad y Detección automática.
Requisitos del equilibrador de carga de hardware
Si su entorno incluye un Grupo de servidores front-end, las IP virtuales (VIP) externas de servicios web en el equilibrador de carga de hardware usadas para el tráfico de servicios web deben estar configuradas para la persistencia basada en cookies. La persistencia basada en cookies asegura que varias conexiones de un único cliente se envíen a un servidor para mantener el estado de la sesión. Las cookies deben cumplir los requisitos específicos. Para obtener más información sobre los requisitos de cookies, vea Requisitos del equilibrio de carga.
Si planea admitir clientes móviles de Lync solo a través de su red Wi-Fi interna, debe configurar las VIP de servicios web internas para la persistencia basada en cookies tal como se describe para las VIP de servicios web externas. En esta situación, no debe usar la persistencia source_addr para VIP de servicios web internas en el equilibrador de carga de hardware. Para obtener más información, vea Requisitos del equilibrio de carga.
Requisitos de proxy inverso
Si admite la detección automática para clientes móviles de Lync, debe crear una nueva regla de publicación web de la siguiente manera:
Si decide actualizar las listas de nombres alternativos de sujeto en los certificados del proxy inverso y usar HTTPS para la solicitud del servicio de Detección automática, necesita crear una nueva regla de publicación web para lyncdiscover.<sipdomain>. También necesita asegurarse de que existe una regla de publicación web para la URL de servicios web externa en el Grupo de servidores front-end.
Si decide usar HTTP para la solicitud inicial del servicio de Detección automática de modo que no deba actualizar la lista de nombres alternativos de sujeto en los certificados del proxy inverso, debe crear una nueva regla de publicación web para el puerto 80 (HTTP).