1세대 테넌트 - 1세대 Horizon Cloud 포드 배포 또는 최초 도메인 바인딩 문제가 발생할 경우의 문제 해결

사용자 환경의 네트워킹이 Microsoft Azure의 1세대 Horizon Cloud 포드에서 사용하도록 적절히 구성되지 않은 경우, 해당 포드를 구축하는 프로세스가 보류 중 상태가 되거나, Active Directory 환경에 대해 도메인 바인딩을 수행하기 위한 배포 후 작업이 실패할 수 있습니다. 가장 일반적인 두 가지 네트워크 관련 원인은 필요한 아웃바운드 포트를 열지 못하는 것과 DNS에서 내부 및 외부 주소를 둘 다 확인하도록 설정하지 못하는 것입니다. 여기에 제공되는 문제 해결 단계에 따라 몇 가지 테스트를 실행하여 필요한 아웃바운드 포트가 열려 있는지와 DNS가 내부 및 외부 주소를 둘 다 확인할 수 있는지를 알아볼 수 있습니다.

중요: 이 정보는 1세대 제어부의 1세대 테넌트 환경에 액세스할 수 있는 경우에만 적용됩니다. KB-92424에 설명된 대로 1세대 제어부는 EOA(사용 종료)에 도달했습니다. 자세한 내용은 해당 문서를 참조하십시오.

포드를 성공적으로 배포하기 위한 전체적인 네트워킹 요구 사항은 전제 조건 검사 목록에 나와 있으며 1세대 테넌트 - Microsoft Azure의 Horizon Cloud 포드에 사용하는 VNet 토폴로지에 필요한 DNS 서버 설정 구성 및 1세대 테넌트 - Horizon Cloud on Microsoft Azure 배포 - 호스트 이름 확인 요구 사항, DNS 이름에 설명되어 있습니다. 사용자 환경의 네트워킹이 해당 요구 사항을 충족하지 않을 경우 다음 두 가지 문제 중 하나 또는 둘 다가 발생합니다.

문제 일반적인 원인

문제	일반적인 원인
시작 페이지에 포드가 보류 중 상태로 표시되며, 연결 상태로 진행되지 않습니다. 일반적으로 포드가 약 10분 동안 보류 상태를 유지합니다(시간이 더 오래 걸리는 Microsoft Azure China 클라우드로 포드를 배포하는 경우 제외). 포드가 성공적으로 배포되었더라도 Active Directory를 등록하려고 하면 "`Unable to register Active Directory`" 오류와 함께 도메인 바인딩 단계가 실패합니다.	필요한 아웃바운드 포트가 열려 있지 않거나 방화벽 환경이 의해 차단되어 있습니다. 필요한 아웃바운드 포트가 열려 있지 않거나 방화벽에 의해 차단되어 있으면, 포드 소프트웨어가 Microsoft Azure 클라우드 환경에 안전하게 다운로드되지 못하고 Horizon Cloud 클라우드 제어부에 다시 연결하지 못합니다. 결과적으로, 보류 중 상태 문제가 발생합니다. VNet DNS 서버가 내부 및 외부 시스템 이름을 둘 다 확인할 수 있는 유효한 DNS 서버를 가리키도록 제대로 구성되지 않았습니다. VNet DNS 서버가 DNS 서버를 제대로 가리키더라도 해당 DNS 서버가 내부 및 외부 시스템 이름을 확인하지 못할 수 있습니다. 외부 시스템 이름에 대한 DNS 확인이 VNet에 제공되지 않을 경우 보류 중 상태 문제 및 도메인 바인딩 문제가 발생할 수 있습니다. 예를 들어 DNS가 도메인 컨트롤러에서 Active Directory로 확인될 수 없으면 도메인 바인딩 단계가 실패합니다. VNet DNS 구성에 대한 자세한 내용은 1세대 테넌트 - Microsoft Azure의 Horizon Cloud 포드에 사용하는 VNet 토폴로지에 필요한 DNS 서버 설정 구성을 참조하십시오.

시작 페이지에 포드가 보류 중 상태로 표시되며, 연결 상태로 진행되지 않습니다. 일반적으로 포드가 약 10분 동안 보류 상태를 유지합니다(시간이 더 오래 걸리는 Microsoft Azure China 클라우드로 포드를 배포하는 경우 제외).
포드가 성공적으로 배포되었더라도 Active Directory를 등록하려고 하면 "Unable to register Active Directory" 오류와 함께 도메인 바인딩 단계가 실패합니다.

필요한 아웃바운드 포트가 열려 있지 않거나 방화벽 환경이 의해 차단되어 있습니다. 필요한 아웃바운드 포트가 열려 있지 않거나 방화벽에 의해 차단되어 있으면, 포드 소프트웨어가 Microsoft Azure 클라우드 환경에 안전하게 다운로드되지 못하고 Horizon Cloud 클라우드 제어부에 다시 연결하지 못합니다. 결과적으로, 보류 중 상태 문제가 발생합니다.
VNet DNS 서버가 내부 및 외부 시스템 이름을 둘 다 확인할 수 있는 유효한 DNS 서버를 가리키도록 제대로 구성되지 않았습니다.
VNet DNS 서버가 DNS 서버를 제대로 가리키더라도 해당 DNS 서버가 내부 및 외부 시스템 이름을 확인하지 못할 수 있습니다.

외부 시스템 이름에 대한 DNS 확인이 VNet에 제공되지 않을 경우 보류 중 상태 문제 및 도메인 바인딩 문제가 발생할 수 있습니다. 예를 들어 DNS가 도메인 컨트롤러에서 Active Directory로 확인될 수 없으면 도메인 바인딩 단계가 실패합니다. VNet DNS 구성에 대한 자세한 내용은 1세대 테넌트 - Microsoft Azure의 Horizon Cloud 포드에 사용하는 VNet 토폴로지에 필요한 DNS 서버 설정 구성을 참조하십시오.

DNS 구성이 내부 및 외부 이름을 확인할 수 있는지를 확인하고 필요한 아웃바운드 포트가 열려 있는지 확인하는 테스트를 실행하려면 Microsoft Azure 구독에 작은 테스트 VM(가상 시스템)을 배포한 다음 해당 VM을 사용하여 이러한 네트워킹 테스트를 실행합니다. 문제 해결 단계의 개략적인 순서는 다음과 같습니다.

SSH 키 쌍을 생성합니다.
Microsoft Azure 구독에서 테스트 VM을 생성합니다.
해당 테스트 VM에 연결합니다.
네트워킹 테스트를 실행합니다.
테스트가 완료되면 이 문제 해결을 수행하기 위해 Microsoft Azure 환경에서 생성된 테스트 VM 및 모든 테스트 관련 아티팩트를 삭제합니다.

참고: 테스트 관련 아티팩트를 삭제하지 않고 나중에 콘솔의 삭제 작업을 사용하여 포드를 삭제하면 예기치 않은 결과가 발생할 수 있습니다. 포드를 삭제할 때 시스템에서 포드의 서브넷을 검사하여 포드 ID에 따라 서브넷에 연결된 모든 항목이 포드 자체에 속하는지 확인합니다. 시스템에서 추가 VM, VM 디스크, IP 또는 기타 아티팩트가 노드의 서브넷에 연결되어 있다고 확인하면 시스템에서 포드를 완전히 삭제할 수 없습니다.

문제 해결 테스트 실행에 대한 자세한 내용은 다음 섹션을 참조하십시오.

중요: 이러한 모든 수동 테스트가 성공하더라도 모든 트래픽이 온-프레미스 네트워크를 통과하도록 하고 인증된 트래픽만 통과하도록 허용하지만 포드 배포 마법사에서 프록시를 사용하기 위한 값을 제공하지 않은 경우 포드 배포가 보류 중 상태에서 중단될 수 있습니다. 이 설명이 상황과 일치하는 경우 [시작] 페이지에서 포드를 삭제하고 포드 배포 마법사를 다시 실행한 후 필수 프록시 정보를 지정해야 합니다.

Horizon Cloud 포드 배포 문제 해결 - SSH 키 쌍 생성

이 문제 해결의 일부로 테스트 Linux VM이 Microsoft Azure 구독에 배포됩니다. 테스트 Linux VM에서 인증을 받으려면 SSH 키 쌍이 필요합니다. 시스템에서 테스트 VM에 대한 SSH 연결에 사용할 키 쌍을 생성합니다. 해당 시스템에 키 쌍이 이미 있는 경우 이 단계는 선택 사항입니다.

이 SSH 키 쌍을 생성하기 위해 Microsoft Windows 또는 Linux 시스템을 사용할 수 있습니다. 두 가지 유형의 시스템에 대한 단계가 여기에 설명되어 있습니다. 본인의 상황에 가장 적절한 단계를 선택합니다.

Microsoft Windows 시스템에서 SSH 키 쌍 생성

Microsoft Windows 시스템을 사용하여 Microsoft Azure 구독에 배포할 테스트 Linux VM에 대해 SSH 연결을 수행할 경우 다음 단계를 사용합니다.

Microsoft Azure에서 테스트 VM을 생성할 때는 생성된 공용 키 파일의 컨텐츠를 사용합니다. 테스트 VM에 연결하는 데 사용할 기존의 키 쌍이 Microsoft Windows 시스템에 이미 있는 경우 이 단계를 건너뛰고 Microsoft Azure 구독에서 테스트 가상 시스템 생성에 설명된 대로 테스트 VM을 계속 생성할 수 있습니다.

다음 단계를 수행하여 SSH 키 쌍을 생성하고, 테스트 VM을 생성할 때 사용할 수 있도록 공용 키 파일의 컨텐츠를 복사하고, PuTTY Pageant 도구에 개인 키를 로드합니다. Pageant는 개인 키를 메모리에 저장할 수 있는 SSH 인증 에이전트입니다. 메모리에 개인 키를 저장하면, 개인 키가 자동으로 해당 Microsoft Windows 시스템의 모든 SSH 세션에 적용되므로 보다 쉽게 사용할 수 있습니다.

사전 요구 사항

Microsoft Windows 시스템에는 기본적으로 SSH 키 쌍 소프트웨어가 설치되어 있지 않습니다. SSH 키 쌍 생성 소프트웨어가 사용하려는 시스템에 설치되어 있는지 확인합니다. 어떤 SSH 키 쌍 생성 소프트웨어도 사용할 수 있습니다. 다음 단계에서는 Microsoft Windows에서 PuTTY 소프트웨어를 사용하여 SSH 키 쌍을 생성하는 방법을 설명합니다. www.putty.org에서 PuTTY 소프트웨어를 다운로드할 수 있습니다. 설치 후에는 PuTTY 도구 모음을 사용할 수 있습니다. 다음 스크린샷에서는 시작 메뉴의 PuTTY 도구 예를 보여 줍니다.

Microsoft Windows 10 시작 메뉴에 표시되는 PuTTY 도구 스크린샷

프로시저

Microsoft Windows 시스템에서 PuTTYgen(PuTTY 키 생성기)을 실행합니다.
PuTTY 키 생성기 창이 표시됩니다. 다음 스크린샷에서 강조 표시된 것처럼, 목표는 SSH-2 RSA 유형 및 2048비트의 공개-개인 키 쌍을 생성하는 것입니다.
SSH-2RSA를 선택했고 비트 수로 2048이 설정되어 있는지 확인한 후 생성을 클릭합니다. 창은 진행률 표시줄이 있는 키 창으로 변경됩니다.
화면 지침에 따라 진행률 표시줄 아래의 빈 영역으로 커서를 이동합니다. PuTTY 사용자 인터페이스에 표시되는 것처럼, 이 영역에서 커서를 이동하여 해당 프로세스에 필요한 임의성을 추가합니다.
키 암호를 입력하여 시스템에 개인 키를 저장하고 개인 키 저장을 클릭합니다.

참고: 키 암호를 사용하는 것은 선택 사항이지만 권장됩니다. 그러나 키 암호를 입력하지 않고 개인 키 저장을 클릭하면 키 암호 없이 개인 키를 저장할지 여부를 확인하는 팝업 창이 표시됩니다.

개인 키가 PPK 파일로 저장됩니다. 개인 키 저장을 클릭한 후 로컬 시스템의 디렉토리로 이동한 후 파일 이름을 입력하고, 파일을 저장할 수 있습니다.
공용 키 저장 버튼을 사용하여 테스트 VM을 생성할 때 복사할 수 있는 위치에 공용 키를 저장합니다.
PuTTY SSH 인증 에이전트인 Pageant를 실행합니다.
Windows 10 시스템에서는 Pageant 아이콘이 시스템 트레이에 로드됩니다.
해당 시스템 트레이 아이콘을 마우스 오른쪽 단추로 클릭하고 키 추가를 클릭한 후 파일 선택 창을 사용하여 저장된 개인 키(PPK) 파일로 이동한 후 해당 파일을 선택하여 Pageant에 개인 키를 추가합니다.

참고: 이전에 개인 키 파일을 저장할 때 키 암호를 지정한 경우 해당 암호를 입력할 수 있는 상자가 표시됩니다.

결과

이때, 개인 키가 Pageant에 로드됩니다. 작업 메뉴의 키 보기 선택 옵션을 사용하여 로드된 키 목록의 키를 볼 수 있습니다. PuTTY를 사용하여 SSH 세션을 시작할 때 PuTTY는 Pageant에서 키를 자동으로 검색하므로, 암호를 입력하지 않고도 해당 키를 사용하여 인증을 받을 수 있습니다. 나중에 SSH 세션 실행을 마친 후에 Pageant를 종료하려는 경우 Pageant 시스템 트레이 아이콘의 오른쪽 클릭 메뉴에서 종료 선택 옵션을 사용합니다.

다음에 수행할 작업

Microsoft Azure 구독에서 테스트 가상 시스템 생성의 단계에 따라 테스트 VM을 생성합니다.

Linux 시스템에서 SSH 키 쌍 생성

Linux 시스템을 사용하여 Microsoft Azure 구독에 배포할 테스트 Linux VM에 대해 SSH 연결을 수행할 경우 다음 단계를 사용합니다.

Microsoft Azure에서 테스트 VM을 생성하는 단계에서 생성된 공용 키 파일의 컨텐츠를 사용합니다. 테스트 VM에 연결하는 데 사용할 기존의 SSH 키 쌍이 Linux 시스템에 이미 있는 경우 이 단계를 건너뛰고 Microsoft Azure 구독에서 테스트 가상 시스템 생성에 설명된 대로 테스트 VM을 계속 생성할 수 있습니다.

사전 요구 사항

다음 단계를 수행하기 전에 다른 용도로 유지하려는 기존 SSH 키 쌍을 덮어쓰지 않는지 확인합니다. Linux 시스템에서는 기본적으로 SSH 공용 및 개인 키 파일이 Linux ~/.ssh/id_rsa 디렉토리에 생성됩니다. SSH 키 쌍이 해당 디렉토리에 있으며 이 명령을 실행할 때 동일한 파일 이름을 사용하는 경우 또는 명령에 다른 위치를 지정하고 SSH 키 쌍이 해당 위치에 이미 있는 경우에는 기존 키 쌍을 덮어쓰게 됩니다.

프로시저

Linux 시스템에서 bash 셸을 엽니다.
bash 셸에서 다음 명령을 입력합니다.
```
ssh-keygen -t rsa -b 2048
```
키를 저장할 파일을 입력하고, 암호를 입력하고, 암호를 확인하기 위한 화면 지시를 따릅니다.
다음은 화면 지침의 예입니다. 여기서는 키를 저장할 파일로 mykey를 입력했습니다.
```
-bash-4.1$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
참고: 키 암호를 사용하는 것은 선택 사항이지만 권장됩니다.
개인 키는 사용자가 지정한 파일에 저장되고, 공용 키는 동일한 이름 및 .pub 확장명을 갖는 파일에 저장됩니다. 파일로 mykey를 입력하는 위 예제를 사용할 경우 샘플 출력은 다음과 같습니다.
```
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
```

다음에 수행할 작업

Microsoft Azure 구독에서 테스트 가상 시스템 생성의 단계에 따라 테스트 VM을 생성합니다.

Microsoft Azure 구독에서 테스트 가상 시스템 생성

Microsoft Azure 환경에서 테스트 Linux VM(가상 시스템)을 사용하여 Horizon Cloud 포드에 대해 구성된 네트워크 연결을 확인하는 테스트를 실행합니다.

사전 요구 사항

Horizon Cloud 포드 배포 문제 해결 - SSH 키 쌍 생성에 설명된 대로 생성한 SSH 공용 키가 있는지 확인합니다. VM에서 해당 개인 키를 가진 시스템에서 시작된 SSH 연결을 신뢰할 수 있도록 VM 생성 마법사에서 해당 공용 키를 제공합니다.

1세대 Horizon Cloud - Microsoft Azure에서 필수 가상 네트워크 구성에 설명된 대로 포드를 배포할 때 사용하는 것과 동일한 VNet(가상 네트워크)의 이름을 알고 있는지 확인합니다.

[포드 추가] 마법사의 옵션을 사용하여 포드에 대해 고유한 명명된 서브넷을 사용하지 않고 대신 서브넷에 대한 CIDR을 입력한 경우 포드 배포자가 포드의 관리 서브넷을 생성합니다. 배포 프로세스가 실패한 시점에서 이 프로세스는 VNet에서 포드의 관리 서브넷을 이미 생성했을 수 있습니다.

배포자가 해당 관리 서브넷을 이미 생성한 경우 해당 서브넷에 테스트 VM을 배포하는 것이 좋습니다. 포드의 관리 서브넷이 VNet에 있는지 확인하려면 Microsoft Azure Portal에 로그인하고, 해당 VNet으로 이동한 후, 포함된 서브넷 목록을 검토합니다. 포드 배포자가 포드의 서브넷을 자동으로 생성하도록 하는 경우(포드에 대해 고유한 명명된 서브넷을 사용하는 옵션을 사용하지 않음) 포드의 관리 서브넷에는 vmw-hcs-podID-net-management 패턴의 이름이 있습니다. 여기서 podID는 포드의 UUID입니다. 그렇지 않으면 포드의 관리 서브넷은 포드 배포를 위해 생성한 서브넷입니다.
실패한 배포 프로세스 중에 VNet에 포드의 관리 서브넷이 생성되지 않은 경우 VNet에서 사용 가능한 서브넷을 선택하거나 테스트 VM에서 사용할 새 서브넷을 생성할 수 있습니다.

프로시저

Microsoft Azure Portal에 로그인합니다.
포털에서 Azure Martketplace에서 Ubuntu Server LTS 모델 유형을 기준으로 계산 VM을 생성합니다.
이 문서를 작성할 때는 Ubuntu Server 20.04 LTS를 Azure Marketplace에서 선택할 수 있었습니다.

이 테스트 Linux VM을 생성할 때 마법사 UI에 따라 필요한 옵션을 구성합니다. 아래와 같이 다음 항목을 구성해야 합니다.


옵션	설명
구독	포드에 대한 [포드 추가] 마법사에서 선택한 것과 일치합니다.
리소스 그룹	선택 옵션은 테스트 VM에 대한 새 리소스 그룹을 생성하는 것이 좋습니다. 화면 프롬프트에 따라 새 리소스 그룹을 생성합니다. 이 테스트 VM에 기존 리소스 그룹을 사용할 수 있지만, 테스트 VM과 관련된 리소스 그룹이 권장됩니다. 테스트 실행이 끝나면 전체 리소스 그룹을 삭제하여 해당 VM과 관련 아티팩트를 보다 쉽게 삭제할 수 있기 때문입니다.
지역	포드에 대한 [포드 추가] 마법사에서 선택한 것과 일치합니다.
크기	이 VM은 확인 테스트를 완료하는 데만 사용되는 일시적인 VM이면 되므로 어떤 크기도 선택 가능합니다. 그러나 더 작은 크기를 사용하면 일반적으로 Microsoft Azure의 관련 비용이 절감되므로 테스트 VM으로 작은 크기를 선택하는 것이 일반적입니다(예: 2 vCPU 모델).
사용자 이름	이 이름은 나중에 필요하므로 적어둡니다.
인증 유형	SSH 공용 키를 선택합니다.
SSH 공용 키 소스	기존 공용 키 사용을 선택합니다. SSH 공용 키 필드가 해당 선택 항목과 함께 표시되며 SSH 공용 키에 붙여넣을 수 있습니다.
SSH 공용 키	이 필드에 SSH 키 쌍을 만들 때 생성한 SSH 공용 키를 붙여 넣습니다. 붙여넣은 컨텐츠는 공용 키의 `---- BEGIN SSH2 PUBLIC KEY ----` 줄로 시작하고 `---- END SSH2 PUBLIC KEY ----` 줄로 끝납니다.
공용 인바운드 포트	이 테스트 VM으로 테스트를 수행할 수 있도록 선택한 SSH(22) 포트를 허용합니다.
가상 네트워크	실패한 포드 배포에 사용된 것과 동일한 VNet을 선택합니다.
서브넷	포드를 이미 배포하려고 했으나 해당 프로세스가 실패한 경우, 가상 네트워크에서 포드의 관리 서브넷이 생성되었을 수 있습니다. 서브넷이 생성된 경우 이 테스트 VM에 대해 해당 서브넷을 선택하는 것이 좋습니다. 서브넷 선택 옵션을 클릭하여 선택한 가상 네트워크에 있는 서브넷으로 이동합니다. 도구 설명에 전체 이름을 표시하기 위해 서브넷으로 마우스를 가져가야 할 수 있습니다. 포드 배포 프로세스로 VNet에 포드의 관리 서브넷을 생성하지 못한 경우 테스트 VM에 사용하기 위해 식별한 VNet의 서브넷을 선택합니다(위 전제 조건의 설명 참조). 참고: 포드를 성공적으로 배포했으나 도메인 가입 문제를 해결하고 있는 경우, 도메인 가입 작업이 해당 데스크톱 서브넷에 연결된 데스크톱 이미지와 함께 사용되므로 관리 서브넷 대신, 테스트 VM에 대한 포드의 데스크톱 서브넷을 선택할 수 있습니다.
공용 IP	생성된 테스트 VM에 공용 IP 주소가 할당되도록 이 선택 옵션을 선택합니다. 공용 IP 주소가 있으면 WAN(Wide Area Network)을 통해 연결할 수 있습니다. 참고: 공용 IP를 사용하는 것이 네트워킹 구성에서 기술적으로 가능하지 않을 수도 있습니다. 공용 IP를 사용하여 테스트 VM을 생성할 수 없는 경우, 로컬 시스템으로부터 서브넷 필드에서 선택한 서브넷에 대한 네트워크 연결이 있거나 네트워크의 다른 시스템에 연결한 후 테스트 VM에 대해 인바운드 연결을 수행해야 합니다.

마법사의 최종 단계에서 핵심 정보(구독, 지역 위치, 가상 네트워크 및 서브넷)가 포드에 사용하려는 항목과 일치하는지 확인한 후 제출하여 VM을 생성합니다.

SSH를 사용하여 테스트 VM에 연결

Microsoft Azure 환경에서 네트워크 연결 테스트를 실행할 수 있도록 테스트 VM에 대해 SSH(Secure Shell) 연결을 수행합니다.

Microsoft Windows 시스템에서 테스트 VM에 대해 SSH 연결 수행

테스트 VM을 만들 때 지정한 공용 키에 해당하는 개인 키가 있는 Microsoft Windows 시스템에서 이 연결을 만듭니다.

사전 요구 사항

테스트 VM의 IP 주소와 VM을 만들 때 지정한 사용자 이름이 있는지 확인합니다.

Microsoft Windows 시스템에는 일반적으로 PuTTY가 사용됩니다. SSH 세션을 시작할 때 PuTTY에서 개인 키를 쉽게 로드하도록 하려면 PuTTY를 시작하기 전에 Microsoft Windows 시스템에서 SSH 키 쌍 생성에 설명된 대로 Pageant를 시작하고 Pageant 키 목록에 SSH 개인 키를 추가합니다. SSH 개인 키는 테스트 VM을 생성할 때 지정한 공용 키와 일치해야 합니다. 개인 키가 Pageant에 로드되면 PuTTY SSH 세션은 해당 개인 키를 자동으로 사용합니다.

프로시저

PuTTY를 시작합니다().
PuTTY 구성 창이 열립니다.
PuTTY 구성 창에서 호스트 이름을 지정하고 SSH를 선택한 후 열기를 클릭합니다.
PuTTY 구성 창의 호스트 이름 필드에 다음 패턴의 문자열을 입력합니다.
```
testvm_username@testvmip
```
문자열에서 testvm_username 및 testvmip에 테스트 VM의 사용자 이름과 IP 주소를 대신 입력합니다.
중요: 테스트 VM에 처음 연결하는 경우라면 열기를 클릭할 경우 서버의 호스트 키가 캐시되지 않았다는 PuTTY 보안 메시지가 표시되고, 서버의 rsa2 키 지문이 표시됩니다. 또는 예를 클릭하여 서버의 호스트 키를 PuTTY의 캐시에 추가하거나, 아니요를 클릭하여 PuTTY의 캐시에 키를 추가 하지 않고 연결할 수 있습니다. 테스트 VM에 대해 연결이 설정되지 않았다고 의심되면 취소를 클릭하여 연결을 중단한 후 PuTTY 구성 창으로 돌아가 호스트 이름 항목을 확인합니다.
다음 스크린샷은 이 샘플을 사용하는 창의 모습입니다.
```
[email protected]
```

결과

SSH 연결이 설정되면 명령줄 창이 표시됩니다.

다음에 수행할 작업

테스트 VM에 연결되었으므로 테스트를 실행하여 Microsoft Azure 환경 내의 네트워크 연결을 확인할 수 있습니다. Microsoft Azure 환경에서 테스트를 실행하여 네트워킹 확인에 설명된 단계를 따르십시오.

Linux 시스템에서 테스트 VM에 대해 SSH 연결

테스트 VM을 만들 때 지정한 공용 키에 해당하는 개인 키가 있는 Linux 시스템에서 이 연결을 만듭니다.

사전 요구 사항

테스트 VM의 IP 주소와 VM을 만들 때 지정한 사용자 이름이 있는지 확인합니다.

프로시저

bash 셸을 엽니다.
bash 셸 $ 프롬프트에서 아래와 같이 명령의 testvmip 및 testvm_username에 테스트 VM의 IP 주소 및 사용자 이름을 대신하는 ssh 명령을 입력합니다.
```
ssh Testvm_usernametestvmip@testvmip
```
예를 들어, Microsoft Azure 구독에서 테스트 가상 시스템 생성의 예에서 테스트 VM 세부 정보를 사용할 경우 샘플 명령은 다음과 같습니다.
```
ssh [email protected]
```

결과

SSH 연결이 설정되면 다음 스크린샷과 유사한 명령줄 창이 표시됩니다.

다음에 수행할 작업

Microsoft Azure 환경에서 테스트를 실행하여 네트워킹 확인

DNS가 내부 및 외부 주소 둘 다를 확인할 수 있는지와 필요한 아웃바운드 포트가 열려 있는지에 대한 테스트를 실행하여 2개의 네트워크 관련 영역이 제대로 구성되었는지 확인합니다. 이러한 테스트는 테스트 VM을 사용하여 실행합니다.

포드는 내부 및 외부 주소를 둘 다 확인하기 위해 DNS에 의존합니다. 여기에서 처음 두 테스트는 네트워크 환경에 구성된 DNS가 내부 및 외부 주소에 대한 알려진 FQDN을 확인할 수 있는지 여부를 검토합니다.

사전 요구 사항

이러한 테스트를 실행하기 전에 Microsoft Azure 구독에서 테스트 가상 시스템 생성 및 SSH를 사용하여 테스트 VM에 연결에 설명된 대로 Microsoft Azure 구독에서 테스트 VM을 생성하고, SSH 연결이 있는지 확인합니다.

VNet에서 연결할 수 있어야 하는 네트워크 내부의 서버에 대한 IP 주소 및 FQDN(정규화된 도메인 이름)을 가져옵니다(예: Active Directory 도메인 컨트롤러). DNS 확인 테스트에서 이 정보를 사용합니다.

프로시저

dlg 명령을 통해 Microsoft Azure에서 VNet의 내부인 알려진 도메인 이름을 쿼리하여 작업 환경에서 DNS가 내부 FQDN을 확인하는지 검토합니다.
SSH 연결 창에서 dig 명령을 실행하여 네트워크 외부에 있는 것으로 알려진 서버의 도메인 이름을 쿼리합니다(예: Active Directory 도메인 컨트롤러).
```
dig internal-domain-name
```
여기서 internal-domain-name은 네트워크 외부에 있는 것으로 알려진 서버의 정규화된 도메인 이름입니다.
dig(Domain Information Grouper)는 네트워크 문제 해결을 위한 명령줄 도구입니다. 내부 호스트 이름을 사용하여 이 명령을 실행할 경우 결과는 DNS 구성이 내부 주소를 올바르게 확인할 수 있음을 확인합니다. DNS 구성이 명령에 사용된 internal-domain-name을 확인할 수 있는 경우 명령 출력으로 해당 도메인 이름에 연결된 올바른 IP 주소가 반환됩니다.
예를 들어, VNet이 DNS 항목 skylo.local과 IP 주소 192.168.0.15의 Active Directory 도메인 컨트롤러가 있는 내부 Active Directory 서버로 구성되어 있다고 가정합니다. dig skylo.local을 실행하면 VNet의 DNS 구성이 해당 내부 skylo.local 서버 이름을 확인할 수 있는지 확인됩니다.
```
testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;skylo.local.                   IN      A

;; ANSWER SECTION:
skylo.local.            600     IN      A       192.168.0.15

;; Query time: 1 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 20:58:01 UTC 2018
;; MSG SIZE  rcvd: 56

testvmadmin@HCS-testingVM:~$
```
ANSWER SECTION이 제공된 호스트 이름이 해당 호스트 이름에 대해 예상되는 IP 주소로 확인되었음을 나타낼 경우 테스트는 성공적인 것입니다.
참고: 경우에 따라 DNS가 100%를 신뢰할 수 없으며 일부 요청은 실패하고 일부 요청은 제대로 확인됩니다. 처음에 이 명령을 실행했을 때 실패하면 이 명령을 10~12번 반복해서 실행하면서 매번 안정적인 응답이 제공되는지 여부를 확인합니다.
dlg 명령을 통해 알려진 외부 도메인 이름을 쿼리하여 DNS가 작업 환경에서 외부 FQDN을 확인하는지 검토합니다.
SSH 연결 창에서 dig 명령을 실행하여 외부 업계 표준 도메인 이름(예: vmware.com 또는 microsoft.com)을 쿼리합니다.
```
dig external-domain-name
```
여기서 external-domain-name은 VNet에 외부인 정규화된 도메인 이름입니다. 예를 들어, dig vmware.com을 실행하면 VNet의 DNS 구성이 해당 외부 이름을 확인할 수 있는지 여부가 확인됩니다.
```
testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vmware.com.                    IN      A

;; ANSWER SECTION:
vmware.com.             150     IN      A       107.154.105.19
vmware.com.             150     IN      A       107.154.106.19

;; Query time: 28 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 21:14:29 UTC 2018
;; MSG SIZE  rcvd: 71

testvmadmin@HCS-testingVM:~
```
위 예에서 ANSWER SECTION은 외부 도메인 이름 vmware.com이 두 개의 IP 주소로 올바로 확인되었음을 나타냅니다.
참고: azure.com 또는 microsoft.com과 같은 다양한 외부 도메인 이름을 사용하여 이 테스트를 반복하면서 DNS가 다른 외부 이름을 확인할 수 있는지 확인할 수 있습니다.
DNS 테스트가 작동하지 않는 경우 네트워크 구성 및 DNS 서버를 확인합니다. VNet에 DNS 서버를 추가했는지 확인합니다.
중요: 사용자 VNet에 DNS 서버를 추가해야 하거나 VNet의 DNS 서버 구성을 변경해야 할 경우, 변경 사항을 선택할 수 있게 해당 VNet에 연결된 모든 VM을 다시 시작해야 합니다. VNet의 DNS 서버 구성을 변경하고 해당 VNet에 연결된 일부 VM만 다시 시작하면 변경 사항이 VNet에 올바르게 전파되지 않습니다.
netcat 명령을 사용하여 필요한 아웃바운드 포트를 사용할 수 있는지 확인합니다.
Horizon Cloud에서는 포드 소프트웨어를 Microsoft Azure 환경에 안전하게 다운로드하고, 포드를 Horizon Cloud 제어부에 다시 연결할 수 있도록 하기 위해 일부 아웃바운드 포트를 열어 두어야 합니다. 1세대 테넌트 - Horizon Cloud on Microsoft Azure 배포 - 호스트 이름 확인 요구 사항, DNS 이름에 설명된 대로, 포드의 관리 서브넷에서 아웃바운드 TCP 포트 80, 443 및 11371을 열어 두어야 합니다. 아래 명령에 나와 있는 것처럼 netcat 명령을 실행하여, 필요에 따라 해당 아웃바운드 포트가 열려 있는지 확인할 수 있습니다.
SSH 연결 창에서 다음 명령을 실행합니다(포트당 1번씩).
참고: 포트 11371을 테스트하기 위한 아래 명령은 연결을 테스트할 packages.microsoft.com을 지정하지만, 다른 2개의 줄은 Horizon Cloud 제어부에 대한 아웃바운드 연결을 테스트합니다.
```
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
```
포트가 적절히 열려 있으면 netcat 명령은 해당 테스트에 대해 succeeded! 줄을 반환 합니다.
netcat 명령이 오류를 반환하는 경우 Microsoft Azure 네트워크 연결, 구독의 네트워크 보안 그룹 및 방화벽을 제대로 설정했는지 확인합니다. 1세대 테넌트 - Horizon Cloud on Microsoft Azure 배포 - 호스트 이름 확인 요구 사항, DNS 이름에 설명된 대로 네트워크 구성이 배포를 위해 포드에 필요한 DNS, 포트 및 프로토콜 요구 사항을 충족하는지 확인합니다.

결과

위의 테스트가 성공하는 경우 포드를 성공적으로 배포할 수 있게 됩니다.

참고: 포드에 사용할 선택적 기능을 구성하려는 경우(예: True SSO 또는 인증 서버와의 2단계 인증) 해당 용도로 추가 포트가 필요할 수 있습니다. 위의 아웃바운드 포트 테스트 기법을 사용하여 이러한 포트가 제대로 열렸는지 확인할 수 있습니다.

다음에 수행할 작업

테스트를 완료했으면 테스트 VM과 VM 디스크, IP 주소, NIC와 같은 모든 관련 아티팩트를 Microsoft Azure 환경에서 삭제해야 합니다. 테스트 VM에 대한 리소스 그룹을 생성하는 것이 좋습니다. 이 경우 단순히 해당 리소스 그룹을 삭제하여 모든 VM의 아티팩트를 삭제할 수 있습니다. 테스트를 완료한 후 테스트 VM 삭제의 단계를 따르십시오.

중요: Microsoft Azure 환경에서 테스트 VM의 아티팩트를 모두 삭제하지 않고 VM을 포드의 서브넷 중 하나에 연결한 경우 나중에 포드에서 삭제 작업을 사용하여 Horizon Cloud 환경에서 포드를 삭제하려고 하면 나머지 연결된 아티팩트로 인해 시스템에서 포드를 완전히 삭제하지 못할 수 있습니다. 기본적으로 삭제 작업을 사용하여 포드를 삭제하면 Horizon Cloud가 포드에 대해 생성한 리소스 그룹과 서브넷을 삭제합니다. Microsoft Azure는 여전히 사용 중인 서브넷이 삭제되지 않도록 합니다. 테스트 VM의 아티팩트가 포드의 서브넷에 연결되어 있으면 해당 서브넷을 삭제할 수 없으며 포드 삭제가 완료되지 않습니다. 이 상황을 방지하려면 포드를 성공적으로 배포한 후 테스트 VM의 아티팩트가 모두 삭제되었는지 확인하십시오.

테스트를 완료한 후 테스트 VM 삭제

Microsoft Azure 네트워크 구성을 확인하기 위한 테스트를 완료했으며 더 이상 테스트 VM이 필요하지 않으면 해당 테스트 VM 및 관련된 모든 아티팩트를 Microsoft Azure 환경에서 삭제해야 합니다.

프로시저

Microsoft Azure Portal에 로그인합니다.
다음 방법 중 하나를 사용하여 배포된 방식에 따라 테스트 VM을 삭제합니다.
- 테스트 VM을 자체 리소스 그룹에 배포했으며 해당 그룹을 다른 용도로는 사용하지 않을 경우 전체 리소스 그룹을 삭제할 수 있습니다.
  경고: 다른 항목을 실수로 삭제하지 않으려면 삭제하기 전에 리소스 그룹에 테스트 VM과 해당 관련 개체(예: 디스크 및 네트워크 어댑터)만 포함되어 있는지 확인하십시오.
- 전체 리소스 그룹을 삭제하지 않고 테스트 VM을 삭제해야 하는 경우, 포털의 검색 상자를 사용하여 테스트 VM의 이름을 검색합니다. 이 검색 결과로 VM 및 모든 관련 개체(디스크, 네트워크 인터페이스, 공용 IP 주소 등)가 나열됩니다. 그런 후 각 개체를 개별적으로 삭제합니다.