AnyConnect Optimal Gateway Selection 문제 해결 가이드

소개

이 문서에서는 OGS(Optimal Gateway Selection) 문제를 해결하는 방법에 대해 설명합니다. OGS는 RTT(Round Trip Time)가 가장 낮은 게이트웨이를 확인하고 해당 게이트웨이에 연결하기 위해 사용할 수 있는 기능입니다. 사용자 개입 없이 인터넷 트래픽에 대한 레이턴시를 최소화하기 위해 OGS 기능을 사용할 수 있습니다. Cisco AnyConnect Secure Mobility Client(AnyConnect)는 OGS를 통해 연결 또는 재연결에 가장 적합한 보안 게이트웨이를 식별하고 선택합니다. OGS는 첫 번째 연결 시 또는 이전 연결이 끊어진 후 최소 4시간 후에 다시 연결할 때 시작합니다. 자세한 내용은 관리자 설명서를 참조하십시오.

팁: OGS는 최신 AnyConnect 클라이언트 및 ASA 소프트웨어 버전 9.1(3)* 이상에서 가장 효과적입니다.

OGS는 어떻게 작동합니까?

많은 Cisco ASA(Adaptive Security Appliance) 방화벽이 검색을 방지하기 위해 ICMP 패킷을 차단하도록 구성되어 있으므로 단순 ICMP(Internet Control Message Protocol) ping 요청이 작동하지 않습니다. 대신 클라이언트는 모든 프로파일을 병합하는 데 나타나는 각 헤드엔드에 세 개의 HTTP/443 요청을 보냅니다. 이러한 HTTP 프로브는 로그에서 OGS ping이라고 하지만, 앞에서 설명한 것처럼 ICMP ping은 아닙니다. (재)연결이 너무 오래 걸리지 않도록 하기 위해 OGS는 7초 내에 OGS ping 결과를 수신하지 않는 경우 기본적으로 이전 게이트웨이를 선택합니다. (로그에서 OGS ping 결과를 확인합니다.)

참고: AnyConnect는 성공적인 응답이 아니라 응답 자체가 중요하므로 HTTP 요청을 443으로 보내야 합니다. 안타깝게도 프록시 처리를 위한 수정 사항은 모든 요청을 HTTPS로 전송합니다. 참조: Cisco 버그 ID CSCtg38672 - OGS should ping with HTTP requests.

참고: 캐시에 헤드엔드가 없는 경우 AnyConnect는 먼저 인증 프록시가 있는지, 요청을 처리할 수 있는지 확인하기 위해 HTTP 요청 하나를 전송합니다. 이 초기 요청 후에야 서버를 프로브하기 위해 OGS ping을 시작합니다.

• OGS는 DNS(Domain Name System) 접미사 및 DNS 서버 IP 주소와 같은 네트워크 정보를 기반으로 사용자 위치를 결정합니다. 이 위치와 함께 RTT 결과가 OGS 캐시에 저장됩니다.
  
  
• OGS 위치 항목은 14일 동안 캐시됩니다. Cisco 버그 ID CSCtk66531가 이러한 설정을 사용자가 구성할 수 있도록 하기 위해 제출되었습니다.
  
  
• OGS는 위치 항목이 처음 캐시된 후 14일이 지나야 이 위치에서 다시 실행됩니다. 이 시간 동안 캐시된 엔트리와 해당 위치에 대해 결정된 RTT를 사용합니다. 즉, AnyConnect가 다시 시작될 때 OGS를 다시 수행하지 않고, 대신 해당 위치에 대해 캐시에서 최적의 게이트웨이 순서를 사용합니다. DART(Diagnostic AnyConnect Reporting Tool) 로그에 다음 메시지가 표시됩니다.
  
  

  ******************************************
  Date : 10/04/2013
  Time : 14:00:44
  Type : Information
  Source : acvpnui
  
  Description : Function: ClientIfcBase::startAHS
  File: .\ClientIfcBase.cpp
  Line: 2785
  OGS was already performed, previous selection will be used.
  
  ******************************************

• RTT는 사용자가 AnyConnect 프로필의 호스트 항목에 지정된 대로 연결을 시도할 게이트웨이의 SSL(Secure Sockets Layer) 포트로의 TCP 교환을 통해 결정됩니다.
  
  

  참고: 간단한 HTTP 게시를 수행한 다음 RTT 및 결과를 표시하는 HTTP-ping과 달리 OGS 계산은 약간 더 복잡합니다. AnyConnect는 각 서버에 대해 세 개의 프로브를 전송하고, 전송하는 HTTP SYN과 각 프로브에 대한 FIN/ACK 간의 지연 시간을 계산합니다. 그런 다음 서버를 비교하고 선택하기 위해 가장 낮은 델타를 사용합니다. 따라서 HTTP-ping은 AnyConnect가 어떤 서버를 선택할지 잘 나타내지만, 반드시 계산하지는 않을 수 있습니다. 문서의 나머지 부분에 이에 대한 자세한 내용이 있습니다.

• 현재 OGS는 사용자가 일시 중단에서 벗어나고 임계값을 초과한 경우에만 검사를 실행합니다. 사용자가 연결된 ASA가 충돌하거나 사용할 수 없게 될 경우 OGS는 다른 ASA에 연결되지 않습니다. OGS는 최적의 서버를 결정하기 위해 프로필의 기본 서버에만 연결합니다.
  
  
• OGS 클라이언트 프로파일을 다운로드한 후 사용자가 AnyConnect 클라이언트를 다시 시작하면 다음과 같이 다른 프로파일을 선택하는 옵션이 회색으로 표시됩니다.
  
  
  
  사용자 시스템에 다른 프로파일이 여러 개 있는 경우에도 OGS를 비활성화할 때까지 둘 중 하나를 선택할 수 없습니다.

OGS 캐시

계산이 완료되면 preferences_global 파일에 결과가 저장됩니다. 이전에 이 데이터가 파일에 저장되지 않은 문제가 있었습니다.

자세한 내용은 Cisco 버그 ID CSCtj84626를 참조하십시오.

위치 결정

OGS 캐싱은 DNS 도메인과 개별 DNS 서버 IP 주소의 조합에서 작동합니다. 다음과 같이 작동합니다.

• 위치 A에는 DNS 도메인인 locationa.com과 두 개의 DNS 서버 IP 주소(ip1 및 ip2)가 있습니다. 각 도메인/IP 조합은 OGS 캐시 항목을 가리키는 캐시 키를 생성합니다. 예를 들면 다음과 같습니다.
  • locationa.com|ip1 -> ogscache1
  • locationa.com|ip2 -> ogscache1
• 그러면 AnyConnect가 물리적으로 다른 네트워크에 연결되는 경우, 동일한 도메인/IP 조합 통합이 생성되어 캐시된 목록에 대해 확인됩니다. 일치하는 항목이 조금이라도 있으면 해당 OGS 캐시 값이 사용되며 클라이언트는 여전히 위치 A에 있는 것으로 간주됩니다.

실패 시나리오

다음은 사용자에게 발생할 수 있는 몇 가지 실패 시나리오입니다.

게이트웨이에 대한 연결이 끊긴 경우

OGS를 사용할 때 사용자가 연결된 게이트웨이에 대한 연결이 끊기면 AnyConnect는 백업 서버 목록및아님 다음 OGS 호스트로 이동합니다. 작동 순서는 다음과 같습니다.

1. OGS는 최적의 서버를 결정하기 위해 기본 서버에만 접속합니다.
   
   
2. 연결 알고리즘이 결정되면 다음과 같습니다.
   
   1. 최적의 서버에 연결하려고 합니다.
   2. 실패할 경우 최적의 서버의 백업 서버 목록을 시도합니다.
   3. 실패할 경우 선택 결과에 따라 순서가 지정된 OGS 선택 목록에 남아 있는 각 서버를 시도합니다.

참고: 관리자가 백업 서버 목록을 구성할 때 현재 프로파일 편집기에서는 관리자가 백업 서버에 대해 FQDN(정규화된 도메인 이름)만 입력할 수 있지만 기본 서버에 대해 가능한 사용자 그룹은 입력할 수 없습니다.

이를 수정하기 위해 Cisco 버그 ID CSCud84778가 제출되었지만 백업 서버의 호스트 주소 필드에 전체 URL을 입력해야 하며, 이 URL이 제대로 작동해야 합니다. https://<ip-address>/usergroup.

일시 중단 후 다시 시작

재개 후 OGS를 실행하려면 시스템을 절전 모드로 전환했을 때 AnyConnect에 연결이 설정되어 있어야 합니다. 재시작 후 OGS는 네트워크 환경 테스트가 수행된 후에만 수행되며, 이는 네트워크 연결이 사용 가능한지 확인하는 의미입니다. 이 테스트에는 DNS 연결 하위 테스트가 포함되어 있습니다.

그러나 DNS 서버가 쿼리 필드에 IP 주소가 있는 유형 A 요청을 삭제하는 경우, "name not found"(일반적으로 테스트 중에 항상 발생)로 회신하는 대신 Cisco 버그 ID가 삭제됩니다 CSCti20768 "IP 주소에 대한 유형 A의 DNS 쿼리는 시간 초과를 방지하기 위해 PTR이어야 합니다"가 적용됩니다. 

TCP Delayed-ACK Window Size Selects Incorrect Gateway

버전 9.1(3) 이전의 ASA 버전을 사용하는 경우 클라이언트의 캡처에서 SSL 핸드셰이크의 지속적인 지연을 표시합니다. 여기서 주의할 점은 클라이언트가 ClientHello를 전송한 다음 ASA가 ServerHello를 전송한다는 것입니다. 이 메시지 다음에는 일반적으로 인증서 메시지(선택적 인증서 요청) 및 ServerHelloDone 메시지가 옵니다. 이상 징후는 두 가지입니다.

1. ASA는 ServerHello 이후에 즉시 인증서 메시지를 보내지 않습니다. 클라이언트 윈도우 크기는 64,860바이트이며, 이는 ASA의 전체 응답을 보유할 수 있는 양보다 큽니다.
   
   
2. 클라이언트는 ServerHello를 즉시 ACK하지 않으므로 ASA는 ~120ms 후에 ServerHello를 재전송하며, 이 시점에서 클라이언트는 데이터를 ACK합니다. 그런 다음 인증서 메시지가 전송됩니다. 마치 클라이언트가 더 많은 데이터를 기다리는 것과 같습니다.

이는 TCP slow-start와 TCP delayed-ACK 간 상호 작용 때문에 발생합니다. ASA 버전 9.1(3) 이전에는 ASA가 느린 시작 윈도우 크기 1을 사용하는 반면, Windows 클라이언트는 지연된 ACK 값 2를 사용합니다. 즉, ASA는 ACK를 받을 때까지 하나의 데이터 패킷만 전송하지만, 클라이언트는 두 개의 데이터 패킷을 받을 때까지 ACK를 전송하지 않습니다. ASA는 120ms 후에 시간 초과되고 ServerHello를 재전송하며, 그 후 클라이언트는 데이터를 ACK하고 연결이 계속됩니다. 이 동작은 Cisco 버그 ID CSCug98113에 의해 변경되어 ASA는 기본적으로 느린 시작 윈도우 크기를 1이 아닌 2로 사용합니다.

다음과 같은 경우 OGS 계산에 영향을 줄 수 있습니다.

• 각 게이트웨이는 서로 다른 ASA 버전을 실행합니다.
• 클라이언트의 delayed-ACK 창 크기가 서로 다릅니다.

이러한 상황에서 delayed-ACK에 의해 도입된 지연은 클라이언트가 잘못된 ASA를 선택하는 데 충분할 수 있습니다. 클라이언트와 ASA 간에 이 값이 다를 경우 문제가 발생할 수 있습니다. 이러한 경우 해결 방법은 Delayed Acknowledgement 창 크기를 조정하는 것입니다.

창

1. 레지스트리 편집기를 시작합니다.
   
   
2. delayed-ACK을 비활성화할 인터페이스의 GUID를 식별합니다. 이 작업을 수행하려면 수신:
   HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > WindowsNT > CurrentVersion > NetworkCards > (number).
   NetworkCards(네트워크 카드) 아래에 나열된 각 번호를 확인합니다. 오른쪽에는 설명서에 인터페이스(예: Intel(R) Wireless WiFi Link 5100AGN)가 표시되고 ServiceName에는 해당 GUID가 표시됩니다.
   
   
3. 다음 레지스트리 하위 키를 찾아 클릭합니다.
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<인터페이스 GUID>
   
   
4. 편집 메뉴에서 새로 만들기를 가리킨 다음 DWORD 값을 클릭합니다.
   
   
5. 새 값의 이름을 TcpAckFrequency로 지정하고 값을 1로 할당합니다.
   
   
6. 레지스트리 편집기를 끝냅니다.
   
   
7. 이 변경 내용을 적용하려면 Windows를 다시 시작하십시오.

참고: ASA에서 TCP 튜닝 매개변수를 구성할 수 있도록 Cisco 버그 ID CSCum19065이 제출되었습니다.

일반적인 사용자 예

가장 일반적인 활용 사례는 재택 근무 사용자가 OGS를 처음 실행할 때 DNS 설정을 기록하고 OGS ping 결과를 캐시에 저장하는 것입니다(기본값은 14일 시간 초과). 사용자가 다음 날 저녁에 집으로 돌아오면 OGS는 동일한 DNS 설정을 탐지하고 캐시에서 이를 찾은 다음 OGS 핑 테스트를 건너뜁니다. 이후 사용자가 인터넷 서비스를 제공하는 호텔이나 레스토랑에 가면 OGS는 서로 다른 DNS 설정을 감지하고 OGS 핑 테스트를 실행한 후 최상의 게이트웨이를 선택하고 그 결과를 캐시에 기록한다.

OGS 및 AnyConnect 재개 설정에서 허용하는 경우, 이 프로세스는 일시 중단 또는 최대 절전 모드에서 다시 시작할 때 동일합니다.

OGS 트러블슈팅

1단계. 재평가를 강제로 수행하려면 OGS 캐시를 지웁니다.

OGS 캐시를 지우고 사용 가능한 게이트웨이의 RTT를 재평가하려면 PC에서 Global AnyConnect Preferences 파일을 삭제하기만 하면 됩니다. 파일 위치는 운영 체제(OS)에 따라 다릅니다.

• Windows Vista 및 Windows 7
  

  C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\preferences_global.xml 
  Note: in older client versions it used to be stored in C:\ProgramData\Cisco\Cisco
   AnyConnect VPN Client

• 윈도 XP
  

  C:\Documents and Settings\AllUsers\Application Data\Cisco\Cisco AnyConnect VPN
  Client\preferences_global.xml

• 맥 OS X
  

  /opt/cisco/anyconnect/.anyconnect_global
  Note: with older versions of the client it used to be /opt/cisco/vpn..

• Linux
  

  /opt/cisco/anyconnect/.anyconnect_global
  Note: with older versions of the client it used to be /opt/cisco/vpn..

2단계. 연결 시도 중 서버 프로브 캡처

1. 테스트 시스템에서 Wireshark를 시작합니다.
   
   
2. AnyConnect에서 연결 시도를 시작합니다.
   
   
3. 연결이 완료되면 Wireshark 캡처를 중지합니다.

   팁: 캡처는 OGS를 테스트하는 데만 사용되므로 AnyConnect에서 게이트웨이를 선택하는 즉시 캡처를 중지하는 것이 좋습니다. 패킷 캡처를 클라우드할 수 있으므로 완전한 연결 시도를 거치지 않는 것이 가장 좋습니다.

3단계. OGS에서 선택한 게이트웨이 확인

OGS가 특정 게이트웨이를 선택한 이유를 확인하려면 다음 단계를 완료하십시오.

1. 새 연결을 시작합니다.
   
   
2. AnyConnect DART 실행:
   
   1. AnyConnect를 시작하고 Advanced(고급)를 클릭합니다.
   2. Diagnostics를 클릭합니다.
   3. Next(다음)를 클릭합니다.
   4. Next(다음)를 클릭합니다.
3. 데스크톱에서 새로 생성된 DartBundle_XXXX_XXXX.zip 파일에 있는 DART 결과를 검토합니다.
   
   1. Cisco AnyConnect Secure Mobility Client(Cisco AnyConnect Secure Mobility 클라이언트) > AnyConnect.txt로 이동합니다.
      
      
   2. 이 DART 로그에서 특정 서버에 대해 OGS 프로브가 시작된 시간을 확인합니다.
      

      ******************************************
      
      Date : 10/04/2013
      Time : 14:21:27
      Type : Information
      Source : acvpnui
      
      Description : Function: CHeadendSelection::CSelectionThread::Run
      File: .\AHS\HeadendSelection.cpp
      Line: 928
      OGS starting thread named gw2.cisco.com
      
      ******************************************

      
      일반적으로 이러한 패킷은 비슷한 시간대에 있어야 하지만, 캡처가 큰 경우 타임스탬프를 사용하면 어떤 패킷이 HTTP 프로브이고 어떤 패킷이 실제 연결 시도인지를 좁힐 수 있습니다.
      
      
   3. AnyConnect가 세 개의 프로브를 서버로 전송하면 각 프로브에 대한 결과와 함께 이 메시지가 생성됩니다.
      

      ******************************************
      
      Date : 10/04/2013
      Time : 14:31:37
      Type : Information
      Source : acvpnui
      
      Description : Function: CHeadendSelection::CSelectionThread::logThreadPingResults
      File: .\AHS\HeadendSelection.cpp
      Line: 1137
      OGS ping results for gw2.cisco.com: (219 218 132 )
      
      ******************************************

      이 세 가지 값은 캡처 결과와 일치해야 하므로 주의해야 합니다.
      
      
   4. 평가된 RTT를 보려면 "*** OGS Selection Results***"가 포함된 메시지를 확인합니다. 가장 최근의 연결 시도가 캐시된 RTT 또는 새 계산의 결과인 경우.
      
      예를 들면 다음과 같습니다.

      ******************************************
      
      Date        : 10/04/2013
      Time        : 12:29:38
      Type        : Information
      Source      : vpnui
      
      Description : Function: CHeadendSelection::logPingResults
      File: .\AHS\HeadendSelection.cpp
      Line: 589
      *** OGS Selection Results ***
      OGS performed for connection attempt. Last server: 'gw2.cisco.com'
      
      Results obtained from OGS cache. No ping tests were performed.
      
      Server Address     RTT (ms)
      gw1.cisco.com     302
      gw2.cisco.com     132            <========= As seen, 132 was the lowest delay
                                       of the three probes from the previous DART log
      gw3.cisco.com     506
      gw4.cisco.com     877
      
      
      Selected 'gw2.cisco.com' as the optimal server.
      
      ******************************************

4단계. AnyConnect에서 실행하는 OGS 계산 검증 

RTT 계산에 사용된 TCP/SSL 프로브의 캡처를 검사합니다. 단일 TCP 연결을 통해 HTTPS 요청을 처리하는 시간을 확인합니다. 각 프로브 요청은 서로 다른 TCP 연결을 사용해야 합니다. 이렇게 하려면 Wireshark에서 캡처를 열고 각 서버에 대해 다음 단계를 반복합니다.

1. ip.addr 필터를 사용하여 각 서버로 전송된 패킷을 고유한 캡처로 격리합니다. 이렇게 하려면 Edit(수정)로 이동하고 Mark All Displayed Packets(표시된 모든 패킷 표시)를 선택합니다. 그런 다음 File(파일) > Save As(다른 이름으로 저장)로 이동하여 Marked packets only(표시된 패킷만) 옵션을 선택하고 Save(저장)를 클릭합니다.
   
   
   
   
2. 이 새 캡처에서 View > Time Display Format > Date and Time of Day로 이동합니다.
   
   
   
   
3. 3.3.2단계에서 확인된 DART 로그를 기반으로 OGS 프로브가 전송될 때 전송된 이 캡처의 첫 번째 HTTP SYN 패킷을 식별합니다. 첫 번째 서버에 대해 첫 번째 HTTP 요청은 서버 프로브가 아니라는 점을 기억해야 합니다. 서버 프로브에 대한 첫 번째 요청을 잘못 생각하기 쉬우므로 OGS에서 보고하는 것과 완전히 다른 값에 도달합니다. 이 문제는 여기서 강조 표시됩니다.
   
   
   
   
4. 각 프로브를 보다 쉽게 식별하려면 첫 번째 프로브에 대한 HTTP SYN을 마우스 오른쪽 버튼으로 클릭한 다음 여기와 같이 대화의 색상화를 선택합니다.
   
   
   
   모든 프로브의 SYN에 대해 이 프로세스를 반복합니다. 이전 이미지에서 볼 수 있듯이 처음 두 프로브는 서로 다른 색상으로 표시됩니다. TCP 대화를 색칠하는 이점은 프로브당 재전송 또는 기타 그러한 문제를 쉽게 찾아내는 것입니다.
   
   
5. 시간 표시를 변경하려면 보기 > 시간 표시 형식 > 시간 표시 이후 시간으로 이동합니다.
   
   
   
   Milliseconds는 OGS에서 사용하는 정밀도 레벨이므로 Milliseconds를 선택합니다.
   
   
6. 4단계 다이어그램에 표시된 대로 HTTP SYN과 FIN/ACK 간의 시간 차이를 계산합니다. 세 개의 프로브 각각에 대해 이 프로세스를 반복하고 3.3.3단계의 DART 로그에 표시된 값과 비교합니다.

분석

캡처 분석 후 결정된 RTT 값이 계산되고 DART 로그에 표시된 값과 비교되고 모든 것이 일치하는 것으로 밝혀졌지만 여전히 잘못된 게이트웨이가 선택된 것처럼 보일 경우 다음 두 가지 문제 중 하나로 인한 것입니다.

• 헤드엔드에 문제가 있습니다. 이 경우 하나의 특정 헤드엔드에서 재전송이 너무 많거나 프로브에서 볼 수 있는 다른 문제가 발생할 수 있습니다. 거래소에 대한 보다 면밀한 분석이 필요하다.
  
  
• 인터넷 서비스 공급자(ISP)에 문제가 있습니다. 이 경우 특정 헤드엔드에 단편화 또는 대규모 지연이 발생할 수 있습니다.

질문과 대답

Q: OGS는 로드 밸런싱과 함께 작동합니까?

A: 네. OGS는 클러스터 마스터 이름만 인식하고 있으며 이를 사용하여 가장 가까운 헤드엔드를 판단합니다.

Q: OGS는 브라우저에 정의된 프록시 설정을 사용합니까?

A: OGS는 자동 프록시 또는 프록시 자동 구성(PAC) 파일을 지원하지 않지만 하드 코딩된 프록시 서버를 지원합니다. 따라서 OGS 작업이 발생하지 않습니다. 관련 로그 메시지는 "자동 프록시 탐지가 구성되었으므로 OGS가 수행되지 않습니다."입니다.