OPM

Horizon 연결 이해

Horizon 및 Blast 연결을 계획하거나 문제를 해결하기 전에 VMware Horizon Client가 리소스에 연결되는 방식을 이해하는 것이 중요합니다. 이를 통해 최상의 아키텍처를 결정하고 트래픽 흐름 및 네트워크 포트를 이해하며 문제 해결에 도움이 될 수 있습니다.

Horizon 연결 서버를 포함하여 VMware Horizon 7이 여기에 사용되지만 여기에 설명 된 대부분의 내용은 VMware Horizon Cloud에도 적용됩니다. 이 가이드는 Blast Extreme 연결에 중점을두고 있지만, 특히 연결 이해에 관한 대부분의 내용은 PCoIP 연결에도 적용됩니다.

이 가이드의 목적

이 가이드는 VMware Horizon Client와 리소스 간의 연결과 VMware Horizon 7 및 Horizon Cloud Services 모두에서 연결 문제를 해결하는 데 이러한 이해를 적용하는 방법에 중점을 둡니다.

대상 청중

이 가이드는 VMware vSphere 및 VMware vCenter Server®에 익숙한 IT 관리자 및 제품 평가자를 대상으로합니다. 가상 환경, Active Directory, ID 관리 및 디렉터리 서비스의 네트워킹 및 스토리지에 익숙하다고 가정합니다. Horizon 7과 같은 다른 기술에 대한 지식도 도움이됩니다.

구성 요소

Horizon 연결에 사용되는 Horizon 7의 핵심 구성 요소는 다음 표에 설명되어 있습니다.

표 1 : Horizon 7 구성 요소

1 차 및 2 차 프로토콜

먼저 Horizon Client가 Horizon 환경에 연결될 때 여러 다른 프로토콜이 사용되며 성공적인 연결은 두 단계로 구성된다는 점을 이해하는 것이 중요합니다.

연결의 첫 번째 단계는 항상 인증, 권한 부여 및 세션 관리를 제공하는 HTTPS를 통한 기본 XML-API 프로토콜입니다. 인증에 성공하면 하나 이상의 보조 프로토콜을 사용하여 리소스에 연결됩니다.

Horizon 7의 구성 요소 및 아키텍처를 탐색하려면 VMware Workspace ONE 및 VMware Horizon 참조 아키텍처 의 구성 요소 설계 : Horizon 7 아키텍처 섹션 을 참조하십시오.

내부 연결

내부 연결은 Horizon Client가 연결 서버에 직접 연결 한 다음 Horizon Agent에 직접 연결하는 연결입니다. 일반적으로 이것은 회사 네트워크 내부의 연결을위한 것입니다.

초기 인증 단계에서 연결은 Horizon Client에서 연결 서버로 이루어집니다. 그런 다음 보조 프로토콜 세션은 일반적으로 Horizon Client에서 Horizon Agent로 직접 연결됩니다.

보조 프로토콜 연결은 Connection Server 에서 게이트웨이 또는 터널 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 또는 HTTPS 보안 터널)이 활성화 된 경우에만 연결 서버를 통해 라우팅됩니다. 이 구성은 프로토콜 세션이 Connection Server를 통해 터널링되어 진행중인 세션의 일부가되므로 덜 일반적입니다.

대부분의 일반적인 배포에서 연결 서버에 사용되는 유일한 게이트웨이 서비스는 VMware HTML Access (웹 기반 클라이언트) 트래픽을 처리하는 데만 사용되는 Blast 보안 게이트웨이입니다. 이 내용은이 가이드 뒷부분의 HTML 클라이언트 액세스 연결 섹션에서 별도의 항목으로 다룹니다 .

커뮤니케이션 흐름

1. Horizon Client가 연결 서버에 로그인
   • 연결 서버는 사용자의 권한을 조회합니다.
   • 사용자가 데스크톱 또는 앱을 선택합니다.
2. Horizon Client는 데스크톱 / RDSH에서 실행중인 Horizon Agent에 연결됩니다.

위의 다이어그램은 세 개의 개별 네트워크 영역을 보여 주지만 구성 요소 사이에 방화벽이없는 동일한 네트워크에 모든 내부 구성 요소를 포함하는 것도 지원됩니다.

Load Balancing

연결 서버의 부하를 분산 할 때 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리) 만 부하 분산하면됩니다. 보조 프로토콜 연결은 Horizon Client에서 Horizon Agent로 직접 이동하기 때문에로드 밸런싱되지 않습니다.

Network Port

구성 요소 간의 성공적인 연결과 올바른 통신을 보장하려면 Horizon 7 배포에서 연결을위한 네트워크 포트 요구 사항을 이해하는 것이 중요합니다.

아래 다이어그램은 가능한 각 디스플레이 프로토콜과 대상 네트워크 포트를 사용하는 내부 연결을 보여줍니다.

참고 :

• 화살표는 트래픽 시작 방향 (소스에서 목적지로)을 나타냅니다.
• Horizon UDP 프로토콜은 양방향이므로 UDP 응답 데이터 그램을 허용하도록 상태 저장 방화벽을 구성해야합니다.

다음 다이어그램은 내부 Blast Extreme 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 내부 PCoIP 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 내부 RDP를 허용하는 데 필요한 포트를 보여줍니다.

VMware Horizon 7 의 네트워크 포트 가이드 에는 트래픽을 보여주는 다이어그램과 함께 자세한 내용이 있습니다. 내부, 외부 및 터널링 된 연결에 대한 특정 섹션과 다이어그램도 있습니다. 외부 연결에 필요한 네트워크 포트에 대한 자세한 내용 은 VMware Horizon 7 : 내부 연결 및 내부 연결 다이어그램의 네트워크 포트를 참조하십시오 .

외부 연결

외부 연결 인 경우 통신은 일반적으로 VMware Unified Access Gateway 장치를 통해 이루어집니다. 연결의 초기 인증 단계는 Horizon Client에서 Unified Access Gateway 장치로 이동 한 다음 연결 서버로 이동하는 것입니다. 프로토콜 세션 연결은 Horizon Client에서 Unified Access Gateway로 이동 한 다음 Horizon Agent로 이동합니다.

Unified Access Gateway는 Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널과 같은 게이트웨이 서비스를 실행할 수 있습니다. Blast 보안 게이트웨이 및 PCoIP 보안 게이트웨이도 연결 서버에서 활성화되어 있지 않은지 확인하십시오. 이렇게하면 프로토콜 트래픽의 이중 홉 시도가 발생하여 지원되지 않고 연결이 실패하게됩니다.

Communication Flow

위의 그림은 연결 흐름을 보여줍니다.

1. 사용자는 Horizon Client를 사용하여 Unified Access Gateway를 통해 연결 서버에 로그인합니다.
   • 연결 서버는 사용자의 권한을 조회합니다.
   • 사용자는 연결할 데스크톱 또는 애플리케이션 리소스를 선택합니다.
2. Horizon Client는 데스크톱 또는 RDSH에서 실행중인 Horizon Agent에 연결됩니다.
   • 이는 사용자가 인증 된 장치와 동일한 Unified Access Gateway 장치에서 Blast 보안 게이트웨이를 통해 이루어집니다.

Load Balancing

Horizon 트래픽을 여러 Unified Access Gateway 장치로로드 밸런싱 할 때 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리)을 로드 밸런싱해야합니다. 보조 Horizon 프로토콜은 기본 Horizon XML-API 프로토콜이 라우팅 된 것과 동일한 Unified Access Gateway 장치로 라우팅되어야합니다. 이를 통해 Unified Access Gateway는 인증 된 사용자 세션을 기반으로 보조 프로토콜을 승인 할 수 있습니다.

보조 프로토콜 세션이 기본 프로토콜과 다른 Unified Access Gateway 장치로 잘못 라우팅되면 세션이 승인되지 않습니다. 따라서 연결이 DMZ에서 삭제되고 프로토콜 연결이 실패합니다. 로드 밸런서가 올바르게 구성되지 않은 경우 보조 프로토콜 세션을 잘못 라우팅하는 것은 일반적인 문제입니다.

로드 밸런서 선호도는 세션의 전체 기간 (기본 최대 10 시간) 동안 만들어진 XML-API 연결이 동일한 Unified Access Gateway 장치로 계속 라우팅되도록해야합니다.

보조 프로토콜 세션은 기본 XML-API 연결에 사용 된 것과 동일한 Unified Access Gateway 장치로 라우팅되어야하지만 보조 프로토콜 세션이로드 밸런서를 통해 라우팅되는지 여부를 선택할 수 있습니다. 이는 일반적으로로드 밸런서의 기능에 따라 다릅니다.

예를 들어 F5 BIG-IP LTM (Local Traffic Manager)을 사용하면 기본 및 보조 프로토콜 트래픽이 F5 LTM을 통과하고 소스 IP 선호도를 사용하여 보조 프로토콜 세션의 올바른 라우팅을 보장합니다. 이는 하나의 공용 IP 주소 만 필요하다는 장점이 있습니다. 로드 밸런서에 이 기능이 없거나 소스 IP 선호도를 사용할 수없는 경우 다른 옵션은 보조 프로토콜 세션이로드 밸런서를 우회 할 수 있도록 각 Unified Access Gateway 장치에 대한 추가 IP 주소를 지정하는 것입니다. 이는로드 밸런싱 된 VIP가 기본 프로토콜에 사용되고 보조 프로토콜이 각 Unified Access Gateway 장치 전용 N VIP 중 하나로 직접 라우팅되는 N + 1 VIP 방법이라고도합니다. 보다VMware Unified Access Gateway 장치 간의로드 밸런싱 .

Network Port

성공적인 외부 연결과 구성 요소 간의 올바른 통신을 보장하려면 Horizon 7 배포에서 연결을위한 네트워크 포트 요구 사항을 이해하는 것이 중요합니다. 아래 다이어그램은 가능한 각 디스플레이 프로토콜과 대상 네트워크 포트를 사용하는 외부 연결을 보여줍니다.

참고 :

• 화살표는 트래픽 시작 방향 (소스에서 목적지로)을 나타냅니다.
• Horizon UDP 프로토콜은 양방향이므로 UDP 응답 데이터 그램을 허용하도록 상태 저장 방화벽을 구성해야합니다.

다음 다이어그램은 Unified Access Gateway를 통한 외부 Blast Extreme 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 Unified Access Gateway를 통한 외부 PCoIP 연결을 허용하는 데 필요한 포트를 보여줍니다.

다음 다이어그램은 Unified Access Gateway를 통한 외부 RDP 연결을 허용하는 데 필요한 포트를 보여줍니다.

VMware Horizon 7 의 네트워크 포트 가이드 에는 트래픽을 보여주는 다이어그램과 함께 자세한 내용이 있습니다. 내부, 외부 및 터널링 된 연결에 대한 특정 섹션과 다이어그램도 있습니다. 외부 연결에 필요한 네트워크 포트에 대한 자세한 내용 은 VMware Horizon 7 : 외부 연결 및 외부 연결 다이어그램의 네트워크 포트를 참조하십시오 .

아키텍처

Unified Access Gateway를 사용하여 Horizon에 대한 외부 액세스를 제공하는 경우 외부 및 내부 연결 모두에 동일한 연결 서버를 사용할 수 있습니다.

위의 다이어그램은 Unified Access Gateway 장치와 연결 서버 간의로드 밸런서를 보여 주지만 로드 밸런서없이 1 : 1 연결로도 지원됩니다. 인터넷 연결 로드 밸런서가 모든 구성 요소에서 오류를 계속 감지하므로 고 가용성은 계속 유지됩니다.

연결 문제 해결

Horizon 연결 및 세션이 설정되는 방법을 이해 했으므로 이제 작동하지 않는 시점을 살펴볼 수 있습니다. 성공적인 연결 중에 무슨 일이 발생하는지 알면 작동하지 않을 때 이해하고 문제를 해결하는 데 도움이됩니다.

이 가이드는 가능한 모든 구성 요소와 통신 흐름을 보여 주므로 외부 연결 문제 해결에 중점을 둡니다. 문제 해결 단계는 내부 연결에도 적용 할 수 있습니다.

아래 다이어그램은 외부 연결을 나타내며 숫자는 통신 흐름을 나타냅니다.

1. Unified Access Gateway 앞의 로드 밸런서에 대한 Horizon Client 인증
2. 로드 밸런서에서 Unified Access Gateway 중 하나로의 인증 트래픽
3. (선택 사항) Unified Access Gateway에서 타사 인증 소스 (예 : RADIUS, RSA SecurID, SAML 2.0 ID 공급자) 로의 인증 트래픽
4. Unified Access Gateway에서 연결 서버 앞의 로드 밸런서로의 인증 트래픽
5. 로드 밸런서에서 Connection Server 중 하나로의 인증 트래픽
6. Horizon Client에서 인증에 사용 된 동일한 Unified Access Gateway 로의 프로토콜 세션입니다. 로드 밸런싱 구성에 따라 이 트래픽은 로드 밸런서를 통해 이동할 수 있습니다.
7. Unified Access Gateway에서 Windows Server의 가상 데스크톱에서 실행중인 Horizon Agent 로의 프로토콜 세션

참고 : 연결 통신 흐름의 일부는 아니지만 Horizon Agent가 연결 서버와 통신하여 상태를 표시한다는 점에 유의해야합니다.

Horizon 연결 문제를 해결하려면 먼저 실패한 단계 (인증 또는 프로토콜)를 확인하십시오. 사용자가 인증 할 수 있습니까? 로그인하고 Horizon 리소스를 선택하고 실행할 수 있습니까? Horizon 리소스가 사용자의 연결에 실패합니까? 사용자가 인증 할 수없는 경우 초기 조사를 위에 나열된 처음 4 단계로 제한 할 수 있습니다.

대부분의 문제는 Horizon 구성 요소 자체와 관련이 없습니다. 더 일반적으로, 잘못 구성된 방화벽 차단 포트, 잘못 구성된 로드 밸런서 연결 라우팅 또는 트래픽이 대상 (Connection Server, 에이전트 또는 인증 서버)으로 라우팅되는 것을 허용하지 않는 네트워크 라우팅 문제입니다.

초기 문제 해결 단계에는 다음이 포함되어야합니다.

• 방화벽을 통해 필요한 포트가 허용되는지 확인합니다. 이 가이드의 내부 연결 및 외부 연결 섹션에서 네트워크 포트 정보를 검토하십시오. 필요한 포트에 대한 자세한 내용은 VMware Horizon 7의 네트워크 포트를 참조하십시오 .
• 네트워크 라우팅이 위 다이어그램에 표시된 모든 구성 요소간에 트래픽이 흐르도록 구성 되었는지 확인 합니다.
• 로드 밸런서의 잘못된 구성 또는 잘못 정의 된 Blast 외부 URL과 같은 일반적인 문제를 확인합니다.

조사해야 할 Communication Flow 의 주요 영역은 다음과 같습니다.

1. Horizon Client에서 Unified Access Gateway로
2. (선택 사항) 타사 인증 소스에 대한 Unified Access Gateway
3. Connection Server에 대한 Unified Access Gateway
4. Horizon Agent에 대한 Unified Access Gateway
5. Horizon Agent와 Connection Server 간

Horizon Client에서 Unified Access Gateway로

기본 인증 단계에서 Horizon Client는 Unified Access Gateway 중 하나에 연결됩니다. 이를 위해서는 TCP 443이 Horizon Client에서 Unified Access Gateway로 라우팅 될 수 있어야합니다.

보조 프로토콜 단계의 경우 필요한 포트는 사용중인 디스플레이 프로토콜과 Unified Access Gateway에서 사용하도록 구성된 특정 포트 인 Blast에 따라 다릅니다. Horizon Client와 Unified Access Gateway간에 Blast 연결이 실패하면 Unified Access Gateway에 시간 초과 로그 항목이 표시됩니다 bsg.log.

이 문제를 해결하기 위해 조사해야 할 주요 영역은 다음과 같습니다.

외부 방화벽

Horizon Client와 Unified Access Gateway 사이의 방화벽이 Horizon Client의 Blast Extreme 프로토콜 포트에 필요한 포트를 차단하지 않는지 확인합니다.

이는 Unified Access Gateway에서 blastExternalUrl 설정이 구성된 방식에 따라 포트 TCP 8443 또는 TCP 443이됩니다 .

Blast는 선택적으로 Horizon Client에서 Unified Access Gateway로 UDP 8443을 사용할 수도 있지만 먼저 TCP를 통해 초기 연결을 시도해야합니다.

로드 밸런서 선호도

보조 Horizon 프로토콜 (Blast Extreme, PCoIP)은 기본 Horizon 인증이 라우팅 된 것과 동일한 Unified Access Gateway 장치로 라우팅되어야합니다. 이를 통해 Unified Access Gateway는 인증 된 사용자 세션을 기반으로 보조 프로토콜을 승인 할 수 있습니다.

보조 프로토콜 세션이 기본 프로토콜과 다른 Unified Access Gateway 장치로 잘못 라우팅되면 세션이 승인되지 않습니다. 따라서 연결이 DMZ에서 끊어지고 Blast 연결이 실패합니다.

Blast 연결의 경우 이는 Unified Access Gateway 의 bsg.log 에 표시됩니다. 여기서 Blast 세션은 기본값 인 60 초 내에 동일한 Unified Access Gateway에 도착하지 않습니다.

[absg-master] – Removing idle route 44271692-*** to target 192.168.2.151|22443, idled for 60.00 seconds, registered for 60.01 seconds

로드 밸런서가 올바르게 구성되지 않은 경우 보조 프로토콜 세션을 잘못 라우팅하는 것은 일반적인 문제입니다. 로드 밸런서 선호도는 세션의 전체 기간 (기본 최대 10 시간) 동안 이루어진 연결이 인증에 사용 된 동일한 Unified Access Gateway 장치로 계속 라우팅되도록해야합니다.

로드 밸런서에서 선호도 및 제한 시간이 올바르게 구성되었는지 확인하십시오.

VMware Unified Access Gateway 장치 간의로드 밸런싱을 참조하십시오 .

로드 밸런서 WebSocket

Blast Extreme은 WebSocket을 사용합니다 . 일부로드 밸런서는 WebSocket을 차단할 수 있고 일부는 기본적으로 WebSocket을 비활성화 할 수 있습니다. 이는 Citrix NetScaler와 Microsoft TMG 모두에서 나타났습니다.

Unified Access Gateway 앞의로드 밸런서 구성을 확인하여 WebSocket 사용이 활성화되었는지 확인하십시오.

Blast 외부 URL

는 blastExternalUrl통일 액세스 게이트웨이에 돌풍과 연결 호라이즌 클라이언트에 의해 사용되어야하는 URL과 포트를 지정하는 통합 액세스 게이트웨이의 구성입니다.

이 값은 클라이언트가 Unified Access Gateway 장치에 연결하는 데 사용할 수있는 값으로 설정하거나 Unified Access Gateway 앞에 하나가있는 경우로드 밸런서 이름으로 설정해야합니다. 그렇지 않은 경우 Unified Access Gateway는 Blast 연결을 수신하지 않습니다.

구성을 확인하고 blastExternalUrl필요한 경우 URL 및 포트를 변경하십시오. 유효한 포트는 8443 또는 443이어야합니다.

인증서

Unified Access Gateway 및로드 밸런서에서 TLS / SSL 오프로드 또는 재 암호화를 처리하는 경우 사용되는 TLS / SSL 인증서를 확인하십시오. 로드 밸런서 및 Unified Access Gateway 장치에서 동일한 인증서를 사용해야합니다.

Unified Access Gateway에 인증서 불일치 또는 잘못된 SSL 인증서가있는 경우 연결이 실패합니다. Blast 연결이 잘못된 Unified Access Gateway 장치로 잘못 라우팅되고 해당 장치에 올바른 장치에 대한 다른 인증서가있는 경우에도 연결 실패가 발생합니다.

연결 테스트

Windows 클라이언트에서 Unified Access Gateway에 대한 연결을 테스트 할 수 있습니다. 사용중인 게이트웨이 서비스 및 포트에 따라 아래에서 적절한 명령을 사용하십시오.

PowerShell 명령 셸 열기

Test-NetConnection uag-hostname-or-ip-address -port 443

Test-NetConnection uag-hostname-or-ip-address -port 8443

Test-NetConnection uag-hostname-or-ip-address -port 4172

curl 을 동등한 추적으로 사용할 수도 있습니다 .

curl --trace <outputfile> https://hostname.domain.com

이렇게하면 설명 정보를 포함하여 모든 들어오고 나가는 데이터의 전체 추적 덤프가 지정된 출력 파일로 전송됩니다.

파일로 지정하는 대신 표준 출력 (stdout)을 사용하여 출력을 콘솔로 보내려면 파일 이름으로 "-"를 사용하십시오.

curl --trace - https://uag-hostname.domain.com

또는 curl --trace-ascii를 사용하십시오 . 이것은 --trace와 매우 유사하지만 16 진 부분은 제외하고 덤프의 ASCII 부분 만 표시합니다. 최종 사용자가 더 쉽게 읽을 수 있도록 더 작은 출력을 만듭니다.

curl --trace-ascii <outputfile> https://hostname.domain.com

Unified Access Gateway에 tcpdump 설치

tcpdump는 Unified Access Gateway 안팎에서 패킷을 추적하는 데 유용한 도구입니다. 설치하려면 다음을 실행하십시오.

/etc/vmware/gss-support/install.sh

그런 다음 tcpdump 명령을 실행할 수 있습니다. 예 :

tcpdump -i any -n -v port 443

tcpdump -i any -n -v port 8443

tcpdump -i eth0 -n -v udp port 8443

tcpdump -i any -n -v port 4172

타사 ID 공급자에 대한 Unified Access Gateway

RADIUS 또는 RSA SecurID와 같은 타사 ID 공급자를 인증 소스로 사용하도록 Unified Access Gateway를 구성한 경우 인증 소스의 호스트 이름을 확인할 수 있고 트래픽을 올바르게 라우팅 할 수 있는지 확인합니다.

반지름

Unified Access Gateway에서 다음 명령을 실행하여 이름 확인 및 연결을 확인합니다. ICMP는 방화벽에 의해 차단 될 수 있으므로 ping이 항상 작동하는 것은 아니지만 이름 확인은 작동해야합니다.

nslookup radius-server-hostname

tracepath radius-server-hostname

tcpdump로 패킷 추적

tcpdump는 Unified Access Gateway 안팎에서 패킷을 추적하는 데 유용한 도구입니다. 설치하려면 다음을 실행하십시오.

/etc/vmware/gss-support/install.sh

그런 다음 다음 tcpdump 명령을 실행할 수 있습니다.

tcpdump -i any -n -v port 1812

RDS SecurID

일반적인 문제에는 필요한 포트를 차단하는 방화벽, 제자리에 있지 않은 올바른 네트워크 라우팅, 작동하지 않는 이름 확인 또는 재협상해야하는 노드 암호가 포함됩니다.

방화벽

Unified Access Gateway는 일반적으로 UDP 포트 5500을 사용하여 RSA 인증 관리자 서버와 통신하는 RSA SecurID 클라이언트를 사용합니다 (UDP가 반대 방향으로 응답 함). 이 UDP 및 / 또는 응답 포트를 차단하는 방화벽이있는 경우 SecurID 인증이 실패합니다.

RSA Authentication Manager 서버에 대한 로그에 Unified Access Gateway의 연결이 없음이 표시됩니다.

RSA 인증 관리자 호스트 이름 확인

내부 sdconf.recRSA 인증 관리자에서 추출한 파일, 하나 이상의 호스트 이름이있다. 이러한 호스트 이름은 Unified Access Gateway에서 확인할 수 있어야합니다.

sdconf.rec파일에 있는 호스트 이름을 사용하여 Unified Access Gateway에서 다음 명령을 실행하여 이름 확인 및 연결을 확인합니다. ICMP는 방화벽에 의해 차단 될 수 있으므로 ping이 항상 작동하지는 않지만 이름 확인은 작동해야합니다.

nslookup rsa-auth-manager-hostname

tracepath rsa-auth-manager-hostname

Unified Access Gateway에서 사용하는 DNS에 해당 호스트 이름이없는 경우 실패 할 수 있습니다.

호스트 이름이 확인되지 않은 경우 해결 방법은 Unified Access Gateway에서 사용하는 DNS에 호스트 이름을 추가하거나 호스트에 대한 호스트 파일 항목을 추가하는 것입니다 (PowerShell 방법을 사용하여 배포 중에 자동으로 수행 될 수 있음).

RSA Authentication Manager 서버에 대한 로그에 Unified Access Gateway의 연결이 없음이 표시됩니다.

노드 비밀 지우기

처음 배포 할 때 노드 비밀은 Unified Access Gateway와 RSA 인증 관리자 서버간에 협상 / 교환됩니다. RSA Authentication Manager 서버가 재배포되거나 Unified Access Gateway가 재배포 된 경우 재협상이 발생하도록 다른 쪽의 노드 암호를 지워야합니다. 이 문제를 보여주는 RSA 인증 관리자 서버에 좋은 로그가 있습니다.

tcpdump로 패킷 추적

tcpdump는 Unified Access Gateway 안팎에서 패킷을 추적하는 데 유용한 도구입니다. 설치하려면 다음을 실행하십시오.

/etc/vmware/gss-support/install.sh

그런 다음 tcpdump 명령을 실행할 수 있습니다.

tcpdump -i any -n -v port 5500

위에 설명 된 호스트 이름 확인의 IP 주소를 사용하는 RSA Authentication Manager 서버와의 통신 시도가 표시됩니다. 올바르게 구성되면 UDP 데이터 그램이 대상 포트 5500에서 전송되는 것으로 표시되고 해당 포트의 응답 데이터 그램도 표시됩니다.

아웃 바운드 UDP 데이터 그램이 표시되지만 응답 데이터 그램이없는 경우 포트를 차단하는 방화벽 일 수 있으며 데이터 그램이 RSA 인증 관리자에 도달하지 않거나 응답 데이터 그램이 Unified Access Gateway로 다시 라우팅되지 않을 수 있습니다. RSA Auth Manager 로그를 확인하십시오.

연결 서버에 대한 Unified Access Gateway

기본 인증 단계의 일부로 Unified Access Gateway는 포트 TCP 443을 사용하여 연결 서버 중 하나에 연결합니다.

• 네트워킹 -TCP 443이 Unified Access Gateway에서 연결 서버로 열려 있고 존재하는 모든 방화벽을 통해 허용되며 두 구성 요소 사이에 네트워크 라우팅이 있는지 확인합니다.
• 연결 서버 URL- Unified Access Gateway에 정의 된 연결 서버 URL이 올바른지, Unified Access Gateway가 DNS를 사용하여이 URL을 확인할 수 있는지 확인합니다.
• 인증서 – 연결 서버에 Unified Access Gateway에서 신뢰하는 TLS / SSL 인증서가 있는지 확인합니다. 또는 Unified Access Gateway가 연결 서버 URL 지문으로 구성되어 있는지 확인하십시오.

연결 테스트

Unified Access Gateway 장치 명령 줄에서 원격 콘솔 또는 SSH를 엽니 다. 루트로 로그온하고 다음 명령을 실행하십시오.

curl -v -k https://hostname-or-ip-address:443/

Unified Access Gateway가 연결 서버에 성공적으로 연결할 수있는 경우 다음 스크린 샷과 유사한 출력이 표시됩니다.

그림 15 : 연결 서버에 대한 Unified Access Gateway의 성공적인 컬 테스트

Unified Access Gateway 명령 줄에서 다음 명령을 실행하여 Unified Access Gateway가 연결 서버의 이름을 확인할 수 있는지 확인합니다.

nslookup hostname

그림 16 : Unified Access Gateway의 nslookup

Unified Access Gateway에서 연결 서버에 연결하는 데 문제가있는 경우 다음과 유사하게 Unified Access Gateway의 esmanager.log 에 기록됩니다 .

[nioEventLoopGroup-7-1]ERROR view.ViewEdgeService[onFailure: 165][]: Failed to resolve hostname address in proxyDestinationUrl: s1-cs3.eucmobility.com

[nioEventLoopGroup-4-1]WARN  client.HttpClient[operationComplete: 359][]: unable to connect to s1-cs3.eucmobility.com:443, reason=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443 retryCount:3

nioEventLoopGroup-4-1]ERROR client.HttpClient[lambda$send$1: 246][]: unable to connect to s1-cs3.eucmobility.com:443, reason=io.netty.channel.ConnectTimeoutException: connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443

[Monitoring]ERROR view.ViewEdgeService[healthCheckBroker: 407][]: Exception message: io.netty.channel.ConnectTimeoutException: connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443

[nioEventLoopGroup-4-1]WARN  client.HttpClient[operationComplete: 359][]: unable to connect to s1-cs3.eucmobility.com:443, reason=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: s1-cs3.eucmobility.com/192.168.2.33:443 retryCount:2

DNS 문제

Photon 3에서 실행되는 Unified Access Gateway 3.7 이상에서는 /etc/resolv.conf 파일에 DNS 서버 IP 주소가 포함되지 않습니다. 이것은 의도적으로 설계된 것입니다. /etc/resolv.conf 파일을 수동으로 편집하지 마십시오. DNS IP 주소는 배포시 PowerShell .ini 설정 파일을 통해 또는 Unified Access Gateway 관리 콘솔을 사용하여 추가해야합니다.

호스트 이름에 .local 을 사용하지 마십시오. 멀티 캐스트 DNS (mDNS) 용으로 예약되어 있으며 .local로 끝나는 이름에 대한 확인 요청은 일반 (유니 캐스트) DNS로 전송되지 않습니다. Photon 2를 기반으로하는 이전 버전의 Unified Access Gateway에서는 .local 이름을 확인할 수 있었지만이 문제는 Unified Access Gateway 3.7 이상에서 수정되었습니다.

환경의 호스트 이름이 .local 접미사 로 지정된 경우 예약 된 접미사 .local에서 벗어날 수있을 때까지 세 가지 해결 방법이 있습니다.

1. ntpServers, proxydestinationUrl 등과 같은 설정에서 호스트 이름 참조 대신 IP 주소를 사용하십시오.
2. Unified Access Gateway 호스트 파일 (PowerShell 또는 관리 UI를 통해)에 .local 호스트에 대한 호스트 항목을 추가합니다 . / etc / hosts 파일을 직접 편집하지 마십시오.
3. DNS에 별칭 CNAME 레코드를 추가하여 모든 .local 호스트에 대한 대체 이름을 제공합니다 .
   1. 예를 들어 myinternalserver.local DNS 항목의 경우 myinternalserver.int를 CNAME으로 사용한 다음 Unified Access Gateway의 호스트 이름 참조에 .int 이름을 사용합니다.

다음 명령을 사용하여 Unified Access Gateway에 구성된 DNS 서버 IP 주소를 확인하십시오.

systemd-resolve --status

Unified Access Gateway가 각 DNS 서버 IP 주소를 ping 할 수 있는지 확인합니다.

ping <DNS Server IP Address>

DNS를 사용하여 호스트 이름을 확인합니다.

nslookup <hostname>

Unified Access Gateway에서 tcpdump를 사용하여 DNS 프로토콜 활동 (요청 및 응답)을 볼 수도 있습니다.

/etc/vmware/gss-support/install.sh

tcpdump -i any -n -v udp port 53

백그라운드에서 실행하려면 끝에 "&"를 입력하십시오.

tcpdump -i any -n -v udp port 53&

Unified Access Gateway 3.7 이상에서 nslookup을 사용하는 tcpdump 출력을 사용하면 127.0.0.53 UDP 포트 53으로가는 DNS 쿼리가 표시됩니다. 이것은 로컬 DNS 리스너 systemd-resolv이며 DNS 쿼리를 다음과 같이 구성된 DNS 서버로 전달합니다. 와 함께 표시 systemd-resolve --status

Horizon Agent에 대한 Unified Access Gateway

프로토콜 세션이 보조 세션의 일부로 연결되면 Unified Access Gateway는 가상 데스크톱 또는 Windows Server에서 실행중인 Horizon Agent에 연결됩니다 (게시 된 애플리케이션에 대해 RDSH를 실행하는 경우).

Blast 연결의 경우 TCP 22443 (및 선택적으로 UDP 22443)을 사용합니다. 방화벽이있는 경우 Unified Access Gateway에서 에이전트로의이 트래픽을 허용하고 트래픽을 허용하고 전달하는 네트워크 라우팅이 있는지 확인합니다.

연결 서버 구성 오류

연결 서버가 BSG (Blast 보안 게이트웨이)에 대해 구성된 경우 Unified Access Gateway를 통한 Blast 연결이 실패합니다.

• Blast Extreme은 다중 홉 Blast 보안 게이트웨이를 지원하지 않습니다. 예를 들어, Unified Access Gateway와 연결 서버 모두에서 BSG를 실행합니다.
• 오류는 Unified Access Gateway 의 에 표시됩니다 bsg.log.

그림 17 : 연결 서버에 터널 및 프로토콜 게이트웨이가 비활성화되어 있는지 확인

마찬가지로 PCoIP가 Unified Access Gateway를 통해 사용되는 경우 PCoIP 보안 게이트웨이 서비스를 연결 서버에 구성하면 안됩니다. 이로 인해 프로토콜의 이중 홉이 발생하고 연결이 실패 할 수 있습니다.

연결 테스트

Blast over 22443 또는 PCoIP over 4172를 사용하여 Horizon Agent에 대한 연결을 테스트 할 수 없습니다. 데스크톱은 세션이 준비 될 때까지 이러한 포트 번호를 수신하지 않기 때문입니다. 로그에서 이러한 포트의 연결 실패를 볼 수 있습니다.

Horizon Framework 채널 TCP 연결을 사용하여 테스트

curl -v telnet://virtualdesktop-ip-address:32111

Horizon MMR / CDR TCP 연결을 사용하여 테스트

curl -v telnet://virtualdesktop-ip-address:9427

HTML 클라이언트 액세스 연결

HTML Access를 사용하면 설치된 기본 Horizon Client 대신 웹 브라우저가 Horizon 리소스에 액세스하기위한 클라이언트로 사용됩니다. 한 가지 고려 사항은 브라우저가 제공된 SSL 인증서를 신뢰해야한다는 것입니다.

외부 연결에서 Unified Access Gateway는 Blast 보안 게이트웨이를 실행하고 ID를 확인하기 위해 브라우저에 Unified Access Gateway 인증서를 제공합니다.

프로토콜 세션이 일반적으로 클라이언트에서 Horizon Agent로 직접 연결되는 내부 연결을 사용하는 경우 에이전트 측은 신뢰할 수있는 인증서를 브라우저에 제공해야합니다. 이것은 몇 가지 도전을 제시합니다.

1. 기본적으로 연결 서버는 데스크톱 컴퓨터 및 RDSH 서버의 호스트 이름이 아닌 IP 주소를 클라이언트에 전송하는 것을 우선적으로 제공하므로 인증서가 일치하지 않고 신뢰할 수 없게됩니다. (이 동작은 DNS 이름을 선호하도록 변경할 수 있습니다.)
2. 데스크톱 컴퓨터와 RDSH 서버에는 클라이언트 장치의 브라우저에서 신뢰할 수있는 인증서가 설치되어 있어야합니다. 이 동작으로 인해 전통적으로 와일드 카드 인증서가 사용되었습니다.

구성

Horizon 연결 서버의 기능은 이러한 제약을 극복하는 데 도움이됩니다. Horizon Administrator에서는 HTML Access가 로컬로 사용되는 경우에만 원격 데스크톱 및 애플리케이션에 대한 보안 액세스를 제공하도록 Blast 보안 게이트웨이 사용을 구성 할 수 있습니다.

Blast Extreme 프로토콜 트래픽 세션은 연결 서버를 통해 라우팅되며 SSL 인증서와 함께 제공됩니다. 이렇게하면 연결 서버가 시스템 또는 RDSH 서버 정보를 호스트로 보내는 기본 방식을 변경할 필요가 없습니다. 또한 데스크톱 컴퓨터 및 RDSH 서버에서 인증서를 관리 할 필요가 없음을 의미합니다.

그림 18 : 연결 서버 게이트웨이 설정

연결 서버에 구성된 HTML Access 용 Blast 보안 게이트웨이 사용 설정 만 사용 하면 다음과 같은 동작이 발생합니다.

1. 연결 서버에 직접 연결하는 내부 HTML Access 사용자는 Blast 연결이 연결 서버의 Blast 보안 게이트웨이를 통해 이동합니다.
2. 내부 기본 Horizon Client에는 Blast 연결이 데스크톱으로 직접 연결됩니다.
3. Unified Access Gateway를 통해 연결하는 외부 사용자 (HTML Access 또는 기본 클라이언트)는 Blast 연결이 Unified Access Gateway의 Blast 보안 게이트웨이를 통해 이동합니다. 그런 다음 연결은 Unified Access Gateway 장치에서 Horizon Agent로 이동하고 연결 서버의 Blast 보안 게이트웨이를 건드리지 않으며 프로토콜의 이중 홉이 발생하지 않습니다.

그림 19 : HTML Access를 사용한 내부 연결

또한 연결 서버는 대부분의 사용 사례에서 Unified Access Gateway에서 실행되는 게이트웨이 서비스 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널)와 함께 내부 및 외부 연결 모두에 대해 공유 될 수 있음을 의미합니다. 내부 HTML Access 연결 만 연결 서버의 Blast 보안 게이트웨이를 통과합니다.

HTML 액세스 실패

경우에 따라 기본 Horizon Client가 Blast Extreme에서 작동하지만 HTML Access Client 사용이 실패 할 수 있습니다 (일부 브라우저에서는 실패하고 다른 브라우저에서는 작동하지 않음). HTML Access 및 Horizon 7을 사용하는 경우로드 밸런서 또는 Unified Access Gateway와 같은 게이트웨이를 통해 연결 서버에 연결하는 경우 먼저 Horizon 7에서 보안 설정을 구성해야합니다.

이러한 실패의 일반적인 이유는 연결 서버의 원본 확인 실패입니다. 연결 서버에서 디버그 로그 파일을보고 "Origin"을 검색하여 원본 확인 실패를 찾습니다. 자세한 내용은 Horizon 7 보안 문서에서 "원본 확인"을 참조하십시오.

이를 해결하려면 로드 밸런서를 통한 HTML 액세스 허용을 참조하십시오 .

출처 : techzone.vmware.com/resource/understand-and-troubleshoot-horizon-connections#troubleshooting

vCLS (vSphere Clustering Service)는 vSphere 7 업데이트 1 릴리스에 도입 된 새로운 기능입니다 . 첫 번째 릴리스는 vSphere의 클러스터링 서비스를 위해 분리되고 분산 된 제어 플레인을 생성하기위한 기반을 제공합니다.

문제는 vSphere DRS (Distributed Resource Scheduler)와 같은 클러스터 서비스가 구성 및 운영을 위해 vCenter Server 가용성에 의존한다는 것입니다. vCenter Server의 가용성을 높일 수있는 방법이 있지만 vSphere HA (고 가용성) 및 VCHA ( vCenter Server High Availability )에 대해 생각해보십시오 . 종속성은 이상적이지 않습니다. 또한 대규모 온 프레미스 및 퍼블릭 클라우드에서 vCenter Server 확장 성을 고려할 때 클러스터링 서비스를 지원하는 더 나은 솔루션이 필요합니다. 이것이 vCLS가 도입 된 이유입니다. 첫 번째 릴리스에서는 DRS 기능의 하위 집합이 이미 새로운 vCLS 기능을 사용하고 있습니다.

기본 아키텍처

vCLS 컨트롤 플레인의 기본 아키텍처는 최대 3 개의 VM (가상 머신)으로 구성되며 클러스터의 개별 호스트에 배치되는 시스템 또는 에이전트 VM이라고도합니다. 이들은 클러스터 쿼럼을 형성하는 경량 에이전트 VM입니다. 호스트가 3 개 미만인 소규모 클러스터에서 에이전트 VM의 수는 ESXi 호스트의 수와 같습니다. 에이전트 VM은 vSphere Cluster Services에서 관리합니다. 사용자는 에이전트 VM의 수명주기 또는 상태를 유지할 것으로 예상되지 않으며 일반적인 워크로드 VM처럼 취급해서는 안됩니다.

클러스터 서비스 상태

클러스터 쿼럼 상태를 형성하는 에이전트 VM은 자체 수정됩니다. 즉, 에이전트 VM을 사용할 수없는 경우 vCLS가 VM을 자동으로 인스턴스화하거나 전원을 켭니다.

클러스터 서비스에 대한 세 가지 상태가 있습니다.

• 정상 – 클러스터에서 하나 이상의 에이전트 VM이 실행 중이면 vCLS 상태가 녹색입니다. 에이전트 VM 가용성을 유지하기 위해 3 개의 에이전트 VM이 배포 된 클러스터 쿼럼이 있습니다.
• Degraded – 에이전트 VM 중 하나 이상을 사용할 수 없지만 DRS가 에이전트 VM을 사용할 수 없어 논리를 건너 뛰지 않은 경우 일시적인 상태입니다. vCLS VM 중 하나가 다시 배포되거나 실행중인 VM에 영향을 준 후 전원이 켜질 때 클러스터는이 상태 일 수 있습니다.
• 비정상 – vCLS 제어 플레인을 사용할 수 없어 (최소 1 개의 에이전트 VM) DRS 논리의 다음 실행 (워크로드 배치 또는 균형 조정 작업)을 건너 뛸 때 vCLS 비정상 상태가 발생합니다.

에이전트 VM 리소스

vCLS 에이전트 VM은 경량이므로 리소스 소비가 최소로 유지됩니다. vCLS는 vCenter Server가 vSphere 7 업데이트 1로 업그레이드 될 때 기존 배포에서 클러스터 당 최대 3 개의 에이전트 VM을 자동으로 생성합니다. 그린 필드 시나리오에서는 ESXi 호스트가 새 클러스터에 추가 될 때 생성됩니다. 공유 스토리지를 사용할 수없는 경우 에이전트 VM은 로컬 스토리지에 배치됩니다. vSAN을 사용할 때와 같이 ESXi 호스트에 공유 스토리지가 구성되기 전에 클러스터가 형성되는 경우 vCLS 에이전트 VM을 나중에 공유 스토리지로 이동하는 것이 좋습니다.

에이전트 VM은 사용자 정의 된 Photon OS를 실행합니다. 에이전트 VM 당 리소스 사양은 다음 표에 나열되어 있습니다.

2GB 가상 디스크는 씬 프로비저닝됩니다. 또한 관련된 네트워킹이 없으므로 구성된 네트워크 어댑터가 없습니다. 에이전트 VM은 vSphere Client 의 호스트 및 클러스터 개요에 표시되지 않습니다 . 이제 VM 및 템플릿 보기에 모든 vCLS 에이전트 VM이 포함 된 새 폴더 vCLS가 포함됩니다. 클러스터가 여러 개인 경우 모든 vCLS 에이전트 VM이 연속적으로 번호가 지정되어 표시됩니다.

vSphere Client에는 vCLS 에이전트 VM에 대한 정보를 표시하는 메시지와 메모가 포함되어 있으며 이러한 VM의 전원 상태 및 리소스가 vCLS에서 처리된다는 내용도 포함되어 있습니다.

운영

앞에서 언급했듯이 에이전트 VM은 vCLS에서 유지 관리됩니다. VI 관리자가 VM의 전원을 끌 필요가 없습니다. 실제로 vSphere Client는 에이전트 VM의 전원이 꺼지면 경고를 표시합니다.

호스트가 유지 관리 모드로 전환되면 vCLS 에이전트 VM은 일반 VM과 같이 클러스터 내의 다른 호스트로 마이그레이션됩니다. 고객은 클러스터 서비스를 정상 상태로 유지하기 위해 에이전트 VM 또는 해당 폴더를 제거하거나 이름을 변경하지 않아야합니다.

vCLS 에이전트 VM의 수명주기는 vSphere EAM (ESX Agent Manager)에 의해 유지됩니다. Agent Manager는 VM을 자동으로 생성하거나 사용자가 VM의 전원을 끄거나 삭제하려고 할 때 VM을 다시 생성 / 전원을 켭니다. 

아래 예는 전원 끄기 및 삭제 작업을 볼 수 있습니다. EAM이 에이전트 VM을 자동으로 복구하는 두 가지 기능 모두

자동화 및 vCLS

스크립트를 사용하여 작업을 자동화하는 고객의 경우, 예를 들어 오래된 VM을 삭제하는 정리 스크립트와 같이 에이전트 VM을 무시하도록 인식을 구축하는 것이 중요합니다. vCLS 에이전트 VM 식별은 vCLS 폴더에 에이전트 VM이 나열되는 vSphere Client에서 빠르게 수행됩니다. 또한 관리> vCenter Server Extensions> vSphere ESX Agent Manager 아래의 VM 탭을 검사하면 해당 vCenter Server 인스턴스에서 관리하는 모든 클러스터의 에이전트 VM이 나열됩니다.

모든 에이전트 VM에는 추가 속성이 있으므로 특정 자동화 된 작업에서 무시할 수 있습니다. 이러한 속성은 MOB (Managed Object Browser)를 사용하여 찾을 수도 있습니다. 특정 속성은 다음과 같습니다.

• ManagedByInfo
  • extensionKey == “com.vmware.vim.eam”
  • type == “cluster-agent”

• ExtraConfig keys
  • “eam.agent.ovfPackageUrl”
  • “eam.agent.agencyMoId”
  • “eam.agent.agentMoId”

vCLS 에이전트 VM에는 "true"로 설정된 추가 데이터 속성 키 "HDCS.agent"가 있습니다. 이 속성은 EAM에서 명시 적으로 설정 한 다른 VM ExtraConfig 속성과 함께 ESXi 호스트에 자동으로 푸시 다운됩니다.

출처 : blogs.vmware.com/vsphere/2020/09/vsphere-7-update-1-vsphere-clustering-service-vcls.html

Horizon 연결 서버를 포함하여 VMware Horizon 7을 사용하지만 여기에 설명 된 대부분의 내용은 VMware Horizon Cloud에도 적용됩니다.

참고 :이 블로그는 얼마 전에 게시되었지만 여전히 Horizon 연결의 요지를 알 수있는 관련성이 높고 쉬운 방법입니다. 더 자세히 알아 보려면 이제 상세하고 포괄적 인 Horizon 연결 이해 및 문제 해결 가이드를 제공합니다.

1 차 및 2 차 프로토콜

먼저 Horizon Client가 Horizon 환경에 연결될 때 여러 다른 프로토콜이 사용되며 성공적인 연결은 두 단계로 구성된다는 점을 이해하는 것이 중요합니다.

연결의 첫 번째 단계는 항상 인증, 권한 부여 및 세션 관리를 제공하는 HTTPS를 통한 기본 XML-API 프로토콜입니다. 인증에 성공하면 하나 이상의 보조 프로토콜을 사용하여 리소스에 연결됩니다.

Horizon 7의 구성 요소 및 아키텍처를 탐색 하려면 VMware Workspace ONE 및 VMware Horizon 참조 아키텍처 에서 구성 요소 설계 : Horizon 7 아키텍처 섹션 을 참조하십시오.

내부 연결

내부 연결을 사용하면 초기 인증 단계에서 Horizon Client에서 연결 서버로 연결됩니다. 그런 다음 보조 프로토콜 세션은 일반적으로 Horizon Client에서 Horizon Agent로 직접 연결됩니다.

보조 프로토콜 연결은 연결 서버에서 게이트웨이 또는 터널 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 또는 HTTPS 보안 터널)이 활성화 된 경우에만 연결 서버를 통해 라우팅됩니다. 이 구성은 프로토콜 세션이 연결 서버를 통해 터널링되어 진행중인 세션의 일부가되므로 덜 일반적입니다.

대부분의 일반적인 배포에서 연결 서버에서 사용되는 유일한 게이트웨이 서비스는 VMware HTML Access (웹 기반 클라이언트) 트래픽을 처리하는 Blast 보안 게이트웨이입니다. 이는이 게시물 뒷부분의 내부 HTML 클라이언트 액세스 연결 섹션에서 별도의 주제로 다룹니다 .

연결 서버의 부하를 분산 할 때 일반적으로 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리) 만 부하 분산하면됩니다.

보조 프로토콜 연결은 Horizon Client에서 Horizon Agent로 직접 이동하기 때문에로드 밸런싱되지 않습니다.

외부 연결

연결이 외부인 경우 통신은 일반적으로 VMware UAG (Unified Access Gateway) 어플라이언스를 통해 이루어집니다. 연결의 초기 인증 단계는 Horizon Client에서 Unified Access Gateway 장치로 이동 한 다음 연결 서버로 이동하는 것입니다. 프로토콜 세션 연결은 Horizon Client에서 Unified Access Gateway로 이동 한 다음 Horizon Agent로 이동합니다.

Unified Access Gateway는 Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널과 같은 게이트웨이 서비스를 실행합니다. 이러한 게이트웨이 서비스가 연결 서버에서도 활성화되어 있지 않은지 확인하십시오.이 경우 지원되지 않는 프로토콜 트래픽의 이중 홉 시도가 발생하여 연결이 실패하게됩니다.

또한이 아키텍처에서는 외부 및 내부 연결 모두에 동일한 연결 서버를 사용할 수 있습니다.

Horizon 트래픽을 여러 UAG 장치로로드 밸런싱 할 때 초기 XML-API 연결 (인증, 권한 부여 및 세션 관리)을로드 밸런싱해야합니다. 보조 Horizon 프로토콜은 기본 Horizon XML-API 프로토콜이 라우팅 된 동일한 UAG 어플라이언스로 라우팅되어야합니다. 이를 통해 UAG는 인증 된 사용자 세션을 기반으로 보조 프로토콜을 승인 할 수 있습니다.

보조 프로토콜 세션이 기본 프로토콜과 다른 Unified Access Gateway 장치로 잘못 라우팅되면 세션이 승인되지 않습니다. 따라서 연결이 DMZ에서 삭제되고 프로토콜 연결이 실패합니다. 로드 밸런서가 올바르게 구성되지 않은 경우 보조 프로토콜 세션을 잘못 라우팅하는 것은 일반적인 문제입니다.

로드 밸런서 선호도는 세션의 전체 기간 (기본 최대 10 시간) 동안 만들어진 XML-API 연결이 동일한 UAG 어플라이언스로 계속 라우팅되도록해야합니다.

보조 프로토콜 세션은 기본 XML-API 연결에 사용 된 것과 동일한 UAG 어플라이언스로 라우팅되어야하지만 보조 프로토콜 세션이로드 밸런서를 통해 라우팅되는지 여부를 선택할 수 있습니다. 이는 일반적으로로드 밸런서의 기능에 따라 다릅니다.

예를 들어 F5 BIG-IP LTM (Local Traffic Manager)을 사용하면 기본 및 보조 프로토콜 트래픽이 F5 LTM으로 이동하며 소스 IP 선호도를 사용하여 보조 프로토콜 세션의 올바른 라우팅을 보장합니다. 이는 하나의 공용 IP 주소 만 있으면된다는 장점이 있습니다. 로드 밸런서에이 기능이없는 경우 다른 옵션은 보조 프로토콜 세션이로드 밸런서를 우회 할 수 있도록 각 UAG 어플라이언스에 대한 추가 IP 주소를 지정하는 것입니다. VMware Unified Access Gateway 장치 간의로드 밸런싱을 참조하십시오 .

내부 HTML 클라이언트 액세스 연결

HTML Access를 사용하면 설치된 기본 Horizon Client 대신 웹 브라우저가 Horizon 리소스에 액세스하기위한 클라이언트로 사용됩니다. 한 가지 고려 사항은 브라우저가 제공된 SSL 인증서를 신뢰해야한다는 것입니다. 외부 연결에서 Unified Access Gateway는 Blast 보안 게이트웨이를 실행하고 ID를 확인하기 위해 브라우저에 UAG 인증서를 제공합니다.

프로토콜 세션이 일반적으로 클라이언트에서 Horizon Agent로 직접 연결되는 내부 연결을 사용하는 경우 에이전트 측은 신뢰할 수있는 인증서를 브라우저에 제공해야합니다. 이것은 몇 가지 도전을 제시합니다.

1. 기본적으로 연결 서버는 데스크톱 컴퓨터 및 RDSH 서버의 호스트 이름이 아닌 IP 주소를 클라이언트에 전송하는 것을 우선적으로 제공하므로 인증서가 일치하지 않고 신뢰할 수 없게됩니다. (이 동작은 DNS 이름을 선호하도록 변경할 수 있습니다.)
2. 데스크톱 컴퓨터와 RDSH 서버에는 클라이언트 장치의 브라우저에서 신뢰할 수있는 인증서가 설치되어 있어야합니다. 이 동작으로 인해 전통적으로 와일드 카드 인증서가 사용되었습니다.

연결 서버의 비교적 새로운 기능은 이러한 제약을 극복하고보다 우아한 솔루션을 제공합니다. Horizon Administrator에서는 HTML Access가 로컬로 사용되는 경우에만 원격 데스크톱 및 애플리케이션에 대한 보안 액세스를 제공하도록 Blast 보안 게이트웨이 사용을 구성 할 수 있습니다.

Blast Extreme 프로토콜 트래픽 세션은 연결 서버를 통해 라우팅되며 SSL 인증서와 함께 제공됩니다. 이렇게하면 연결 서버가 시스템 또는 RDSH 서버 정보를 호스트로 보내는 기본 방식을 변경할 필요가 없습니다. 또한 데스크톱 컴퓨터 및 RDSH 서버에서 인증서를 관리 할 필요가 없음을 의미합니다.

연결 서버에 구성된 HTML Access 용 Blast 보안 게이트웨이 사용 설정 만 사용 하면 다음과 같은 동작이 발생합니다.

1. 연결 서버에 직접 연결하는 내부 HTML Access 사용자는 Blast 연결이 연결 서버의 Blast 보안 게이트웨이를 통과합니다.
2. 내부 기본 Horizon Client에는 Blast 연결이 데스크톱으로 직접 연결됩니다.
3. UAG를 통해 연결하는 외부 사용자 (HTML Access 또는 기본 클라이언트)는 Blast 연결이 UAG의 Blast 보안 게이트웨이를 통과하도록합니다. 그러면 연결이 UAG 어플라이언스에서 데스크톱으로 이동하고 연결 서버의 Blast 보안 게이트웨이를 건드리지 않습니다.

또한 연결 서버는 대부분의 사용 사례에서 UAG에서 실행되는 게이트웨이 서비스 (Blast 보안 게이트웨이, PCoIP 보안 게이트웨이 및 HTTPS 보안 터널)와 함께 내부 및 외부 연결 모두에 대해 공유 될 수 있음을 의미합니다. 내부 HTML Access 연결 만 연결 서버의 Blast 보안 게이트웨이를 통과합니다.

결론

이제 연결 방법과 트래픽 흐름을 이해 했으므로 사용되는 네트워크 포트를 살펴볼 수 있습니다. VMware Horizon 7 의 네트워크 포트 문서 에는 트래픽을 보여주는 다이어그램과 함께이 세부 정보가 있습니다. 내부, 외부 및 터널링 된 연결에 대한 특정 섹션과 다이어그램도 있습니다.

자세한 내용은 Horizon 연결 이해 및 문제 해결 가이드를 참조하십시오 .

출처:techzone.vmware.com/blog/understanding-horizon-connections