AnyConnect 버전 4.0 및 NAC Posture 에이전트가 ISE 트러블슈팅 가이드에 팝업되지 않음

소개

ISE(Identity Services Engine)는 NAC(Network Admission Control) 에이전트(Microsoft Windows, Macintosh 또는 웹 에이전트용) 또는 AnyConnect 버전 4.0을 사용해야 하는 포스처 기능을 제공합니다. AnyConnect 버전 4.0 ISE Posture 모듈은 NAC 에이전트와 동일하게 작동하므로 이 문서에서는 NAC 에이전트라고 합니다. 클라이언트에 대한 상태 장애의 가장 일반적인 증상은 작동 시나리오가 항상 NAC 상담원 창을 팝업 하고 PC를 분석 하기 때문에 NAC 상담원이 팝업 되지 않습니다. 이 문서는 상태 실패 할 수 있는 여러 원인을 좁히는 데 도움이 됩니다. 즉 NAC Agent가 팝업 되지 않습니다. NAC 상담원 로그는 Cisco TAC (Technical Assistance Center)에 의해서만 디코딩 할 수 있으며 가능한 근본 원인 이 많기 때문에 총망라하지 않습니다. 그러나 그것은 상황을 명확히 하 고 단순히 "상담원 상태 분석과 함께 팝업 하지 않습니다"보다 더 문제를 정확히 파악 하 고 아마도 가장 일반적인 원인을 해결하는 데 도움이 될 것입니다.

사전 요구 사항

요구 사항

이 문서에 나열된 시나리오, 증상 및 단계는 초기 설정이 이미 완료된 후 문제를 해결할 수 있도록 작성되었습니다. 초기 컨피그레이션은 Cisco.com의 Cisco ISE 컨피그레이션 가이드에서 Posture Services를 참조하십시오.

사용되는 구성 요소

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

• ISE 버전 1.2.x
• ISE용 NAC Agent 버전 4.9.x
• AnyConnect 버전 4.0

참고: 릴리스 노트에 주요 동작 변경이 나타나지 않는 한 이 정보는 ISE의 다른 릴리스에도 적용할 수 있어야 합니다.

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

문제 해결 방법론

상담원이 팝업되는 이유는 무엇입니까?

에이전트가 ISE 노드를 검색하면 팝업됩니다. 에이전트가 전체 네트워크 액세스 권한이 없고 포스처 리디렉션 시나리오에 있는 것을 감지하면 지속적으로 ISE 노드를 찾습니다.

에이전트 검색 프로세스의 세부 사항을 설명하는 Cisco.com 문서가 있습니다. NAC(Network Admission Control) Agent Discovery Process for Identity Services Engine. 이 문서에서는 콘텐츠 중복을 방지하기 위해 핵심 사항에 대해서만 설명합니다.

클라이언트가 연결되면 RADIUS 인증(MAC 필터링 또는 802.1x)을 거치게 되며, ISE는 리디렉션 ACL(Access Control List)과 리디렉션 URL을 네트워크 장치(스위치, ASA(Adaptive Security Appliance) 또는 무선 컨트롤러)에 반환하여 클라이언트 트래픽이 IP 주소 및 DNS(Domain Name Server) 확인만 받도록 제한합니다. 클라이언트에서 오는 모든 HTTP(S) 트래픽은 ISE 포털 자체로 향하는 트래픽을 제외하고 CPP(Client Posture and Provisioning)로 끝나는 ISE의 고유한 URL로 리디렉션됩니다. NAC Agent는 기본 게이트웨이에 일반 HTTP GET 패킷을 보냅니다. 상담원이 CPP 리디렉션 이외의 다른 응답을 받지 못하거나 다른 응답을 받는 경우, 상담원은 자신을 전체 연결로 간주하여 상태 확인을 진행하지 않습니다. 특정 ISE 노드 끝에서 CPP URL로 리디렉션되는 HTTP 응답을 수신하면 포스처 프로세스를 계속하고 해당 ISE 노드에 연결합니다. 해당 ISE 노드에서 포스처 세부사항을 성공적으로 수신할 때만 팝업되고 분석이 시작됩니다.

NAC Agent는 구성된 검색 호스트 IP 주소에도 도달합니다(둘 이상의 구성이 예상되지 않음). 또한 세션 ID가 있는 리디렉션 URL을 가져오기 위해 리디렉션되어야 합니다. 검색 IP 주소가 ISE 노드인 경우, 올바른 세션 ID를 얻기 위해 리디렉션될 때까지 대기하므로 검색하지 않습니다. 따라서 검색 호스트는 일반적으로 필요하지 않지만 리디렉션을 트리거하기 위해 리디렉션 ACL 범위에서 임의의 IP 주소로 설정할 경우 유용할 수 있습니다(예: VPN 시나리오에서처럼).

가능한 원인

리디렉션이 발생하지 않음

이것은 지금까지 가장 흔한 원인이다. 유효성을 검사하거나 무효화하려면 에이전트가 팝업되지 않는 PC에서 브라우저를 열고 URL을 입력할 때 포스처 에이전트 다운로드 페이지로 리디렉션되는지 확인합니다. 또한 가능한 DNS 문제를 방지하기 위해 http://1.2.3.4과 같은 임의 IP 주소를 입력할 수 있습니다(IP 주소가 리디렉션되지만 웹 사이트 이름이 리디렉션되지 않는 경우 DNS를 확인할 수 있습니다).

리디렉션되는 경우 에이전트 로그 및 ISE 지원 번들(디버그 모드를 위한 상태 및 스위스 모듈 포함)을 수집하고 Cisco TAC에 문의해야 합니다. 이는 에이전트가 ISE 노드를 검색하지만 포스처 데이터를 가져오는 과정에서 오류가 발생했음을 나타냅니다.

리디렉션이 발생하지 않을 경우 첫 번째 원인이 있으며, 이 경우 근본 원인에 대한 추가 조사가 필요합니다. 먼저 네트워크 액세스 장치(WLC(Wireless LAN Controller) 또는 스위치)의 구성을 확인하고 이 문서의 다음 항목으로 이동하십시오.

네트워크 디바이스에 특성이 설치되지 않았습니다.

이 문제는 Redirection Does Not Happen 시나리오의 하위 케이스입니다. 리디렉션이 발생하지 않는 경우, 첫 번째 방법은 클라이언트가 스위치 또는 무선 액세스 레이어에 의해 올바른 상태로 올바르게 배치되었는지 확인하는 것입니다(특정 클라이언트에 문제가 발생함).

다음은 클라이언트가 연결된 스위치에서 실행된 show access-session interface <interface number> detail 명령(일부 플랫폼의 끝에 세부 정보를 추가해야 할 수 있음)의 출력 예입니다. 상태가 "Authz success(인증 성공)"인지, URL 리디렉션 ACL이 의도한 리디렉션 ACL을 올바르게 가리키는지, URL 리디렉션이 URL 끝에 CPP가 있는 예상 ISE 노드를 가리키는지 확인해야 합니다. ACS ACL 필드는 ISE의 권한 부여 프로파일에서 다운로드 가능한 액세스 목록을 구성한 경우에만 표시되므로 필수 필드가 아닙니다. 그러나 이를 살펴보고 리디렉션 ACL과 충돌이 없는지 확인하는 것이 중요합니다(의심스러운 경우 포스처 컨피그레이션에 대한 문서 참조).

01-SW3750-access#show access-sess gi1/0/12 det
            Interface:  GigabitEthernet1/0/12
          MAC Address:  000f.b049.5c4b
           IP Address:  192.168.33.201
            User-Name:  00-0F-B0-49-5C-4B
               Status:  Authz Success
               Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
       Oper host mode:  single-host
     Oper control dir:  both
        Authorized By:  Authentication Server
          Vlan Policy:  N/A
              ACS ACL:  xACSACLx-IP-myDACL-51519b43
     URL Redirect ACL:  redirect
         URL Redirect:  https://ISE2.wlaaan.com:8443/guestportal/gateway?
                        sessionId=C0A82102000002D8489E0E84&action=cpp
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  C0A82102000002D8489E0E84
      Acct Session ID:  0x000002FA
               Handle:  0xF60002D9

Runnable methods list:

       Method   State
       mab      Authc Success

AireOS를 실행하는 WLC의 문제를 해결하려면 show wireless client detail <mac address>를 입력하고 Cisco IOS-XE를 실행하는 WLC의 문제를 해결하려면 show wireless client mac-address <mac address> detail을 입력합니다. 유사한 데이터가 표시되고 리디렉션 URL 및 ACL을 확인해야 하며 클라이언트가 "POSTURE_REQD" 상태이거나 유사한 경우(소프트웨어 버전에 따라 다름) 확인해야 합니다.

특성이 없는 경우 트러블슈팅 중이던 클라이언트의 ISE에서 인증 세부 정보를 열고(Operations(운영) > Authentications(인증)로 이동) Result(결과) 섹션에서 리디렉션 특성이 전송되었는지 확인해야 합니다. 이러한 특성이 전송되지 않은 경우 이 특정 클라이언트에 대해 특성이 반환되지 않은 이유를 이해하기 위해 권한 부여 정책을 검토해야 합니다. 아마 한 가지 조건이 맞지 않았을 텐데 하나하나 트러블슈팅을 해보는 게 좋을 것 같습니다.

리디렉션 ACL과 관련하여 Cisco IOS^{®는 permit 문}에서 리디렉션하지만(ISE 및 DNS IP 주소를 거부해야 함), WLC의 AireOS는 deny 문(ISE 및 DNS에 대해 허용됨)에서 리디렉션합니다.

특성이 있지만 네트워크 디바이스가 리디렉션되지 않음

이 경우 주요 원인은 컨피그레이션 문제입니다. Cisco.com의 컨피그레이션 가이드 및 컨피그레이션 예와 비교하여 네트워크 디바이스의 컨피그레이션을 검토해야 합니다. 이 경우 일반적으로 네트워크 디바이스의 모든 포트 또는 AP(Access Point)에서 문제가 발생합니다. 그렇지 않은 경우 일부 스위치 포트 또는 일부 AP에서만 문제가 발생할 수 있습니다. 이 경우 문제가 발생한 포트 또는 AP의 컨피그레이션을 포스처가 제대로 작동하는 포트 또는 AP와 비교해야 합니다.

FlexConnect AP는 각각 고유한 컨피그레이션을 가질 수 있으며 다른 AP가 아닌 일부 AP에서 ACL 또는 VLAN을 실수하기 쉽기 때문에 매우 민감합니다.

또 다른 일반적인 문제는 클라이언트 VLAN에 SVI가 없다는 것입니다. 이는 스위치에만 적용되며 Catalyst 3750 Series 스위치의 ISE 트래픽 리디렉션에 자세히 설명되어 있습니다. 속성 관점에서 보면 모든 것이 좋아 보일 수 있습니다.

DACL(Interfering Downloadable Access-list)

리디렉션 특성과 동시에 DACL을 스위치로 다시 푸시할 경우(또는 무선 컨트롤러의 경우 Airespace-ACL) 리디렉션을 차단할 수 있습니다. DACL이 먼저 적용되고 완전히 삭제되는 항목과 처리할 항목을 결정합니다. 그런 다음 리디렉션 ACL이 적용되고 리디렉션되는 항목을 결정합니다.

이것이 구체적으로 의미하는 것은 대부분의 경우 DACL에서 모든 HTTP 및 HTTPS 트래픽을 허용해야 한다는 것입니다. 차단하면 그 전에 삭제되므로 리디렉션되지 않습니다. 이러한 트래픽은 이후에 리디렉션 ACL에서 대부분 리디렉션되므로 네트워크에서 실제로 허용되지 않습니다. 그러나 DACL에서 이러한 두 가지 유형의 트래픽을 허용해야 이후에 리디렉션 ACL에 도달할 수 있습니다.

잘못된 NAC Agent 버전

특정 NAC Agent 버전은 특정 버전의 ISE에 대해 검증된다는 사실을 쉽게 잊을 수 있습니다. 많은 관리자가 ISE 클러스터를 업그레이드하고 클라이언트 프로비저닝 결과 데이터베이스에 관련 NAC 에이전트 버전을 업로드하는 것을 잊습니다.

ISE 코드에 오래된 NAC Agent 버전을 사용하는 경우, 이 버전이 작동할 수 있지만 작동하지 않을 수도 있습니다. 그래서 어떤 고객들은 일을 하고 어떤 고객들은 일을 하지 않는 것은 놀랄 일이 아니다. 한 가지 확인 방법은 ISE 버전의 Cisco.com 다운로드 섹션으로 이동하여 어떤 NAC Agent 버전이 있는지 확인하는 것입니다. 일반적으로 각 ISE 버전에 대해 몇 가지 기능이 지원됩니다. 이 웹 페이지는 모든 매트릭스, Cisco ISE 호환성 정보를 수집 합니다.

클라이언트에서 HTTP 웹 프록시를 사용 중입니다.

HTTP 웹 프록시의 개념은 클라이언트가 웹 사이트 DNS IP 주소를 직접 확인하지 않고 웹 사이트에 직접 연결하지 않고, 프록시 서버로 요청을 전송하기만 하면 처리된다는 것입니다. 일반적인 컨피그레이션의 일반적인 문제는 클라이언트가 웹 사이트(예: www.cisco.com)에 대한 HTTP GET을 프록시에 직접 전송하여 해결한다는 것입니다. 프록시는 인터셉트되어 ISE 포털로 올바르게 리디렉션됩니다. 그러나 다음 HTTP GET을 ISE 포털 IP 주소로 전송하는 대신 클라이언트는 해당 요청을 프록시로 계속 전송합니다.

프록시로 향하는 HTTP 트래픽을 리디렉션하지 않기로 결정한 경우 모든 트래픽이 프록시를 통과하므로 사용자는 인증 또는 포스처 없이 전체 인터넷에 직접 액세스할 수 있습니다. 해결 방법은 클라이언트의 브라우저 설정을 실제로 수정하고 프록시 설정에서 ISE IP 주소에 대한 예외를 추가하는 것입니다. 이렇게 하면 클라이언트가 ISE에 연결해야 할 때 프록시가 아닌 ISE에 직접 요청을 보냅니다. 이렇게 하면 클라이언트가 지속적으로 리디렉션되지만 로그인 페이지는 표시되지 않는 무한 루프가 방지됩니다.

NAC Agent는 시스템에 입력된 프록시 설정의 영향을 받지 않으며 계속 정상적으로 작동합니다. 즉, 웹 프록시를 사용하는 경우 NAC Agent 검색이 작동하게 할 수 없고(포트 80을 사용하므로), 사용자가 포스처 페이지로 리디렉션된 후 탐색할 때(프록시 포트를 사용하고 일반 스위치는 여러 포트에서 리디렉션할 수 없으므로) 사용자가 에이전트를 직접 설치하도록 할 수 없습니다.

검색 호스트가 NAC Agent에 구성 되어 있습니다

특히 ISE 버전 1.2 이후에는 NAC Agent에서 수행하는 작업과 수행하지 않는 작업에 대한 전문 지식이 없는 한 NAC Agent에서 검색 호스트를 구성하지 않는 것이 좋습니다. NAC 에이전트는 HTTP 검색을 통해 클라이언트 디바이스를 인증한 ISE 노드를 검색해야 합니다. 검색 호스트에 의존하는 경우 NAC Agent가 디바이스를 인증했지만 작동하지 않는 다른 ISE 노드에 연결하게 할 수 있습니다. ISE 버전 1.2에서는 검색 호스트 프로세스를 통해 노드를 검색하는 에이전트를 거부합니다. NAC 에이전트가 리디렉션 URL에서 세션 ID를 가져오도록 하려면 이 방법을 사용하지 않는 것이 좋습니다.

경우에 따라 검색 호스트를 구성할 수 있습니다. 그런 다음 리디렉션 ACL에 의해 리디렉션되는 IP 주소(존재하지 않더라도)로 구성해야 하며 클라이언트와 동일한 서브넷에 있지 않아야 합니다. 그렇지 않으면 클라이언트가 해당 클라이언트에 대해 무기한 ARP를 수행하므로 HTTP 검색 패킷을 전송하지 않습니다.

NAC Agent가 가끔 팝업 되지 않습니다

문제가 더 간헐적으로 발생하고 케이블/WiFi 연결의 플러그를 뽑거나 다시 꽂는 등의 동작이 작동하게 되면 더 미묘한 문제가 됩니다. RADIUS 어카운팅에 의해 세션 ID가 ISE에서 삭제되는 RADIUS 세션 ID의 문제일 수 있습니다(어떤 것이 변경되는지 확인하기 위해 어카운팅을 비활성화합니다).

ISE 버전 1.2를 사용하는 경우, 클라이언트가 브라우저 또는 NAC 에이전트에서 아무 것도 나오지 않도록 많은 HTTP 패킷을 전송할 수도 있습니다. ISE 버전 1.2는 HTTP 패킷의 user-agent 필드를 검사하여 NAC 에이전트나 브라우저에서 온 것인지 확인하지만, 다른 많은 애플리케이션은 user-agent 필드와 함께 HTTP 트래픽을 전송하고 운영 체제나 유용한 정보는 언급하지 않습니다. 그런 다음 ISE 버전 1.2에서 Change of Authorization을 전송하여 클라이언트 연결을 끊습니다. ISE 버전 1.3은 다른 방식으로 작동하므로 이 문제의 영향을 받지 않습니다. 이 솔루션은 버전 1.3으로 업그레이드하거나 리디렉션 ACL에서 탐지된 모든 애플리케이션이 ISE로 리디렉션되지 않도록 허용하는 것입니다.

역문제: 상담원이 반복적으로 팝업합니다.

또 다른 문제는 상담원이 팝업으로 표시되고, 포스처 분석을 수행하고, 클라이언트를 검증한 후, 네트워크 연결을 허용하고 침묵하는 대신 잠시 후에 다시 팝업되는 경우입니다. 이는 성공적인 포스처 이후에도 HTTP 트래픽이 여전히 ISE의 CPP 포털로 리디렉션되기 때문입니다. 그런 다음 ISE 권한 부여 정책을 살펴보고 CPP 리디렉션이 아닌 규정 준수 클라이언트가 다시 발견될 때 허용 액세스(또는 가능한 ACL 및 VLAN이 있는 유사 규칙)를 전송하는 규칙이 있는지 확인하는 것이 좋습니다.

관련 정보

• Cisco ISE 컨피그레이션 가이드의 포스처 서비스
• ISE를 위한 NAC Agent 검색 프로세스
• Catalyst 3750 Series 스위치의 ISE 트래픽 리디렉션
• 기술 지원 및 문서 − Cisco Systems