Cisco Secure Access VPN을 구현할 때 DNS SRV 레코드 확인 충돌로 인해 Jabber 클라이언트에 연결 문제가 발생합니다. 이 문제는 Jabber가 두 개의 DNS SRV 레코드에 도달할 때 발생합니다. 하나는 CUCM(_cisco-UDS)용이고 하나는 ExpressWay(_collab-edge)용입니다. CUCM SRV 레코드가 확인될 경우, 작동 여부에 관계없이 Jabber는 온프레미스로 간주하여 ExpressWay 대신 CUCM에 연결을 시도합니다. 이 동작은 Jabber.log에 표시되는 bEdgeServerFlag = 0을 사용하는 Jabber 로깅에서 분명히 나타납니다. 또한 ExpressWay SRV 레코드는 보안 클라이언트가 해결을 위해 사용하는 사설 DNS 서버로 전송되며 사설 DNS 서버가 이 공용 SRV 레코드를 재귀적으로 찾지 않기 때문에 실패합니다.
Cisco Secure Access(이전의 Cisco AnyConnect Secure Mobility Client)
Cisco Jabber 클라이언트
CUCM(Cisco Unified Communications Manager)
모바일 및 원격 액세스를 위한 Cisco ExpressWay
프라이빗 및 퍼블릭 DNS 서버가 모두 포함된 DNS 인프라
스플릿 터널링 기능을 사용하는 VPN 터널 컨피그레이션
ExpressWay 연결을 위해 클라이언트를 수동으로 구성하는 대신 VPN 터널을 통해 Jabber 트래픽을 라우팅하여 문제가 해결되었습니다. 이 접근 방식은 Jabber 트래픽이 적절한 DNS 확인 경로를 사용하고 클라이언트가 온프레미스 연결을 잘못 가정하도록 하는 SRV 레코드 충돌을 방지합니다.
1단계: wireshark 패킷 캡처를 사용하여 DNS SRV 레코드 쿼리를 분석합니다.
Use Wireshark filter: dns.qry.type == 33
2단계: 에지 서버 플래그 상태에 대한 Jabber 로그 검토
Check Jabber.log for: bEdgeServerFlag = 0
3단계: 두 SRV 레코드에 대한 DNS 확인 동작 확인
확인:
CUCM(cisco-UDS SRV 레코드)(_C)
_collab-edge SRV 레코드(ExpressWay)
Jabber 트래픽이 로컬/프라이빗 DNS 서버를 통해 DNS 쿼리를 확인하도록 허용하지 않고 터널에 포함되도록 Cisco Secure Access VPN 클라이언트를 구성합니다. 이렇게 하면 다음과 같은 이점이 있습니다.
Jabber 트래픽은 올바른 DNS 확인 경로를 사용합니다
SRV 레코드 충돌 방지
ExpressWay 연결이 올바르게 설정됨
전체 Jabber 기능 유지
이 솔루션은 ExpressWay용 Jabber 클라이언트를 수동으로 구성하는 것보다 선호되며, 이로 인해 일부 기능이 손실됩니다.
근본 원인은 Jabber 클라이언트의 DNS SRV 레코드 확인 논리입니다. Jabber가 시작되면 두 개의 특정 DNS SRV 레코드를 쿼리합니다. _cisco-UDS(CUCM용) 및 _collab-edge(ExpressWay용) 클라이언트 의사 결정 프로세스는 CUCM SRV 레코드의 우선 순위를 지정합니다. 이 레코드가 성공적으로 확인될 경우 Jabber는 온프레미스 환경에서 작동한다고 가정하고 실제 CUCM 연결이 작동하는지 또는 ExpressWay SRV 레코드도 확인되는지 여부와 상관없이 bEdgeServerFlag = 0을 설정합니다.
스플릿 터널링이 있는 VPN 시나리오에서 ExpressWay SRV 레코드(_collab-edge)는 보안 클라이언트에서 사용하는 사설 DNS 서버로 전송됩니다. 이 레코드는 일반적으로 공용 DNS 레코드이며 사설 DNS 서버는 외부 레코드에 대해 재귀적 조회를 수행하지 않으므로 ExpressWay SRV 확인이 실패합니다. 이 복합 문제로 인해 Jabber에서 두 경로 중 하나를 통해 적절한 연결을 설정할 수 없습니다.
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
04-May-2026
|
최초 릴리스 |