A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
O Acesso Móvel e Remoto (MRA) é uma solução de implantação para o recurso Jabber VPN (Virtual Private Network-less). Essa solução permite que os usuários finais se conectem a recursos internos da empresa em qualquer lugar do mundo. Este guia foi criado para dar aos engenheiros que solucionam problemas da solução Collaboration Edge a capacidade de identificar e resolver rapidamente os problemas mais comuns enfrentados pelos clientes durante a frase de implantação.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
Esse sintoma pode ser causado por uma grande variedade de problemas, alguns dos quais estão descritos aqui.
Para que um cliente Jabber possa fazer login com êxito com o MRA, um registro SRV de borda de colaboração específico deve ser criado e acessível externamente. Quando um cliente Jabber é iniciado inicialmente, ele faz consultas DNS SRV:
Se o cliente Jabber for iniciado e não receber uma resposta SRV para _cisco-uds e _cuplogin e _collab-edge, então ele usará essa resposta para tentar entrar em contato com o Expressway-E listado na resposta SRV.
O registro SRV _collab-edge deve apontar para o FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado) do Expressway-E com a porta 8443. Se o SRV _collab-edge não for criado, ou não estiver disponível externamente, ou se estiver disponível, mas a porta 8443 não puder ser alcançada, o cliente Jabber falhará ao fazer login.
Você pode confirmar se o registro SRV _collab-edge é resolvível e a porta TCP 8443 pode ser alcançada usando o verificador SRV no Collaboration Solutions Analyzer (CSA).
Se a porta 8443 não for alcançável, isso pode ser devido a um dispositivo de segurança (Firewall) bloqueando a porta ou a uma configuração incorreta do Gateway padrão (GW) ou das rotas estáticas no Exp-E.
Depois que o cliente Jabber receber uma resposta para _collab-edge, ele entra em contato com o Expressway com o Transport Layer Security (TLS) pela porta 8443 para tentar recuperar o certificado do Expressway para configurar o TLS para comunicação entre o cliente Jabber e o Expressway.
Se o Expressway não tiver um certificado assinado válido que contenha o FQDN ou o domínio do Expressway, isso falhará e o cliente Jabber falhará ao fazer logon.
Se esse problema ocorrer, o cliente deve usar a ferramenta de Solicitação de Assinatura de Certificado (CSR - Certificate Signing Request) no Expressway, que inclui automaticamente o FQDN do Expressway como um Nome Alternativo de Assunto (SAN - Subject Alternative Name).
Nota: O MRA exige comunicação segura entre o Expressway-C e o Expressway-E e entre o Expressway-E e os endpoints externos.
A próxima tabela com os requisitos de certificado do Expressway por recurso pode ser encontrada no Guia de Implantação do MRA:
Depois que o cliente Jabber estabelece com êxito uma conexão segura com o Expressway-E, ele solicita sua configuração de borda (get_edge_config). Esta configuração de borda contém os registros SRV para _cuplogin e _cisco-uds. Se os registros SRV _cisco-uds não forem retornados na configuração de borda, o cliente Jabber não poderá prosseguir com o login.
Para corrigir isso, certifique-se de que os registros SRV _cisco-uds sejam criados internamente e resolvidos pelo Expressway-C.
Mais informações sobre os registros SRV de DNS podem ser encontradas no Guia de implantação de MRA para X8.11.
Esse também é um sintoma comum se você estiver em um domínio duplo. Se você executar em um domínio duplo e descobrir que o cliente Jabber não está sendo retornado em nenhum UDS (User Data Service, serviço de dados do usuário), confirme se os registros SRV _cisco-uds foram criados no DNS interno com o domínio externo.
Nota: Depois da versão X12.5 do Expressway, não é mais necessário adicionar um registro SRV _cisco-UDS ao DNS interno. Para obter mais informações sobre esse aprimoramento, consulte o Guia de implantação do Mobile and Remote Access Through Cisco Expressway (X12.5).
Se a NIC (Network Interface Controller, Controlador de Interface de Rede) do Expressway-E estiver configurada incorretamente, isso pode fazer com que o servidor da XCP (Extensible Communications Platform, Plataforma de Comunicações Extensíveis) não seja atualizado. Se o Expressway-E atender a esses critérios, você provavelmente encontrará esse problema:
Para corrigir esse problema, altere a opção Usar interfaces de rede duplas para Não.
O motivo disso é que o Expressway-E escuta a sessão XCP na interface de rede errada, o que faz com que a conexão falhe/timeout. O Expressway-E escuta na porta TCP 7400 para a sessão XCP. Você pode verificar isso se usar o comando netstat
do VCS como raiz.
Se o nome de host/domínio do servidor Expressway-E na configuração da página DNS não corresponder ao que foi recebido na resposta SRV _collab-edge, o cliente Jabber não consegue se comunicar com o Expressway-E. O cliente Jabber usa o elemento xmppEdgeServer/Address na resposta get_edge_config para estabelecer a conexão XMPP com o Expressway-E.
Este é um exemplo de como é o xmppEdgeServer/Address na resposta get_edge_config do Expressway-E para o cliente Jabber:
<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example.com</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>
Para evitar isso, certifique-se de que o registro SRV _collab-edge corresponda ao nome de host/nome de domínio do Expressway-E. A ID de bug da Cisco CSCuo83458 foi arquivada para isso e o suporte parcial foi adicionado na ID de bug CSCuo82526 da Cisco.
Os registros do Jabber para Windows mostram o seguinte:
2014-11-22 19:55:39,122 INFO [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is 'Code: IS_WEBEX_CUSTOMER; Server:
http://loginp.webexconnect.com;
Url: http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com';;;.2014-11-22
19:55:39,122 INFO [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] -
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com2014-11-22
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com]2014-11-22
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url]
skipLocal : [0] value: [http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com]
success: [true] configStoreName: [LocalFileConfigStore]
As tentativas de login são direcionadas para o WebEx Connect.
Para obter uma resolução permanente, você deve entrar em contato com o WebEx para que o site seja desativado.
Solução
A curto prazo, você pode utilizar uma dessas opções para excluí-la da pesquisa.
<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Policies>
<ServiceDiscoveryExcludedServices>WEBEX<
/ServiceDiscoveryExcludedServices>
</Policies>
</config>
msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX
Nota: A segunda opção não funciona para dispositivos móveis.
ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX
Você pode encontrar mais detalhes sobre a descoberta do serviço UC e como excluir alguns serviços na implantação local do Cisco Jabber 12.8.
Se você navegar para Status > Unified Communications e ver a mensagem de erro, "Configured but with errors. Provisioning server: Waiting for traversal server info."
para os registros do Unified CM e o Serviço IM&P, os servidores DNS internos configurados no Expressway-C têm dois registros DNS A para o Expressway-E. O motivo por trás de vários registros de DNS A para o Expressway-E pode ser o usuário afetado movido de uma única NIC com NAT estático habilitado no Expressway-E para NIC dupla com NAT estático habilitado, ou vice-versa, e esquecido de excluir o registro de DNS A apropriado no(s) servidor(es) DNS interno(s). Portanto, ao usar o utilitário de pesquisa DNS no Expressway-C e resolver o FQDN do Expressway-E, você observará dois registros DNS A.
Solução
Se a placa de rede Expressway-E estiver configurada para uma única placa de rede com NAT estático:
ipconfig /flushdns
).Se a placa de rede Expressway-E estiver configurada para NIC dupla com NAT estático ativado:
ipconfig /flushdns
).O cliente pode usar o Microsoft DirectAccess no mesmo PC que o cliente Jabber. Quando você tenta fazer login remotamente, isso pode quebrar o MRA. O DirectAccess forçará consultas DNS a serem encapsuladas na rede interna como se o PC estivesse usando uma VPN.
Nota: O Microsoft DirectAccess não é compatível com Jabber sobre MRA. Qualquer solução de problemas é o melhor esforço. A configuração do DirectAccess é da responsabilidade do administrador da rede.
Alguns clientes obtiveram êxito ao bloquear todos os registros DNS na Tabela de Políticas de Resolução de Nomes do Microsoft DirectAccess. Esses registros não devem ser processados pelo DirectAccess (o Jabber precisa ser capaz de resolvê-los via DNS público ao usar MRA):
Começando na versão X8.8, o Expressway/VCS exige que entradas de DNS posteriores e revertidas sejam criadas para ExpE, ExpC e todos os nós do CUCM.
Para obter todos os requisitos, consulte Pré-requisitos e Dependências de Software nas Notas de Versão do x8.8 e Registros DNS para Acesso Móvel e Remoto.
Se os registros DNS internos não estiverem presentes, você poderá ver um erro nos registros do Expressway que se referem a reverseDNSLookup:
2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"
O Expressway-C deve receber apenas um FQDN ao consultar o registro PTR para o IP do Expressway-E. Se receber um FQDN incorreto do DNS, ele mostrará esta linha nos registros e falhará:
2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname host.example.com"
Um log de diagnóstico do Expressway-C mostra um SIP/2.0 405 Method Not Allowed
em resposta à solicitação de registro enviada pelo cliente Jabber. Isso provavelmente se deve a um tronco de Protocolo de Iniciação de Sessão (SIP - Session Initiation Protocol) existente entre o Expressway-C e o CUCM usando a porta 5060/5061.
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
Para corrigir esse problema, altere a porta SIP no Perfil de segurança do tronco SIP que é aplicada ao tronco SIP existente configurado no CUCM e na zona vizinha do Expressway-C para CUCM para uma porta diferente, como 5065. Isto é explicado mais adiante neste vídeo. Aqui está um resumo da configuração:
CUCM
Expressway-C
"Unknown domain"
Um log de diagnóstico do Expressway-C mostra Event="Registration Rejected" Reason="Unknown domain"
Service="SIP" Src-ip="XXX.XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip:XXX.XXX.XXX.XXX".
Para corrigir esse problema, verifique estes pontos:
"Idle countdown expired"
Ao revisar os logs do Expressway-E durante o período de tempo que o cliente Jabber envia em uma mensagem REGISTER, você pode encontrar um Idle countdown expired
erro, conforme indicado no trecho de código aqui.
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211"
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606"
Module="network.tcp" Level="DEBUG": Src-ip="92.90.21.82" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle
countdown expired"
Esse trecho indica que o firewall tem a porta 5061 aberta; no entanto, não há tráfego da camada de aplicação que seja passado em uma quantidade suficiente de tempo para que a conexão TCP seja fechada.
Se você encontrar essa situação, há um alto grau de probabilidade de que o firewall em frente ao Expressway-E tenha a funcionalidade SIP Inspection/Application Layer Gateway (ALG) ativada. Para corrigir esse problema, você deve desativar essa funcionalidade. Se não tiver certeza de como fazer isso, consulte a documentação do produto do fornecedor do firewall.
Para obter mais informações sobre a inspeção SIP/ALG, consulte o Apêndice 4 do Guia de implantação de configuração básica do Cisco Expressway-E e do Expressway-C.
Um log de diagnóstico do Expressway-E mostra uma falha de negociação TLS na porta 5061, no entanto, o handshake SSL foi bem-sucedido na porta 8443.
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"
Logs do Jabber:
-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'expe.korteco.com' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=expe.korteco.com:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.
A captura de pacotes do Jabber mostra uma negociação SSL com o Expressway E IP; no entanto, o certificado enviado não vem deste servidor:
O FW tem proxy de telefone configurado.
Solução:
Confirme se o firmware está executando o proxy do telefone. Para verificar isso, insira o comando show run policy-map
e mostrará algo semelhante a:
class sec_sip
inspect sip phone-proxy ASA-phone-proxy
Desative a ligação do Proxy de Telefone para serviços telefônicos com êxito.
Estas são algumas das configurações incorretas e ausentes que podem causar esse problema em implantações de NIC simples e dupla:
NIC única com implantações de NAT estático não é recomendada. Aqui estão algumas considerações para evitar problemas de mídia:
Mais informações sobre isso podem ser encontradas no Apêndice 4 do Guia de implantação de configuração básica do Cisco Expressway-E e do Expressway-C.
Esse problema é devido a uma limitação no Expressways anterior à versão X8.5. A ID de bug da Cisco CSCua72781 descreve como o Expressway-C não encaminha a mídia no início do 183 Session Progress ou 180 Ringing através da zona de passagem. Se você executar as versões X8.1.x ou X8.2.x, poderá atualizar para a versão X8.5 ou, alternativamente, executar a solução alternativa listada aqui.
É possível usar uma solução alternativa no Cisco Unified Border Element (CUBE) se você criar um perfil SIP que transforma o 183 em um 180 e o aplica no peer de discagem de entrada. Por exemplo:
voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress"
"SIP/2.0 180 Ringing"
Depois, desabilitariam o 180 Early Media no perfil SIP do CUCM > CUBE ou no próprio CUBE no modo de configuração sip-ua.
disable-early-media 180
Ao adicionar CUCM ao Expressway-C, você encontra um erro ASCII que impede que o CUCM seja adicionado.
Quando o Expressway-C adiciona o CUCM ao seu banco de dados, ele executa uma série de consultas AXL relacionadas às funções get e list. Exemplos disso incluem getCallManager, listCallManager, listProcessNode, listProcessNodeService e getCCMVersion. Depois que o processo getCallManager é executado, ele é bem-sucedido por um ExecuteSQLQuery definido para recuperar todas as confiança do CUCM Call Manager ou do tomcat.
Quando o CUCM recebe a consulta e a executa nela, o CUCM reporta todos os seus certificados. Se um dos certificados contiver um caractere não ASCII, o Expressway gerará um erro na interface da Web semelhante a ascii codec can't decode byte 0xc3 in position 42487: ordinal not in range(128)
.
Esse problema é rastreado com o bug da Cisco ID CSCuo54489 e é resolvido na versão X8.2.
Esse problema ocorre quando você usa certificados autoassinados no CUCM e no Tomcat.pem/CallManager.pem têm o mesmo assunto. O problema é tratado com o bug da Cisco ID CSCun30200. A solução alternativa para corrigir o problema é excluir o tomcat.pem e desabilitar a Verificação TLS da configuração do CUCM no Expressway-C.
Quando você adiciona um Servidor IM&P, o Expressway-C relata "Este servidor não é um Servidor IM e Presence" ou "Não é possível se comunicar com o erro HTTP da consulta .AXL ''HTTPError:500''", o que faz com que o Servidor IM&P não seja adicionado.
Como parte da adição de um servidor IM&P, o Expressway-C usa uma consulta AXL para procurar certificados IM&P em um diretório explícito. Devido à ID de bug da Cisco CSCul05131, os certificados não estão nessa loja; portanto, você encontra o erro falso.
Para fazer com que o status do correio de voz do cliente Jabber se conecte com êxito, você deve configurar o endereço IP ou o nome do host do Cisco Unity Connection na lista de permissões HTTP no Expressway-C.
Para concluir isso no Expressway-C, execute o procedimento relevante:
Procedimento para as versões X8.1 e X8.2
Procedimento para a versão X8.5
A solução de acesso remoto e móvel usa apenas UDS para resolução de fotos de contato. Isso exige que você tenha um servidor Web disponível para armazenar as fotos. A configuração em si é dupla.
<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
/PhotoUriWithToken>
<UdsServer>%IP%</UdsServer>
<MinimumCharacterQuery>3</MinimumCharacterQuery>
</Directory>
Nota: Para obter mais informações sobre a resolução de fotos de contato do UDS, consulte a documentação de fotos de contato do Jabber.
Essa mensagem de erro pode estar relacionada ao certificado Expressway Edge não assinado por uma CA pública confiável pelo dispositivo do cliente ou que o domínio está ausente como SAN no certificado do servidor.
Para impedir que o cliente Jabber seja solicitado a aceitar o certificado Expressway, você deve atender aos dois critérios listados abaixo:
Nota: Isso é facilmente obtido se você usar uma autoridade de certificação pública porque os dispositivos móveis contêm um grande repositório de confiança de certificado.