Compartilhar via

Requisitos técnicos para mobilidade no Lync Server 2013

  • Artigo

 

Tópico última modificação: 24-07-2014

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

Os usuários móveis encontram vários cenários de aplicativo móvel que exigem planejamento especial. Por exemplo, alguém pode começar a usar um aplicativo móvel enquanto estiver fora do trabalho conectando-se por meio da rede 3G, alternar para a rede corporativa Wi-Fi ao chegar no trabalho e, em seguida, alternar de volta para o 3G ao sair do prédio. Você precisa planejar seu ambiente para dar suporte a essas transições de rede e garantir uma experiência de usuário consistente. Esta seção descreve os requisitos de infraestrutura que você deve ter para dar suporte a aplicativos móveis e descoberta automática de recursos de mobilidade.

Nota

Embora os aplicativos móveis também possam se conectar a outros serviços do Lync Server 2013, o requisito para enviar todas as solicitações da Web de aplicativo móvel para o mesmo FQDN (nome de domínio totalmente qualificado) da Web externo se aplica somente ao Serviço de Mobilidade do Lync Server 2013. Outros serviços de mobilidade não exigem essa configuração.

O requisito de afinidade de cookie em balanceadores de carga de hardware é drasticamente reduzido e você substitui a afinidade de protocolo TCP se você estiver usando o Lync Mobile fornecido com o Lync Server 2013. A afinidade de cookie ainda pode ser usada, mas os serviços Web não exigem mais isso.

Importante

Todo o tráfego do Serviço de Mobilidade passa pelo proxy reverso, independentemente de onde o ponto de origem está, interno ou externo. No caso de um único proxy reverso ou um farm de proxies reversos ou um dispositivo que está fornecendo a função de proxy reverso, pode surgir um problema quando o tráfego interno está em saída por meio de uma interface e tentando entrar imediatamente na mesma interface. Isso geralmente leva a uma violação de regra de segurança conhecida como falsificação de pacotes TCP ou apenas falsificação. A fixação de cabelo (a saída e a entrada imediata de um pacote ou série de pacotes) deve ser permitida para que a mobilidade funcione. Uma maneira de resolver esse problema é usar um proxy reverso separado do firewall (a regra de prevenção contra falsificação sempre deve ser imposta no firewall, para fins de segurança). O hairpin pode ocorrer na interface externa do proxy reverso em vez da interface externa do firewall. Você detecta a falsificação no firewall e relaxa a regra no proxy reverso, permitindo assim o hairpin que a mobilidade requer.
Use o host DNS (Sistema de Nomes de Domínio) ou registros CNAME para definir o proxy reverso para o comportamento do hairpin (não o firewall), se possível.

O Lync Server 2013 dá suporte a serviços de mobilidade para clientes móveis do Lync 2010 Mobile e Lync 2013. Ambos os clientes usam o Serviço de Descoberta Automática do Lync Server 2013 para localizar seu ponto de entrada de mobilidade, mas diferem em qual serviço de mobilidade eles usam. O Lync 2010 Mobile usa o Serviço de Mobilidade conhecido como Mcx, introduzido com a Atualização Cumulativa para Lync Server 2010: novembro de 2011. Os clientes móveis do Lync 2013 usam a UNIFIED Communications Web API, ou UCWA, como provedor de serviços de mobilidade.

Configuração de DNS interno e externo

O Mcx dos Serviços de Mobilidade (introduzido com a Atualização Cumulativa para Lync Server 2010: novembro de 2011) e o UCWA (introduzidos no Atualizações cumulativo para o Lync Server 2013: fevereiro de 2013) usam o DNS da mesma maneira.

Quando você usa a Descoberta Automática, os dispositivos móveis usam o DNS para localizar recursos. Durante a pesquisa de DNS, uma conexão é tentada primeiro com o FQDN associado ao registro DNS interno (lyncdiscoverinternal.< nome de domínio interno>). Se uma conexão não puder ser feita usando o registro DNS interno, uma conexão será tentada usando o registro DNS externo (lyncdiscover.< sipdomain>). Um dispositivo móvel interno à rede se conecta à URL interna do Serviço de Descoberta Automática e um dispositivo móvel externo à rede se conecta à URL externa do Serviço de Descoberta Automática. As solicitações de Descoberta Automática Externa passam pelo proxy reverso. O Serviço de Descoberta Automática do Lync Server 2013 retorna todas as URLs dos Serviços Web para o pool inicial do usuário, incluindo as URLs do Serviço de Mobilidade (Mcx e UCWA). No entanto, a URL interna do Serviço de Mobilidade e a URL externa do Serviço de Mobilidade estão associadas ao FQDN externo dos Serviços Web. Portanto, independentemente de um dispositivo móvel ser interno ou externo à rede, o dispositivo sempre se conecta ao Serviço de Mobilidade do Lync Server 2013 externamente por meio do proxy reverso.

Nota

É importante entender que sua implantação pode consistir em vários namespaces distintos para uso interno e externo. O nome de domínio SIP pode ser diferente do nome de domínio de implantação interna. Por exemplo, seu domínio SIP pode ser contoso.com, enquanto sua implantação interna pode ser contoso.net. Os usuários que fizerem logon no Lync Server usarão o nome de domínio SIP, como john@contoso.com. Ao lidar com os serviços Web externos (definidos no Construtor de Topologias como serviços Web externos), o nome de domínio e o nome de domínio SIP serão consistentes, conforme definido no DNS. Ao lidar com os serviços Web internos (definidos no Construtor de Topologias como serviços Web internos), o nome padrão dos serviços Web internos será o FQDN do servidor front-end, pool de front-ends, diretor ou pool de diretores. Você tem a opção de substituir o nome dos serviços Web internos. Você deve usar o nome de domínio interno (e não o nome de domínio SIP) para serviços Web internos e definir o registro A do host DNS (ou, para IPv6, AAAA) para refletir o nome substituído. Por exemplo, o FQDN de serviços Web internos padrão pode ser pool01.contoso.net. Um FQDN de serviços Web internos substituído pode ser webpool.contoso.net. Definir os serviços Web dessa maneira ajuda a garantir que a localidade interna e externa dos serviços , e não a localidade do usuário que os está usando, seja observada.
No entanto, como os serviços Web são definidos no Construtor de Topologias e o nome dos serviços Web internos pode ser substituído, desde que o nome de serviços Web resultante, o certificado que o valide e os registros DNS que o definem sejam consistentes, você pode definir os serviços Web internos com qualquer nome de domínio, incluindo o nome de domínio SIP que desejar. Por fim, a resolução do nome para o endereço IP é determinada pelos registros de host DNS e um namespace consistente.
Para os fins deste tópico e os exemplos, o nome de domínio interno é usado para ilustrar a topologia e as definições de DNS.

O diagrama a seguir ilustra o fluxo de solicitações da Web do aplicativo móvel para o Serviço de Mobilidade e para o Serviço de Descoberta Automática ao usar uma configuração de DNS interna e externa.

serviço Mobilidade fluxo usando a Descoberta Automática

cdb96424-96f2-4abf-88d7-1d32d1010ffd

Nota

O diagrama ilustra os serviços Web genéricos. Um diretório virtual chamado Mobility descreve os serviços de mobilidade Mcx e/ou UCWA. Se você não tiver aplicado o Atualizações cumulativo para o Lync Server 2013: fevereiro de 2013, poderá ou não ter o diretório virtual Ucwa definido em seus serviços Web internos e externos. Você terá uma Descoberta Automática de diretório virtual e poderá ter um diretório virtual Mcx.
A descoberta automática e a descoberta de serviços funcionam da mesma maneira, independentemente da tecnologia de serviços de mobilidade que você implantou.

Para dar suporte a usuários móveis de dentro e fora da rede corporativa, seus FQDNs web internos e externos devem atender a alguns pré-requisitos. Além disso, talvez seja necessário atender a outros requisitos, dependendo dos recursos que você optar por implementar:

  • Novos registros DNS, CNAME ou A (host, se IPv6, AAAA) para descoberta automática.

  • Nova regra de firewall, se você quiser dar suporte a notificações de envio pela sua rede Wi-Fi.

  • Nomes alternativos de entidade em certificados de servidor internos e certificados de proxy reverso, para descoberta automática.

  • A configuração do balanceador de carga de hardware do Servidor Front-End altera a afinidade de origem.

Sua topologia deve atender aos seguintes requisitos para dar suporte ao Serviço de Mobilidade e ao Serviço de Descoberta Automática:

  • O FQDN da Web interno do pool de Front-Ends deve ser diferente do FQDN da Web externo do pool de Front-Ends.

  • O FQDN da Web interno só deve resolver e ser acessível de dentro da rede corporativa.

  • O FQDN da Web externo só deve ser resolvido e estar acessível pela Internet.

  • Para um usuário que está dentro da rede corporativa, a URL do Serviço de Mobilidade deve ser endereçada ao FQDN da Web externo. Esse requisito é para o Serviço de Mobilidade e se aplica somente a essa URL.

  • Para um usuário que está fora da rede corporativa, a solicitação deve ir para o FQDN da Web externo do pool de Front-Ends ou Diretor.

Se você for compatível com a descoberta automática, precisará criar os seguintes registros DNS para cada domínio SIP:

  • Um registro DNS interno para dar suporte a usuários móveis que se conectam de dentro da rede da sua organização.

  • Um registro DNS externo ou público para dar suporte a usuários móveis que se conectam pela Internet.

A URL de descoberta automática interna não deve ser enderecável de fora da rede. A URL de descoberta automática externa não deve ser enderecável de dentro da rede. No entanto, se você não puder atender a esse requisito para a URL externa, o cliente móvel provavelmente não será afetado, pois a URL interna sempre é tentada primeiro.

Os registros DNS podem ser registros CNAME ou A (host, se IPv6, AAAA).

Nota

Os clientes de dispositivo móvel não dão suporte a vários certificados SSL (Secure Sockets Layer) de domínios diferentes. Portanto, não há suporte para o redirecionamento de CNAME para domínios diferentes via HTTPS. Por exemplo, não há suporte para um registro CNAME dns lyncdiscover.contoso.com redireciona para um endereço de director.contoso.net por HTTPS. Nessa topologia, um cliente de dispositivo móvel precisa usar HTTP para a primeira solicitação, para que o redirecionamento CNAME seja resolvido por HTTP. Em seguida, as solicitações subsequentes usam HTTPS. Para dar suporte a esse cenário, você precisa configurar o proxy reverso com uma regra de publicação na Web para a porta 80 (HTTP). Para obter detalhes, consulte "Para criar uma regra de publicação na Web para a porta 80" na configuração do proxy reverso para mobilidade no Lync Server 2013.
Há suporte para o redirecionamento de CNAME para o mesmo domínio via HTTPS. Nesse caso, o certificado do domínio de destino abrange o domínio de origem.

Para obter detalhes sobre os registros DNS necessários para seu cenário, consulte Resumo de DNS – Descoberta automática no Lync Server 2013.

Requisitos de porta e firewall

Se você dá suporte a notificações por push e deseja que os dispositivos móveis da Apple recebam notificações por push pela rede do Wi-Fi, você também precisa abrir a porta 5223 em sua rede Wi-Fi corporativa. A porta 5223 é uma porta TCP de saída usada pelo APNS (Apple Push Notification Service). O dispositivo móvel inicia a conexão. Para obter detalhes, consulte http://support.apple.com/kb/TS1629 .

Aviso

Um dispositivo Apple que usa o cliente Lync 2013 Mobile não requer notificações por push.

Observe que, se um usuário estiver hospedado em um SBA (Aparelho de Filial Persistente), as seguintes portas serão necessárias:

  • UcwaSipExternalListeningPort requer a porta 5088

  • UcwaSipPrimaryListeningPort requer a porta 5089

Para obter mais detalhes e diretrizes sobre requisitos de porta e protocolo para Descoberta Automática, consulte Resumo da porta – Descoberta automática no Lync Server 2013.

Requisitos de certificado

Se você for compatível com a descoberta automática para clientes móveis do Lync, precisará modificar as listas de nomes alternativos da entidade em certificados para dar suporte a conexões seguras dos clientes móveis. Você precisa solicitar e atribuir novos certificados, adicionando as entradas de nome alternativo da entidade descritas nesta seção, para cada Servidor Front-End e Diretor que executa o Serviço de Descoberta Automática. A abordagem recomendada é também modificar as listas de nomes alternativos da entidade em certificados para seus proxies reverso. Você precisa adicionar entradas de nome alternativo da entidade para cada domínio SIP em sua organização.

A reedição de certificados usando uma autoridade de certificação interna normalmente é um processo simples, mas adicionar várias entradas de nome alternativo de entidade a certificados públicos usados pelo proxy reverso pode ser caro. Se você tiver muitos domínios SIP, tornando a adição de nomes alternativos de assunto muito caras, poderá configurar o proxy reverso para fazer a solicitação inicial do Serviço de Descoberta Automática pela porta 80 usando HTTP, em vez da porta 443 usando HTTPS (a configuração padrão). Em seguida, a solicitação é redirecionada para a porta 8080 no pool de Diretor ou Front-End. Quando você publica a solicitação inicial do Serviço de Descoberta Automática na porta 80, não é necessário alterar certificados para o proxy reverso, pois a solicitação usa HTTP em vez de HTTPS. Essa abordagem tem suporte, mas não a recomendamos.

Requisitos do IIS (Serviços de Informações da Internet)

Recomendamos que você use o IIS 7.5, o IIS 8.0 ou o IIS 8.5 para mobilidade. O instalador do Serviço de Mobilidade define sinalizadores ASP.NET melhorar o desempenho. O IIS 7.5 é instalado por padrão no Windows Server 2008 R2, o IIS 8.0 é instalado no Windows Server 2012 e o IIS 8.5 está instalado no Windows Server 2012 R2. O instalador do Serviço de Mobilidade altera automaticamente as ASP.NET configurações.

Requisitos do Balanceador de Carga de Hardware

No balanceador de carga de hardware que dá suporte ao pool de Front-Ends, os VIPs (IPs virtuais) dos Serviços Web externos para tráfego de Serviços Web devem ser configurados para origem. A afinidade de origem ajuda a garantir que várias conexões de um único cliente sejam enviadas a um servidor para manter o estado da sessão. Para obter detalhes sobre os requisitos de afinidade, consulte Requisitos de balanceamento de carga para o Lync Server 2013.

Se você planeja dar suporte a clientes móveis do Lync somente pela rede Wi-Fi interna, configure os VIPS internos dos Serviços Web para origem, conforme descrito para VIPs de Serviços Web externos. Nessa situação, você deve usar source_addr afinidade (ou TCP) para os VIPs de Serviços Web internos no balanceador de carga de hardware. Para obter detalhes, consulte Requisitos de balanceamento de carga para o Lync Server 2013.

Requisitos de proxy reverso

Se você for compatível com a descoberta automática para clientes móveis do Lync, precisará atualizar a regra de publicação atual da seguinte maneira:

  • Se você decidir atualizar as listas de nomes alternativos da entidade nos certificados de proxy reverso e usar HTTPS para a solicitação inicial do Serviço de Descoberta Automática, deverá atualizar a regra de publicação na Web para lyncdiscover.< sipdomain>. Normalmente, isso é combinado com a regra de publicação para a URL de Serviços Web externos no pool de Front-Ends.

  • Se você decidir usar HTTP para a solicitação inicial do Serviço de Descoberta Automática para que não precise atualizar a lista de nomes alternativos da entidade nos certificados de proxy reverso, deverá criar uma nova regra de publicação na Web para a porta HTTP/TCP 80, caso ainda não exista uma. Se uma regra para HTTP/TCP 80 já existir, você poderá atualizar essa regra para incluir o lyncdiscover.< Entrada sipdomain> .