Problemen met de oplossing van DNS SRV-recordproblemen met Cisco Secure Access VPN

Downloadopties

PDF (245.0 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (85.6 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (71.4 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:4 mei 2026

Document-id:225846

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

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.