Contents

Problema

Ao implementar a VPN de Acesso Seguro da Cisco, os clientes Jabber enfrentam problemas de conectividade devido a conflitos de resolução de registro SRV DNS. O problema ocorre quando o Jabber atinge dois registros SRV DNS: um para o CUCM (_cisco-UDS) e um para o ExpressWay (_collab-edge). Se o registro CUCM SRV for resolvido, independentemente de funcionar ou não, o Jabber supõe que ele esteja no local e tenta se conectar ao CUCM em vez do ExpressWay. Esse comportamento é evidente no registro Jabber com o bEdgeServerFlag = 0 visto em Jabber.log. Além disso, o registro SRV do ExpressWay falha porque está sendo enviado ao servidor DNS privado que o Cliente Seguro usa para resolução, e o servidor DNS privado não encontra recursivamente esse registro SRV público.

Ambiente

- Cisco Secure Access (antigo Cisco AnyConnect Secure Mobility Client)

- cliente Cisco Jabber

- Cisco Unified Communications Manager (CUCM)

- Cisco ExpressWay para acesso móvel e remoto

- Infraestrutura DNS com servidores DNS públicos e privados

- Configuração de túnel VPN com capacidades de separação de túneis

Resolução

O problema foi resolvido roteando o tráfego Jabber pelo túnel VPN em vez de tentar configurar manualmente o cliente para a conectividade ExpressWay. Essa abordagem garante que o tráfego Jabber use o caminho de resolução DNS apropriado e evite o conflito de registro SRV que faz com que o cliente assuma incorretamente a conectividade local.

Passos de Troubleshooting

Passo 1: Analise as consultas de registro SRV DNS usando a captura de pacotes do Wireshark.

Use Wireshark filter: dns.qry.type == 33

Passo 2: Revisar logs do Jabber para status do sinalizador do servidor de borda

Check Jabber.log for: bEdgeServerFlag = 0

Passo 3: Verificar o comportamento da resolução DNS para ambos os registros SRV

Verificar resolução de:

- Registro SRV _cisco-UDS (CUCM)

- _registro SRV de borda de colaboração (ExpressWay)

Implementação da solução

Configure o Cisco Secure Access VPN Client para incluir o tráfego Jabber no túnel em vez de permitir que ele resolva consultas DNS através do servidor DNS local/privado. Isso garante que:

- O tráfego Jabber usa o caminho de resolução DNS correto

- Conflitos de registro SRV são evitados

- A conectividade ExpressWay está estabelecida corretamente

- A funcionalidade completa do Jabber é mantida

Essa solução tem preferência sobre a configuração manual do cliente Jabber para ExpressWay, o que resultaria na perda de alguma funcionalidade.

Causa

A causa raiz é a lógica de resolução de registro SRV DNS em clientes Jabber. Quando o Jabber é iniciado, ele consulta dois registros SRV DNS específicos: _cisco-UDS (para CUCM) e _collab-edge (para ExpressWay). O processo de tomada de decisão do cliente prioriza o registro CUCM SRV - se esse registro for resolvido com êxito, o Jabber supõe que ele esteja operando em um ambiente local e define bEdgeServerFlag = 0, independentemente de a conexão real do CUCM funcionar ou de o registro ExpressWay SRV também ser resolvido.

Em cenários de VPN com tunelamento dividido, o registro SRV ExpressWay (_collab-edge) é enviado ao servidor DNS privado usado pelo Cliente seguro. Como esse é geralmente um registro DNS público e o servidor DNS privado não realiza pesquisas recursivas para registros externos, a resolução do SRV ExpressWay falha. Esse problema composto faz com que o Jabber seja incapaz de estabelecer a conectividade adequada através de qualquer caminho.

Conteúdo relacionado

- Suporte técnico e downloads da Cisco