Inhoud

uitgeven

Bij de implementatie van Cisco Secure Access VPN ondervinden Jabber-clients connectiviteitsproblemen als gevolg van conflicten met de oplossing van DNS SRV-records. Het probleem treedt op wanneer Jabber twee DNS SRV-records bereikt: één voor de CUCM (_cisco-UDS) en één voor ExpressWay (_collab-edge). Als het CUCM SRV-record wordt opgelost, ongeacht of het werkt, gaat Jabber ervan uit dat het on-premises is en probeert verbinding te maken met de CUCM in plaats van ExpressWay. Dit gedrag wordt duidelijk in Jabber-logging met de bEdgeServerFlag = 0 in Jabber.log. Bovendien mislukt de ExpressWay SRV-record omdat deze wordt verzonden naar de privé-DNS-server die de beveiligde client gebruikt voor de oplossing, en de privé-DNS-server vindt deze openbare SRV-record niet recursief.

milieu

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

- Cisco Jabber-client

- Cisco Unified Communications Manager (CUCM)

- Cisco ExpressWay voor mobiele en externe toegang

- DNS-infrastructuur met zowel private als publieke DNS-servers

- VPN-tunnelconfiguratie met gesplitste tunnelmogelijkheden

resolutie

Het probleem werd opgelost door Jabber-verkeer door de VPN-tunnel te leiden in plaats van te proberen de client handmatig te configureren voor ExpressWay-connectiviteit. Deze aanpak zorgt ervoor dat Jabber-verkeer het juiste DNS-oplossingspad gebruikt en voorkomt het SRV-recordconflict waardoor de client ten onrechte on-premises connectiviteit aanneemt.

Stappen voor probleemoplossing

Stap 1: Analyseer DNS SRV-recordquery's met wireshark packet capture.

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

Stap 2: Jabber-logs bekijken voor de status van de edge-servervlag

Check Jabber.log for: bEdgeServerFlag = 0

Stap 3: Controleer het DNS-resolutiegedrag voor beide SRV-records

Controleer de resolutie van:

- _cisco-UDS SRV-record (CUCM)

- _collab-edge SRV-record (ExpressWay)

Implementatie van oplossing

Configureer de Cisco Secure Access VPN-client om Jabber-verkeer in de tunnel op te nemen in plaats van het toe te staan DNS-query's op te lossen via de lokale/private DNS-server. Dit zorgt ervoor dat:

- Jabber-verkeer gebruikt het juiste DNS-resolutiepad

- SRV-recordconflicten worden vermeden

- De ExpressWay-connectiviteit is goed tot stand gebracht

- De volledige functionaliteit van Jabber blijft behouden

Deze oplossing heeft de voorkeur boven het handmatig configureren van de Jabber-client voor ExpressWay, wat zou leiden tot verlies van enige functionaliteit.

Oorzaak

De hoofdoorzaak is de DNS SRV-recordresolutielogica in Jabber-clients. Wanneer Jabber wordt gestart, wordt gezocht naar twee specifieke DNS SRV-records: _cisco-UDS (voor CUCM) en _collab-edge (voor ExpressWay). Het besluitvormingsproces van de client geeft prioriteit aan de CUCM SRV-record - als deze record succesvol wordt opgelost, gaat Jabber ervan uit dat deze in een on-premises omgeving werkt en stelt bEdgeServerFlag = 0 in, ongeacht of de daadwerkelijke CUCM-verbinding werkt of dat de ExpressWay SRV-record ook wordt opgelost.

In VPN-scenario's met split tunneling wordt de ExpressWay SRV-record (_collab-edge) verzonden naar de private DNS-server die wordt gebruikt door de Secure Client. Aangezien dit meestal een openbare DNS-record is en de privé-DNS-server geen recursieve opzoekingen uitvoert voor externe records, mislukt de ExpressWay SRV-resolutie. Dit samengestelde probleem resulteert in Jabber niet in staat om de juiste connectiviteit vast te stellen via beide paden.

Verwante inhoud

- Cisco Technical Support en downloads