Catalyst 9800 WLC 및 ISE에서 CWA(Central Web Authentication) 구성

소개

이 문서에서는 Catalyst 9800 WLC 및 ISE에서 CWA 무선 LAN을 구성하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

9800 WLC(Wireless LAN Controller) 컨피그레이션에 대해 알고 있는 것이 좋습니다.

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• 9800 WLC Cisco IOS® XE Gibraltar v17.6.x
• ISE(Identity Service Engine) v3.0

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

CWA 프로세스는 Apple 디바이스의 CWA 프로세스를 예로 볼 수 있는 여기에 나와 있습니다.

구성

네트워크 다이어그램

9800 WLC의 AAA 구성

1단계. 9800 WLC 컨피그레이션에 ISE 서버를 추가합니다.

탐색  Configuration > Security > AAA > Servers/Groups > RADIUS > Servers > + Add  이미지에 표시된 대로 RADIUS 서버 정보를 입력합니다.

나중에 중앙 웹 인증(또는 CoA를 필요로 하는 모든 종류의 보안)을 사용하려는 경우 CoA 지원이 활성화되어 있는지 확인하십시오. 

2단계. 권한 부여 방법 목록을 만듭니다.

탐색  Configuration > Security > AAA >  AAA Method List > Authorization > + Add  그림에 표시된 것과 같습니다.

3단계. (선택 사항) 이미지에 표시된 대로 어카운팅 방법 목록을 생성합니다.

참고: Cisco 버그 ID CSCvh03827로 인해 Cisco IOS XE CLI 컨피그레이션에서 RADIUS 서버를 로드 밸런싱하기로 결정하면 CWA가 작동하지 않습니다. 외부 부하 분산 장치의 사용도 좋습니다.

4단계. (선택 사항) SSID 이름을 Called-station-id 특성으로 전송하도록 AAA 정책을 정의할 수 있습니다. 이 특성은 이 프로세스의 나중에 ISE에서 이 조건을 활용하려는 경우 유용할 수 있습니다.

탐색  Configuration > Security > Wireless AAA Policy 기본 AAA 정책을 수정하거나 새로 생성합니다.

선택할 수 있습니다.  SSID 옵션 1로 지정합니다. SSID만 선택하는 경우에도 수신 스테이션 ID는 SSID 이름에 AP MAC 주소를 계속 추가합니다.

WLAN 구성

1단계. WLAN을 생성합니다.

탐색  Configuration > Tags & Profiles > WLANs > + Add  필요에 따라 네트워크를 구성합니다.

2단계. WLAN 일반 정보를 입력합니다.

3단계. 탐색:  Security  탭을 클릭하고 필요한 보안 방법을 선택합니다. 이 경우 'MAC 필터링' 및 AAA 권한 부여 목록(2단계에서 생성한 항목)만  AAA Configuration  (섹션)이(가) 필요합니다.

CLI:

#config t
(config)#wlan cwa-ssid 4 cwa-ssid
(config-wlan)#mac-filtering CWAauthz
(config-wlan)#no security ft adaptive
(config-wlan)#no security wpa
(config-wlan)#no security wpa wpa2
(config-wlan)#no security wpa wpa2 ciphers aes
(config-wlan)#no security wpa akm dot1x
(config-wlan)#no shutdown

정책 프로파일 구성

정책 프로필 내에서 다른 설정(예: ACL(Access Controls List), QoS(Quality of Service), Mobility Anchor, Timers 등) 중에서 VLAN을 할당할 클라이언트를 결정할 수 있습니다.

기본 정책 프로파일을 사용하거나 새 프로파일을 생성할 수 있습니다.

GUI:

1단계. 새로 만들기  Policy Profile.

탐색  Configuration > Tags & Profiles > Policy  Firepower Threat Defense  default-policy-profile  또는 새로 생성합니다.

프로파일이 활성화되어야 합니다.

2단계. VLAN을 선택합니다.

탐색:  Access Policies  탭을 클릭하고 드롭다운에서 VLAN 이름을 선택하거나 VLAN-ID를 수동으로 입력합니다. 정책 프로파일에서 ACL을 구성하지 마십시오.

3단계. ISE 재정의(AAA 재정의 허용) 및 CoA(Change of Authorization)(NAC 상태)를 허용하도록 정책 프로필을 구성합니다. 선택적으로 어카운팅 방법도 지정할 수 있습니다.

CLI:

# config
# wireless profile policy <policy-profile-name>
# aaa-override
# nac
# vlan <vlan-id_or_vlan-name>
# accounting-list <acct-list>
# no shutdown

정책 태그 구성

정책 태그 내부에서는 SSID를 정책 프로파일과 연결합니다. 새 정책 태그를 생성하거나 default-policy 태그를 사용할 수 있습니다.

참고: default-policy 태그는 WLAN ID가 1~16인 SSID를 자동으로 default-policy 프로필에 매핑합니다. 수정하거나 삭제할 수 없습니다. ID가 17 이상인 WLAN이 있는 경우 default-policy 태그를 사용할 수 없습니다.

GUI:

탐색  Configuration > Tags & Profiles > Tags > Policy  필요한 경우 이미지에 표시된 대로 새 파일을 추가합니다.

WLAN 프로파일을 원하는 정책 프로파일에 연결합니다.

CLI:

# config t
# wireless tag policy <policy-tag-name>
# wlan <profile-name> policy <policy-profile-name>

정책 태그 할당

필요한 AP에 정책 태그를 할당합니다.

GUI:

하나의 AP에 태그를 할당하려면  Configuration > Wireless > Access Points > AP Name > General Tags을 누르고 필요한 할당을 만든 다음  Update & Apply to Device.

참고: AP에서 정책 태그를 변경하면 9800 WLC와의 연결이 끊기고 약 1분 내에 다시 결합됩니다.

동일한 정책 태그를 여러 AP에 할당하려면  Configuration > Wireless > Wireless Setup > Advanced > Start Now.

태그를 할당할 AP를 선택하고  + Tag APs  그림에 표시된 것과 같습니다.

whished Tag(whished 태그)를 선택하고  Save & Apply to Device 그림에 표시된 것과 같습니다.

CLI:

# config t
# ap <ethernet-mac-addr>
# policy-tag <policy-tag-name>
# end

ACL 구성 리디렉션

1단계. 탐색  Configuration > Security > ACL > + Add  새 ACL을 생성합니다. 

ACL의 이름을 선택하고 만듭니다.  IPv4 Extended  이미지에 표시된 대로 모든 규칙을 입력하고 시퀀스로 추가합니다.

ISE PSN 노드에 대한 트래픽과 DNS를 거부하고 나머지는 모두 허용해야 합니다. 이 리디렉션 ACL은 보안 ACL이 아니라 추가 처리(리디렉션 등)를 위해 CPU에 어떤 트래픽(허용 시)을 전송할지, 데이터 평면에 어떤 트래픽(거부 시)을 유지할지 정의하고 리디렉션을 방지하는 punt ACL입니다.

ACL은 다음과 같아야 합니다(이 예에서는 10.48.39.28을 ISE IP 주소로 대체).

참고: 리디렉션 ACL의 경우  deny 작업을 거부 리디렉션(거부 트래픽 아님)으로 사용하고  permit 작업을 허용 리디렉션으로 지정합니다. WLC는 리디렉션할 수 있는 트래픽(기본적으로 포트 80 및 443)만 조사합니다.

CLI:

ip access-list extended REDIRECT
 deny ip any host <ISE-IP>
 deny ip host<ISE-IP> any
 deny udp any any eq domain
 deny udp any eq domain any
 permit tcp any any eq 80

참고: ACL을  permit ip any any 포트 80에 초점을 맞춘 허용 대신 WLC는 HTTPS도 리디렉션합니다. 이는 자체 인증서를 제공해야 하고 항상 인증서 위반을 생성해야 하기 때문에 바람직하지 않은 경우가 많습니다. 이는 CWA의 경우 WLC에 인증서가 필요하지 않다고 말하는 이전 문의 예외입니다. HTTPS 가로채기를 활성화했지만 어쨌든 유효한 것으로 간주되지 않는 경우 인증서가 필요합니다.

ISE 서버에 대한 게스트 포트 8443만 거부하도록 조치하여 ACL을 개선할 수 있습니다.

HTTP 또는 HTTPS에 대한 리디렉션 사용

웹 관리 포털 컨피그레이션은 웹 인증 포털 컨피그레이션과 연결되어 있으며 리디렉션하려면 포트 80에서 수신해야 합니다. 따라서 리디렉션이 제대로 작동하려면 HTTP를 활성화해야 합니다. (명령을 사용하여) 전역적으로 활성화하도록 선택할 수 있습니다  ip http server)를 활성화하거나 웹 인증 모듈만(명령 사용 시)  webauth-http-enable 매개 변수 맵 아래).

HTTPS URL에 액세스하려고 할 때 리디렉션하려면 명령을 추가합니다  intercept-https-enable 매개변수 맵에서 이는 최적의 컨피그레이션이 아니며 WLC CPU에 영향을 미치고 인증서 오류를 생성한다는 점에 유의하십시오.

parameter-map type webauth global
 type webauth
 intercept-https-enable
 trustpoint xxxxx

또한 매개 변수 맵에서 선택한 'Web Auth intercept HTTPS' 옵션을 사용하여 GUI를 통해 수행할 수 있습니다(Configuration > Security > Web Auth).
  

ISE 구성

ISE에 9800 WLC 추가

1단계. ISE 콘솔을 열고Administration > Network Resources > Network Devices > Add 그림에 표시된 것과 같습니다.

2단계. 네트워크 디바이스를 구성합니다.

선택적으로, 지정된 모델 이름, 소프트웨어 버전 및 설명이 될 수 있으며 디바이스 유형, 위치 또는 WLC에 따라 네트워크 디바이스 그룹을 할당할 수 있습니다.

여기서 IP 주소는 인증 요청을 전송하는 WLC 인터페이스에 해당합니다. 기본적으로 이 인터페이스는 이미지에 표시된 관리 인터페이스입니다.

네트워크 디바이스 그룹에 대한 자세한 내용은 ISE 관리 가이드 장: 네트워크 디바이스 관리: ISE - 네트워크 디바이스 그룹을 참조하십시오.

ISE에서 새 사용자 생성

1단계. 탐색  Administration > Identity Management > Identities > Users > Add  그림에 표시된 것과 같습니다.

2단계. 정보를 입력합니다.

이 예에서 이 사용자는  ALL_ACCOUNTS 그러나 그림과 같이 필요에 따라 조정할 수 있습니다.

권한 부여 프로파일 생성

정책 프로필은 매개 변수(예: mac 주소, 자격 증명, 사용된 WLAN 등)를 기반으로 클라이언트에 할당된 결과입니다. VLAN(Virtual Local Area Network), ACL(Access Control List), URL(Uniform Resource Locator) 리디렉션 등 특정 설정을 할당할 수 있습니다.

최신 버전의 ISE에는 Cisco_Webauth 권한 부여 결과가 이미 있습니다. 여기에서 WLC에 구성한 것과 일치하도록 리디렉션 ACL 이름을 수정하도록 편집할 수 있습니다.

1단계. 탐색  Policy > Policy Elements > Results > Authorization > Authorization Profiles. 클릭  add 직접 만들거나  Cisco_Webauth 기본 결과입니다.

2단계. 리디렉션 정보를 입력합니다. ACL 이름이 9800 WLC에 구성된 이름과 동일한지 확인합니다.

인증 규칙 구성

1단계. 정책 집합은 인증 및 권한 부여 규칙의 모음을 정의합니다. 하나를 생성하려면Policy > Policy Sets에서 목록의 첫 번째 Policy Set(정책 집합)의 장비를 클릭하고Insert new row or click the blue arrow on the right to choose the defaut Policy Set.


2단계. Expand  Authentication 정책. 의 경우  MAB 규칙(유선 또는 무선 MAB에 일치), 확장  Options을 선택하고  CONTINUE '사용자를 찾을 수 없는 경우'가 표시되는 경우 옵션입니다.

3단계. 클릭  Save  변경 사항을 저장합니다.

권한 부여 규칙 구성

권한 부여 규칙은 클라이언트에 어떤 권한(권한 부여 프로파일) 결과를 적용할지 결정하는 역할을 합니다.

1단계. 동일한 Policy set 페이지에서  Authentication Policy 및 확장  Authorziation Policy  그림에 표시된 것과 같습니다.

2단계. 최신 ISE 버전은  Wifi_Redirect_to_Guest_Login 이는 대부분 우리의 요구와 일치합니다. 왼쪽에 있는 회색 판을  enable.

3단계. 이 규칙은 Wireless_MAB에만 일치하며 CWA 리디렉션 특성을 반환합니다. 이제 선택적으로 약간의 비틀기를 추가하고 특정 SSID에만 일치하도록 할 수 있습니다. Conditions Studio(조건 스튜디오)를 표시하려면 조건(현재 Wireless_MAB)을 선택합니다. 오른쪽에 조건을 추가하고  Radius 사전  Called-Station-ID 특성. SSID 이름과 일치하도록 합니다. 다음으로 유효성 검사 Use 그림과 같은 화면 맨 아래에 있습니다.

4단계. 이제 우선 순위가 더 높은 두 번째 규칙이 필요합니다.  Guest Flow 사용자가 포털에서 인증한 후 네트워크 액세스 세부사항을 반환하기 위한 조건입니다. Firepower Threat Defense  Wifi Guest Access 최근 ISE 버전에서도 기본적으로 미리 생성되는 규칙입니다. 그런 다음 왼쪽에 녹색 표시가 있는 규칙만 활성화해야 합니다.   기본 PermitAccess를 반환하거나 더 정확한 액세스 목록 제한을 구성할 수 있습니다.

5단계. 규칙을 저장합니다.

클릭  Save  있습니다.

FlexConnect 로컬 스위칭 액세스 포인트 전용

FlexConnect 로컬 스위칭 액세스 포인트 및 WLAN이 있는 경우 어떻게 해야 합니까? 이전 섹션은 여전히 유효합니다. 그러나 리디렉션 ACL을 AP에 미리 푸시하려면 추가 단계가 필요합니다.

탐색  Configuration > Tags & Profiles > Flex Flex 프로필을 선택합니다. 그런 다음  Policy ACL 탭을 클릭합니다.

클릭  Add  그림에 표시된 것과 같습니다.

리디렉션 ACL 이름을 선택하고 Central 웹 인증을 활성화합니다. 이 확인란은 AP 자체의 ACL을 자동으로 반전시킵니다. Cisco IOS XE의 WLC에서 'deny' 문은 '이 IP로 리디렉션하지 않음'을 의미하기 때문입니다. 그러나 AP에서 'deny' 문장은 그 반대를 의미합니다. 따라서 이 확인란은 AP에 대한 푸시를 수행할 때 모든 허가를 자동으로 스왑하고 거부합니다. 다음 명령을 사용하여 이를 확인할 수 있습니다  show ip access list AP CLI에서 확인할 수 있습니다.

참고: Flexconnect 로컬 스위칭 시나리오에서 ACL은 반환 명령문을 구체적으로 언급해야 합니다(로컬 모드에서 반드시 필요한 것은 아님). 따라서 모든 ACL 규칙이 (예를 들어 ISE로 들어오고 나가는) 트래픽의 두 가지 방법을 모두 다루도록 해야 합니다.

잊지 말고 명중하세요  Save 그리고  Update and apply to the device.

인증서

클라이언트가 웹 인증 인증서를 신뢰하도록 하려면 ISE 인증서(클라이언트가 신뢰해야 함)만 제공되므로 WLC에 인증서를 설치할 필요가 없습니다.

다음을 확인합니다.

이러한 명령을 사용하여 현재 구성을 확인할 수 있습니다.

# show run wlan
# show run aaa
# show aaa servers
# show ap config general
# show ap name <ap-name> config general 
# show ap tag summary
# show ap name <AP-name> tag detail
# show wlan { summary | id | nme | all }
# show wireless tag policy detailed <policy-tag-name>
# show wireless profile policy detailed <policy-profile-name> 

다음은 이 예에 해당하는 WLC 컨피그레이션의 관련 부분입니다.

aaa new-model
!
aaa authorization network CWAauthz group radius
aaa accounting identity CWAacct start-stop group radius
!
aaa server radius dynamic-author
 client <ISE-IP> server-key cisco123
!
aaa session-id common
!
!
radius server ISE-server
 address ipv4 <ISE-IP> auth-port 1812 acct-port 1813
 key cisco123
!
!
wireless aaa policy default-aaa-policy
wireless cts-sxp profile default-sxp-profile

wireless profile policy default-policy-profile
 aaa-override
 nac
 vlan 1416
 no shutdown
wireless tag policy cwa-policy-tag
 wlan cwa-ssid policy default-policy-profile
wlan cwa-ssid 4 cwa-ssid
 mac-filtering CWAauthz
 no security ft adaptive
 no security wpa
 no security wpa wpa2
 no security wpa wpa2 ciphers aes
 no security wpa akm dot1x
 no shutdown

ip http server (or "webauth-http-enable" under the parameter map)
ip http secure-server

문제 해결

체크리스트

• 클라이언트가 연결되어 있고 유효한 IP 주소를 가져와야 합니다.
• 리디렉션이 자동이 아니면 브라우저를 열고 임의의 IP 주소를 시도합니다. 예: 10.0.0.1. 리디렉션이 작동하는 경우 DNS 확인 문제가 있을 수 있습니다. DHCP를 통해 제공된 유효한 DNS 서버가 있으며 호스트 이름을 확인할 수 있는지 확인합니다. 
• 명령을 가지고 있는지 확인합니다.  ip http server HTTP에서 리디렉션하도록 구성되었습니다. 웹 관리 포털 컨피그레이션은 웹 인증 포털 컨피그레이션과 연결되어 있으며 리디렉션하려면 포트 80에 나열되어야 합니다. (명령을 사용하여) 전역적으로 활성화하도록 선택할 수 있습니다  ip http server)를 활성화하거나 웹 인증 모듈만(명령 사용 시)  webauth-http-enable 매개 변수 맵 아래).
• HTTPS URL에 액세스하려고 할 때 리디렉션되지 않고 필요한 경우 이 명령이 있는지 확인합니다  intercept-https-enable 매개변수 맵에서 다음을 수행합니다.
  
  

parameter-map type webauth global
 type webauth
 intercept-https-enable
 trustpoint xxxxx

또한 GUI를 통해 매개변수 맵에서 'Web Auth intercept HTTPS' 옵션을 선택할 수도 있습니다.
  

RADIUS에 대한 서비스 포트 지원

Cisco Catalyst 9800 Series Wireless Controller에는  GigabitEthernet 0포트. 버전 17.6.1부터 RADIUS(CoA 포함)는 이 포트를 통해 지원됩니다.

RADIUS용 서비스 포트를 사용하려면 다음 컨피그레이션이 필요합니다.

aaa server radius dynamic-author 
client 10.48.39.28 vrf Mgmt-intf server-key cisco123

interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 ip address x.x.x.x x.x.x.x

!if using aaa group server:
aaa group server radius group-name
 server name nicoISE
 ip vrf forwarding Mgmt-intf
 ip radius source-interface GigabitEthernet0

디버그 수집

WLC 9800은 상시 추적 기능을 제공합니다. 이렇게 하면 모든 클라이언트 연결 관련 오류, 경고 및 알림 수준 메시지가 지속적으로 로깅되며, 사고 또는 장애 발생 후 상황에 대한 로그를 볼 수 있습니다.

참고: 로그에서 몇 시간에서 며칠로 돌아갈 수 있지만 생성된 로그의 볼륨에 따라 다릅니다.

기본적으로 9800 WLC가 수집한 추적을 보려면 SSH/텔넷을 통해 9800 WLC에 연결하고 다음 단계를 수행할 수 있습니다(세션을 텍스트 파일에 로깅해야 함).

1단계. WLC의 현재 시간을 확인하여 문제가 발생한 시간까지의 로그를 추적할 수 있습니다.

# show clock

2단계. 시스템 컨피그레이션에 따라 WLC 버퍼 또는 외부 syslog에서 syslog를 수집합니다. 이렇게 하면 시스템의 상태와 오류가 있는 경우 이를 빠르게 확인할 수 있습니다.

# show logging

3단계. 디버그 조건이 활성화되었는지 확인합니다.

# show debugging
Cisco IOS XE Conditional Debug Configs:

Conditional Debug Global State: Stop

Cisco IOS XE Packet Tracing Configs:


Packet Infra debugs:

Ip Address                                               Port
------------------------------------------------------|----------

참고: 조건을 나열하면, 활성화된 조건(mac 주소, IP 주소 등)이 발생하는 모든 프로세스의 디버그 레벨에 추적이 로깅됨을 의미합니다. 이렇게 하면 로그의 볼륨이 증가합니다. 따라서 능동적으로 디버깅하지 않을 때는 모든 조건을 지우는 것이 좋습니다.

4단계. 테스트 중인 mac 주소가 3단계의 조건으로 나열되지 않았다는 가정하에 특정 mac 주소에 대한 always-on 알림 레벨 추적을 수집합니다.

# show logging profile wireless filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file always-on-<FILENAME.txt> 

세션의 콘텐츠를 표시하거나 파일을 외부 TFTP 서버에 복사할 수 있습니다.

# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt> 

조건부 디버깅 및 무선 활성 추적 

Always-on 추적을 통해 조사 중인 문제의 트리거를 확인할 수 있는 충분한 정보가 제공되지 않을 경우, 조건부 디버깅을 활성화하고 RA(Radio Active) 추적을 캡처할 수 있습니다. 그러면 지정된 조건(이 경우 클라이언트 mac 주소)과 상호 작용하는 모든 프로세스에 대해 디버그 레벨 추적을 제공합니다. 조건부 디버깅을 활성화하려면 다음 단계를 진행합니다.

5단계. 활성화된 디버그 조건이 없는지 확인합니다.

# clear platform condition all

6단계. 모니터링할 무선 클라이언트 mac 주소에 대한 디버그 조건을 활성화합니다.

이 명령은 30분(1,800초) 동안 제공된 MAC 주소를 모니터링하기 시작합니다. 선택적으로 이 시간을 최대 2,085,978,494초까지 늘릴 수 있습니다.

# debug wireless mac <aaaa.bbbb.cccc> {monitor-time <seconds>}

참고: 한 번에 둘 이상의 클라이언트를 모니터링하려면 debug wireless mac을 실행하십시오   mac 주소당 명령입니다.

참고: 모든 것이 나중에 볼 수 있도록 내부적으로 버퍼링되므로 터미널 세션에서 클라이언트 활동의 출력이 표시되지 않습니다.

7단계` 모니터링할 문제나 동작을 재현합니다.

8단계. 기본 또는 구성된 모니터 시간이 끝나기 전에 문제가 재현되는 경우 디버그를 중지합니다.

# no debug wireless mac <aaaa.bbbb.cccc>

모니터 시간이 경과하거나 디버그 무선이 중지되면 9800 WLC는 다음과 같은 이름의 로컬 파일을 생성합니다.

ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log

9단계. mac 주소 활동의 파일을 수집합니다. 다음 중 하나를 복사하거나  ra trace .log 외부 서버에 연결하거나 화면에 출력을 직접 표시합니다.

RA 추적 파일의 이름을 확인합니다.

# dir bootflash: | inc ra_trace

파일을 외부 서버에 복사:

# copy bootflash: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log  tftp://a.b.c.d/ra-FILENAME.txt

콘텐츠 표시:

# more bootflash: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log 

10단계. 근본 원인이 아직 명확하지 않은 경우 디버그 레벨 로그를 더 자세히 보여주는 내부 로그를 수집합니다. 이미 수집되어 내부적으로 저장된 디버그 로그를 더 자세히 살펴볼 뿐이므로 클라이언트를 다시 디버깅할 필요는 없습니다.

# show logging profile wireless internal filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file ra-internal-<FILENAME>.txt

참고: 이 명령 출력은 모든 프로세스에 대한 모든 로그 레벨의 추적을 반환하며 상당히 방대합니다. 이러한 추적을 분석하도록 Cisco TAC와 협력하십시오.

다음 중 하나를 복사하거나  ra-internal-FILENAME.txt 외부 서버에 연결하거나 화면에 출력을 직접 표시합니다.

파일을 외부 서버에 복사:

# copy bootflash:ra-internal-<FILENAME>.txt tftp://a.b.c.d/ra-internal-<FILENAME>.txt

콘텐츠 표시:

# more bootflash:ra-internal-<FILENAME>.txt

11단계. 디버그 조건을 제거합니다.

# clear platform condition all

참고: 트러블슈팅 세션 후 항상 디버그 조건을 제거해야 합니다.

예

인증 결과가 예상과 다를 경우 ISE로 이동하는 것이 중요합니다  Operations > Live logs 페이지를 표시하고 인증 결과에 대한 세부 정보를 가져옵니다.

실패에 대한 이유(실패가 있는 경우) 및 ISE에서 수신하는 모든 Radius 특성이 표시됩니다.

다음 예시에서는 일치하는 권한 부여 규칙이 없으므로 ISE가 인증을 거부했습니다. 이는 권한 부여가 SSID 이름과 정확히 일치하는 반면 AP mac 주소에 추가된 SSID 이름으로 전송되는 Called-station-ID 특성이 표시되기 때문입니다. 해당 규칙이 'equal' 대신 'contains'로 변경되면서 수정됩니다.

이 문제를 해결한 후에도 ISE에서 권한 부여가 성공적이며 올바른 CWA 특성을 반환했다고 주장하는 동안 wifi 클라이언트는 여전히 SSID와 연결할 수 없습니다.

다음 위치로 이동할 수 있습니다.  Troubleshooting > Radioactive trace WLC 웹 UI 페이지입니다.

대부분의 경우 문제를 한 번 더 재현하지 않고 항상 켜져 있는 로그를 신뢰할 수 있으며 이전 연결 시도에서 로그도 가져올 수 있습니다.

클라이언트 mac 주소를 추가하고  Generate  그림에 표시된 것과 같습니다.

이 경우 문제는 ACL 이름을 생성할 때 오타를 만들었고 ISE에서 반환한 ACL 이름과 일치하지 않거나 WLC에서 ISE에서 요청한 ACL과 같은 ACL이 없다고 불평하는 데 있습니다.

2019/09/04 12:00:06.507 {wncd_x_R0-0}{1}: [client-auth] [24264]: (ERR): MAC: e836.171f.a162  client authz result: FAILURE
2019/09/04 12:00:06.516 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [24264]: (ERR): SANET_AUTHZ_FAILURE - Redirect ACL Failure username E8-36-17-1F-A1-62, audit session id 7847300A0000012EFC24CD42, 
2019/09/04 12:00:06.518 {wncd_x_R0-0}{1}: [errmsg] [24264]: (note): %SESSION_MGR-5-FAIL: Authorization failed or unapplied for client (e836.171f.a162) on Interface capwap_90000005 AuditSessionID 7847300A0000012EFC24CD42. Failure Reason: Redirect ACL Failure. Failed attribute name REDIRECT.