Azure Stack Hub 러기드 네트워크 소개

네트워크 디자인 개요

실제 네트워크 디자인

Azure Stack Hub 러기드 솔루션은 운영 및 서비스를 지원하기 위해 복원력 있고 고가용성 물리적 인프라가 필요합니다. ToR에서 Border 스위치로의 업링크는 SFP+ 또는 SFP28 미디어와 1GB, 10GB 또는 25GB 속도로 제한됩니다. 가용성은 OEM(원래 장비 제조업체) 하드웨어 공급업체에 문의하세요.

다음 다이어그램은 러기드화된 Azure Stack Hub에 권장되는 디자인을 제공합니다.

Azure Stack Hub ruggedized physical network

논리 네트워크 디자인

논리 네트워크 디자인은 실제 네트워크 인프라의 추상화입니다. 호스트, VM(가상 머신) 및 서비스에 대한 네트워크 할당을 구성하고 간소화하는 데 사용됩니다. 논리 네트워크 만들기의 일부로 네트워크 사이트는 다음을 정의하기 위해 만들어집니다.

  • VLAN(가상 로컬 영역 네트워크)
  • IP 서브넷
  • IP 서브넷/VLAN 쌍

모두 각 물리적 위치의 논리 네트워크와 연결됩니다.

다음 표에서는 계획해야 하는 논리 네트워크 및 연결된 IPv4 서브넷 범위를 보여 줍니다.

논리 네트워크 설명 크기
VIP(공용 가상 IP) Azure Stack Hub 러기드화는 이 네트워크의 총 31개의 주소를 사용합니다. 8개의 공용 IP 주소는 작은 Azure Stack Hub 러기드 서비스 집합에 사용되고 나머지는 테넌트 VM에서 사용됩니다. App Service 및 SQL 리소스 공급자를 사용하려는 경우 7개의 주소가 더 사용됩니다. 나머지 15개 IP는 향후 Azure 서비스를 위해 예약됩니다. /26(호스트 62개)-
/22(호스트 1022개)

권장 = /24(호스트 254개)
인프라 전환 라우팅을 위한 지점 및 지점 간의 IP 주소, 전용 스위치 관리 인터페이스 및 스위치에 할당된 루프백 주소입니다. /26
인프라 통신하기 위해 Azure Stack Hub 러기드 내부 구성 요소에 사용됩니다. /24
Private 스토리지 네트워크, 프라이빗 VIP, 인프라 컨테이너 및 기타 내부 기능에 사용됩니다. /20
베이스 보드 관리 컨트롤러(BMC) 물리적 호스트의 베이스보드 관리 컨트롤러와 통신하는 데 사용됩니다. /26

네트워크 인프라

러기드화된 Azure Stack Hub의 네트워크 인프라는 스위치에 구성된 여러 논리 네트워크로 구성됩니다. 다음 다이어그램에서는 이러한 논리 네트워크와 TOR(Top-of-Rack), 베이스보드 관리 컨트롤러 및 테두리(고객 네트워크) 스위치와 통합하는 방법을 보여 줍니다.

Azure Stack Hub 러기드 논리 네트워크 다이어그램:

Azure Stack Hub ruggedized logical network

BMC 네트워크

이 네트워크는 모든 기본 보드 관리 컨트롤러(BMC 또는 서비스 프로세서라고도 함)를 관리 네트워크에 연결하는 데만 사용됩니다. 예를 들면 iDRAC, iLO, iBMC 등이 있습니다. BMC 노드와 통신하는 데는 BMC 계정이 하나만 사용됩니다. 있는 경우 HLH(하드웨어 수명 주기 호스트)는 이 네트워크에 있으며 하드웨어 유지 관리 또는 모니터링을 위한 OEM 관련 소프트웨어를 제공할 수 있습니다.

또한 HLH는 DVM(배포 VM)을 호스트합니다. DVM은 Azure Stack Hub 러기드 배포 중에 사용되며 배포가 완료되면 제거됩니다. DVM은 여러 구성 요소를 테스트, 유효성 검사 및 액세스하기 위해 연결된 배포 시나리오에서 인터넷에 액세스해야 합니다. 이러한 구성 요소는 회사 네트워크 내부 및 외부에 있을 수 있습니다(예: NTP, DNS 및 Azure). 연결 요구 사항에 대한 자세한 내용은 Azure Stack Hub 러기드 방화벽 통합의 NAT 섹션을 참조하세요.

프라이빗 네트워크

/20(4096 호스트 IP) 네트워크는 Azure Stack Hub 러기드 지역에 비공개입니다. Azure Stack Hub 러기드 지역의 테두리 스위치 디바이스를 넘어 확장되지 않습니다. 이 네트워크는 여러 서브넷으로 나뉩니다. 예를 들면 다음과 같습니다.

  • Storage 네트워크: 공간 다이렉트 및 SMB(서버 메시지 블록) 스토리지 트래픽 및 VM 실시간 마이그레이션 사용을 지원하는 데 사용되는 /25(128 IP) 네트워크입니다.
  • 내부 가상 IP 네트워크: 소프트웨어 부하 분산 장치의 내부 전용 VIP 전용 /25 네트워크입니다.
  • 컨테이너 네트워크: 인프라 서비스를 실행하는 컨테이너 간의 내부 전용 트래픽 전용 /23(512 IP) 네트워크

프라이빗 네트워크의 크기는 개인 IP 공간의 /20(4096 IP)입니다. 이 네트워크는 Azure Stack Hub 러기드 시스템에 비공개입니다. Azure Stack Hub 러기드 시스템의 테두리 스위치 디바이스를 벗어나는 경로는 없으며, 여러 Azure Stack Hub 러기드 시스템에서 다시 사용할 수 있습니다. 네트워크는 러기드화된 Azure Stack Hub에 비공개이지만 데이터 센터의 다른 네트워크와 겹치지 않아야 합니다. 개인 IP 공간에 대한 지침은 RFC 1918을 따르는 것이 좋습니다.

/20 개인 IP 공간은 여러 네트워크로 나뉩니다. 그러면 Azure Stack Hub 러기드 시스템 인프라가 향후 릴리스의 컨테이너에서 실행될 수 있습니다. 자세한 내용은 1910 릴리스 정보를 참조하세요. 이 새로운 개인 IP 공간을 사용하면 배포하기 전에 필요한 라우팅 가능한 IP 공간을 줄이기 위해 지속적으로 노력할 수 있습니다.

Azure Stack Hub 러기드 인프라 네트워크

/24 네트워크는 내부 Azure Stack Hub 러기드 구성 요소 전용으로, 서로 통신하고 데이터를 교환합니다. 이 서브넷은 데이터 센터에 대한 Azure Stack Hub 러기드 솔루션 외부에서 라우팅할 수 있습니다. 이 서브넷에서 공용 또는 인터넷 라우팅 가능 IP 주소를 사용하지 않는 것이 좋습니다. 이 네트워크는 테두리에 보급되지만 대부분의 IP는 ACL(Access Control 목록)으로 보호됩니다. 액세스에 허용되는 IP는 /27 네트워크와 동일한 작은 범위 내에 있습니다. IP는 PEP(권한 있는 엔드포인트) 및 Azure Stack Hub 러기드 백업과 같은 서비스를 호스트합니다.

공용 VIP 네트워크

공용 VIP 네트워크는 러기드화된 Azure Stack Hub의 네트워크 컨트롤러에 할당됩니다. 스위치의 논리 네트워크가 아닙니다. SLB는 주소 풀을 사용하고 테넌트 워크로드에 /32 네트워크를 할당합니다. 스위치 라우팅 테이블에서 이러한 /32 IP는 BGP(Border Gateway Protocol)를 통해 사용 가능한 경로로 보급됩니다. 이 네트워크에는 외부에서 액세스할 수 있는 공용 주소가 포함되어 있습니다. Azure Stack Hub 러기드 인프라는 이 공용 VIP 네트워크에서 처음 31개의 주소를 예약하고 나머지는 테넌트 VM에서 사용합니다. 이 서브넷의 네트워크 크기는 최소 /26(호스트 64개)에서 최대 /22(호스트 1022개)에 이르기까지 다양할 수 있습니다. /24 네트워크를 계획하는 것이 좋습니다.

인프라 네트워크 전환

/26 네트워크는 라우팅 가능한 지점 간 IP /30(두 호스트 IP) 서브넷과 루프백을 포함하는 서브넷입니다. 이러한 서브넷은 대역 내 스위치 관리 및 BGP 라우터 ID를 위한 전용 /32 서브넷입니다. 이 IP 주소 범위는 데이터 센터에 대한 Azure Stack Hub 러기드 솔루션 외부에서 라우팅할 수 있어야 합니다. IP 주소는 프라이빗 또는 퍼블릭일 수 있습니다.

관리 네트워크 전환

/29(6개의 호스트 IP) 네트워크는 스위치의 관리 포트 연결 전용입니다. 이 네트워크는 배포, 관리 및 문제 해결을 위해 대역 외 액세스를 허용합니다. 위에서 언급한 스위치 인프라 네트워크에서 계산됩니다.

DNS 디자인 개요

러기드화된 Azure Stack Hub 외부에서 Azure Stack Hub 러기드 엔드포인트(포털, 관리, 관리, 관리)에 액세스하려면 Azure Stack Hub 러기드화된 DNS 서비스를 Azure Stack Hub에서 사용하려는 DNS 영역을 호스트하는 DNS 서버와 통합해야 합니다.

Azure Stack Hub 러기드 DNS 네임스페이스

Azure Stack Hub를 러기드화된 배포할 때 DNS와 관련된 몇 가지 중요한 정보를 제공해야 합니다.

필드 설명 예제
지역 Azure Stack Hub 러기드 배포의 지리적 위치입니다. 동부
외부 도메인 이름 Azure Stack Hub 러기드 배포에 사용할 영역의 이름입니다. cloud.fabrikam.com
내부 도메인 이름 Azure Stack Hub의 인프라 서비스에 사용되는 내부 영역의 이름입니다. 디렉터리 서비스 통합 및 프라이빗입니다(Azure Stack Hub 러기드 배포 외부에서 연결할 수 없음). azurestack.local
DNS 전달자 회사 인트라넷 또는 공용 인터넷에서 Azure Stack Hub 외부에서 호스팅되는 DNS 쿼리, DNS 영역 및 레코드를 전달하는 데 사용되는 DNS 서버입니다. 배포 후 Set-AzSDnsForwarder cmdlet을 사용하여 DNS 전달자 값을 편집할 수 있습니다.
명명 접두사(선택 사항) Azure Stack Hub 러기드 인프라 역할 인스턴스 컴퓨터 이름을 사용할 명명 접두사입니다. 제공되지 않으면 기본값은 "azs"입니다. azs

Azure Stack Hub 러기드 배포 및 엔드포인트의 FQDN(정규화된 도메인 이름)은 Region 매개 변수와 외부 도메인 이름 매개 변수의 조합입니다. 이전 표의 예제 값을 사용하여 이 Azure Stack Hub 러기드 배포에 대한 FQDN은 다음과 같습니다 east.cloud.fabrikam.com

따라서 이 배포에 대한 일부 엔드포인트의 예는 다음 URL과 같습니다.

  • https://portal.east.cloud.fabrikam.com
  • https://adminportal.east.cloud.fabrikam.com

Azure Stack Hub 러기드 배포에 이 예제 DNS 네임스페이스를 사용하려면 다음 조건이 필요합니다.

  • 영역 fabrikam.com 도메인 등록 기관, 내부 회사 DNS 서버 또는 둘 다에 등록됩니다. 등록은 이름 확인 요구 사항에 따라 달라집니다.
  • 자식 도메인 cloud.fabrikam.com이 영역 fabrikam.com 아래에 있습니다.
  • 영역 fabrikam.com 및 cloud.fabrikam.com 호스트하는 DNS 서버는 Azure Stack Hub 러기드 배포에서 연결할 수 있습니다.

Azure Stack Hub 러기드 엔드포인트 및 Azure Stack Hub 외부의 인스턴스에 대한 DNS 이름을 확인하려면 DNS 서버를 통합해야 합니다. 사용하려는 부모 영역을 호스트하는 DNS 서버와 함께 러기드화된 Azure Stack Hub의 외부 DNS 영역을 호스트하는 서버를 포함합니다.

DNS 이름 레이블

Azure Stack Hub 러기드형은 공용 IP 주소에 DNS 이름 레이블을 추가하여 공용 IP 주소에 대한 이름 확인을 허용하도록 지원합니다. DNS 레이블은 사용자가 이름으로 러기드화된 Azure Stack Hub에서 호스트되는 앱 및 서비스에 쉽게 연결할 수 있는 방법입니다. DNS 이름 레이블은 인프라 엔드포인트와는 약간 다른 네임스페이스를 사용합니다. 이전 예제 네임스페이스에 따라 DNS 이름 레이블의 네임스페이스는 *.east.cloudapp.cloud.fabrikam.com.

테넌트가 공용 IP 주소 리소스의 DNS 이름 필드에 Myapp을 지정하는 경우 Azure Stack Hub 러기드 외부 DNS 서버의 영역 east.cloudapp.cloud.fabrikam.commyapp에 대한 A 레코드를 만듭니다. 결과적으로 정규화된 도메인 이름은 myapp.east.cloudapp.cloud.fabrikam.com.

이 기능을 활용하고 이 네임스페이스를 사용하려면 DNS 서버를 통합해야 합니다. Azure Stack Hub에 대한 외부 DNS 영역을 호스트하는 서버와 사용하려는 부모 영역을 호스트하는 DNS 서버를 포함합니다. 이 네임스페이스는 Azure Stack Hub 러기드 서비스 엔드포인트에 사용되는 네임스페이스와 다르므로 추가 위임 또는 조건부 전달 규칙을 만들어야 합니다.

DNS 이름 레이블의 작동 방식에 대한 자세한 내용은 Azure Stack Hub의 러기드화된 "DNS 사용"을 참조하세요.

확인 및 위임

DNS 서버에는 다음 두 가지 유형이 있습니다.

  • 신뢰할 수 있는 DNS 서버는 DNS 영역을 호스트합니다. 해당 영역의 레코드에 대한 DNS 쿼리에만 대답합니다.
  • 재귀적 DNS 서버는 DNS 영역을 호스트하지 않습니다. 권한이 있는 DNS 서버를 호출하고 필요한 데이터를 수집하여 모든 DNS 쿼리에 응답합니다.

러기드화된 Azure Stack Hub에는 신뢰할 수 있는 DNS 서버와 재귀 DNS 서버가 모두 포함됩니다. 재귀 서버는 내부 프라이빗 영역을 제외한 모든 항목의 이름 및 Azure Stack Hub 러기드 배포에 대한 외부 공용 DNS 영역을 확인하는 데 사용됩니다.

Azure Stack Hub 러기드화된 외부 DNS 이름 확인

러기드화된 Azure Stack Hub 외부 엔드포인트의 DNS 이름(예: www.bing.com)을 확인하려면 Azure Stack Hub가 신뢰할 수 없는 DNS 요청을 전달하도록 러기드화된 Azure Stack Hub용 DNS 서버를 제공해야 합니다. Azure Stack Hub가 요청 전달을 러기드한 DNS 서버는 배포 워크시트(DNS 전달자 필드)에 필요합니다. 내결함성을 위해 이 필드에 두 개 이상의 서버를 제공합니다. 이러한 값이 없으면 Azure Stack Hub 러기드 배포가 실패합니다. 배포 후 Set-AzSDnsForwarder cmdlet을 사용하여 DNS 전달자 값을 편집할 수 있습니다.

방화벽 디자인 개요

방화벽 디바이스를 사용하여 Azure Stack Hub를 견고하게 보호하는 것이 좋습니다. 방화벽은 DDOS(분산형 서비스 거부) 공격, 침입 탐지, 콘텐츠 검사와 같은 작업을 방어하는 데 도움이 될 수 있습니다. 그러나 BLOB, 테이블 및 큐와 같은 Azure 스토리지 서비스에 대한 처리량 병목 현상을 유발할 수도 있습니다.

연결이 끊긴 배포 모드를 사용하는 경우 AD FS 엔드포인트를 게시해야 합니다. 자세한 내용은 데이터 센터 통합 ID 문서를 참조하세요.

Azure Resource Manager(관리자), 관리자 포털 및 Key Vault(관리자) 엔드포인트는 반드시 외부 게시가 필요한 것은 아닙니다. 예를 들어 서비스 공급자는 인터넷이 아닌 네트워크 내부에서 러기드화된 Azure Stack Hub만 관리하여 공격 노출 영역을 제한할 수 있습니다.

엔터프라이즈 조직의 경우 외부 네트워크는 기존 회사 네트워크일 수 있습니다. 이 시나리오에서는 회사 네트워크에서 러기드화된 Azure Stack Hub를 작동하도록 엔드포인트를 게시해야 합니다.

Network Address Translation

NAT(네트워크 주소 변환)는 배포 중에 DVM(가상 머신)이 외부 리소스에 액세스할 수 있도록 허용하는 권장 방법입니다. 또한 등록 및 문제 해결 중에 ERCS(응급 복구 콘솔) VM 또는 PEP(권한 있는 엔드포인트)의 경우

NAT는 외부 네트워크 또는 공용 VIP의 공용 IP 주소에 대한 대안이 될 수도 있습니다. 그러나 테넌트 사용자 환경을 제한하고 복잡성을 가중하므로 이렇게 하지 않는 것이 좋습니다. 한 가지 옵션은 풀의 사용자 IP마다 하나의 공용 IP가 필요한 일대일 NAT일 수 있습니다. 또 다른 옵션은 사용자가 사용할 수 있는 모든 포트에 대해 사용자 VIP마다 하나의 NAT 규칙이 필요한 다대일 NAT입니다.

공용 VIP에 NAT를 사용할 때의 몇 가지 단점은 다음과 같습니다.

  • 사용자가 SDN(소프트웨어 정의 네트워킹) 스택에서 자체 엔드포인트 및 게시 규칙을 제어하므로 방화벽 규칙을 관리할 때 오버헤드가 발생합니다. 사용자는 AZURE Stack Hub 러기드 운영자에게 문의하여 VIP를 게시하고 포트 목록을 업데이트해야 합니다.
  • NAT 사용은 사용자 환경을 제한하지만 운영자에게 게시 요청에 대한 모든 권한을 부여합니다.
  • Azure를 사용하는 하이브리드 클라우드 시나리오의 경우 Azure는 NAT를 사용하여 엔드포인트에 대한 VPN 터널을 설정하는 방식을 지원하지 않습니다.

SSL 가로채기

현재 모든 Azure Stack Hub 러기드 트래픽에서 SSL 가로채기(예: 암호 해독 오프로드)를 사용하지 않도록 설정하는 것이 좋습니다. 향후 업데이트에서 지원되는 경우 Azure Stack Hub에 SSL 인터셉션을 사용하도록 설정하는 방법에 대한 지침이 제공됩니다.

에지 배포 방화벽 시나리오

에지 배포에서 러기드화된 Azure Stack Hub는 에지 라우터 또는 방화벽 바로 뒤에 배포됩니다. 이러한 시나리오에서는 방화벽이 활성-활성 및 활성-수동 방화벽 구성을 모두 지원하는 경계(시나리오 1) 위에 있도록 지원됩니다. 또한 활성-활성 방화벽 구성만 지원하는 테두리 디바이스(시나리오 2)로 작동할 수도 있습니다. 시나리오 2는 장애 조치(failover)를 위해 BGP 또는 정적 라우팅을 사용하는 동등한 비용의 ECMP(다중 경로)를 사용합니다.

공용 라우팅 가능 IP 주소는 배포 시 외부 네트워크의 공용 VIP 풀에 대해 지정됩니다. 보안을 위해 에지 시나리오의 다른 네트워크에서는 공용 라우팅 가능 IP를 권장 하지 않습니다 . 이 시나리오를 통해 사용자는 Azure와 같은 공용 클라우드에서 완전한 자체 제어 클라우드 환경을 경험할 수 있습니다.

Azure Stack Hub ruggedized edge firewall scenario

엔터프라이즈 인트라넷 또는 경계 네트워크 방화벽 시나리오

엔터프라이즈 인트라넷 또는 경계 배포에서 러기드화된 Azure Stack Hub는 다중 영역 방화벽 또는 에지 방화벽과 내부 회사 네트워크 방화벽 사이에 배포됩니다. 그런 다음 아래에 설명된 대로 보안, 경계 네트워크(또는 DMZ) 및 비보안 영역 간에 트래픽이 분산됩니다.

  • 보안 영역: 내부 또는 회사 라우팅 가능한 IP 주소를 사용하는 내부 네트워크입니다. 보안 네트워크를 나눌 수 있습니다. 방화벽 NAT를 통해 인터넷 아웃바운드 액세스를 가질 수 있습니다. 일반적으로 내부 네트워크를 통해 데이터 센터 내부에서 액세스할 수 있습니다. 모든 Azure Stack Hub 러기드 네트워크는 외부 네트워크의 공용 VIP 풀을 제외하고 보안 영역에 있어야 합니다.
  • 경계 영역. 경계 네트워크는 웹 서버와 같은 외부 또는 인터넷 연결 앱이 일반적으로 배포되는 위치입니다. 일반적으로 인터넷에서 지정된 인바운드 트래픽을 허용하면서 DDoS 및 침입(해킹)과 같은 공격을 방지하기 위해 방화벽에 의해 모니터링됩니다. 러기드화된 Azure Stack Hub의 외부 네트워크 공용 VIP 풀만 DMZ 영역에 상주해야 합니다.
  • 비보안 영역. 외부 네트워크, 인터넷. 비보안 영역에서 러기드화된 Azure Stack Hub를 배포 하는 것은 권장되지 않습니다 .

Perimeter network firewall scenario

VPN 디자인 개요

VPN은 사용자 개념이지만 솔루션 소유자와 운영자가 알아야 할 몇 가지 중요한 고려 사항이 있습니다.

Azure 가상 네트워크와 온-프레미스 사이트 간에 네트워크 트래픽을 보내려면 먼저 가상 네트워크에 대한 VPN(가상 네트워크) 게이트웨이를 만들어야 합니다.

VPN Gateway는 공용 연결을 통해 암호화된 트래픽을 전송하는 가상 네트워크 게이트웨이의 유형입니다. VPN 게이트웨이를 사용하여 Azure Stack Hub의 가상 네트워크와 Azure의 가상 네트워크 간에 안전하게 트래픽을 보낼 수 있습니다. 가상 네트워크와 VPN 디바이스에 연결된 다른 네트워크 간에 안전하게 트래픽을 보낼 수도 있습니다.

가상 네트워크 게이트웨이를 만들 때 만들려는 게이트웨이 유형을 지정합니다. Azure Stack Hub의 러기드형은 가상 네트워크 게이트웨이의 한 가지 유형인 Vpn 유형을 지원합니다.

가상 네트워크마다 두 개의 가상 네트워크 게이트웨이를 포함할 수 있으며 각 유형은 하나씩만 포함할 수 있습니다. 선택한 설정에 따라 단일 VPN Gateway에 대한 여러 연결을 만들 수 있습니다. 이러한 종류의 설정의 예로 다중 사이트 연결 구성이 있습니다.

Azure Stack Hub에 대한 VPN Gateway를 만들고 구성하기 전에 Azure Stack Hub의 견고한 네트워킹에 대한 고려 사항을 검토합니다. Azure Stack Hub에 대한 구성이 Azure와 어떻게 다른지 알아봅니다.

Azure에서 선택한 VPN Gateway SKU에 대한 대역폭 처리량은 게이트웨이에 연결된 모든 연결에서 분할되어야 합니다. 그러나 Azure Stack Hub의 경우 게이트웨이에 연결된 각 연결 리소스에 VPN Gateway SKU에 대한 대역폭 값이 적용됩니다. 예를 들면 다음과 같습니다.

  • Azure에서 기본 VPN 게이트웨이 SKU는 약 100Mbps의 집계 처리량을 수용할 수 있습니다. 해당 VPN Gateway에 대한 두 개의 연결을 만들고 한 연결에서 50Mbps의 대역폭을 사용하는 경우 다른 연결에서 50Mbps를 사용할 수 있습니다.
  • 러기드화된 Azure Stack Hub에서 기본 VPN 게이트웨이 SKU에 대한 각 연결에는 100Mbps의 처리량이 할당됩니다.

VPN 유형

VPN Gateway 구성에 대한 가상 네트워크 게이트웨이 만들 때 VPN 유형을 지정해야 합니다. 선택하는 VPN 유형은 만들려는 연결 토폴로지에 따라 달라집니다. VPN 유형은 사용 중인 하드웨어에 따라 달라질 수도 있습니다. S2S 구성에는 VPN 디바이스가 필요합니다. 일부 VPN 디바이스는 특정 VPN 유형을 지원합니다.

중요

현재, 러기드화된 Azure Stack Hub는 경로 기반 VPN 유형만 지원합니다. 디바이스가 정책 기반 VPN만 지원하는 경우 Azure Stack Hub의 디바이스에 대한 연결은 견고하게 지원되지 않습니다. 또한 사용자 지정 IPSec/IKE 정책 구성이 지원되지 않으므로 현재는 Azure Stack Hub가 경로 기반 게이트웨이에 대해 정책 기반 트래픽 선택기를 사용하는 것을 지원하지 않습니다.

  • PolicyBased: 정책 기반 VPN은 IPsec 정책에 따라 IPsec 터널을 통해 패킷을 암호화하고 직접 전송합니다. 정책은 온-프레미스 네트워크와 Azure Stack Hub의 견고한 VNet 간의 주소 접두사 조합으로 구성됩니다. 정책 또는 트래픽 선택기는 일반적으로 VPN 디바이스 구성의 액세스 목록입니다. PolicyBased 는 Azure에서 지원되지만 Azure Stack Hub는 견고하지 않습니다.
  • RouteBased: 경로 기반 VPN은 IP 전달 또는 라우팅 테이블에 구성된 경로를 사용합니다. 경로는 패킷을 해당 터널 인터페이스로 전달합니다. 그런 다음 터널 인터페이스는 터널로 들어오는 터널에서 나가는 패킷을 암호화하거나 암호 해독합니다. RouteBased VPN에 대한 정책 또는 트래픽 선택기는 모든 항목(또는 와일드카드 사용)으로 구성됩니다. 기본적으로 변경할 수 없습니다. RouteBased VPN 형식의 값은 RouteBased입니다.

VPN 게이트웨이 구성

VPN 게이트웨이 연결은 특정 설정으로 구성된 여러 리소스를 사용합니다. 이러한 리소스의 대부분은 별도로 구성할 수 있지만 경우에 따라 특정 순서로 구성해야 합니다.

설정

각 리소스에 대해 선택하는 설정은 성공적인 연결을 만드는 데 중요합니다.

이 문서는 다음을 이해하는 데 도움이 됩니다.

  • 게이트웨이 유형, VPN 형식 및 연결 형식입니다.
  • 게이트웨이 서브넷, 로컬 네트워크 게이트웨이 및 고려할 수 있는 기타 리소스 설정입니다.

연결 토폴로지 다이어그램

VPN 게이트웨이 연결에 사용할 수 있는 다양한 구성이 있습니다. 요구 사항에 가장 적합한 구성을 결정합니다. 다음 섹션에서는 다음 VPN 게이트웨이 연결에 대한 정보 및 토폴로지 다이어그램을 볼 수 있습니다.

  • 사용 가능한 배포 모델
  • 사용 가능한 구성 도구
  • 사용할 수 있는 경우 문서로 직접 이동하는 링크

다음 섹션의 다이어그램 및 설명은 요구 사항에 맞게 연결 토폴로지 선택에 도움이 될 수 있습니다. 다이어그램은 기본 기준 토폴로지이지만 다이어그램을 가이드로 사용하여 더 복잡한 구성을 빌드할 수 있습니다.

사이트 및 다중 사이트(IPsec/IKE VPN 터널)

사이트 간

S2S( 사이트 대 사이트 ) VPN 게이트웨이 연결은 IPsec/IKE(IKEv2) VPN 터널을 통해 연결됩니다. 이 유형의 연결에는 온-프레미스에 있고 공용 IP 주소가 할당된 VPN 디바이스가 필요합니다. 이 디바이스는 NAT 뒤에 있을 수 없습니다. S2S 연결은 프레미스 간 및 하이브리드 구성에 사용될 수 있습니다.

다중 사이트

다중 사이트 연결은 사이트 대 사이트 연결의 변형입니다. 가상 네트워크 게이트웨이에서 일반적으로 여러 온-프레미스 사이트에 연결하는 둘 이상의 VPN 연결을 만듭니다. 여러 연결을 사용하는 경우 경로 기반 VPN 유형(클래식 VNet으로 작업할 때 동적 게이트웨이라고 함)을 사용해야 합니다. 각 가상 네트워크가 하나의 VPN Gateway만 사용할 수 있으므로 게이트웨이를 통한 모든 연결은 사용 가능한 대역폭을 공유합니다.

게이트웨이 SKU

Azure Stack Hub에 대한 가상 네트워크 게이트웨이를 견고하게 만들 때 사용할 게이트웨이 SKU를 지정합니다. 지원되는 VPN Gateway SKU는 다음과 같습니다.

  • Basic
  • Standard
  • 고성능

더 높은 게이트웨이 SKU를 선택하면 게이트웨이에 더 많은 CPU 및 네트워크 대역폭이 할당됩니다. 따라서 게이트웨이는 가상 네트워크에 대한 더 높은 네트워크 처리량을 지원할 수 있습니다.

러기드화된 Azure Stack Hub는 Express Route에서만 사용되는 울트라 성능 게이트웨이 SKU를 지원하지 않습니다.

SKU를 선택할 때 다음 사항을 고려합니다.

  • 러기드화된 Azure Stack Hub는 정책 기반 게이트웨이를 지원하지 않습니다.
  • BGP는 기본 SKU에서 지원되지 않습니다.
  • ExpressRoute-VPN 게이트웨이 공존 구성은 Azure Stack Hub의 견고한 구성에서 지원되지 않습니다.

게이트웨이 가용성

고가용성 시나리오는 고성능 게이트웨이 연결 SKU에서만 구성할 수 있습니다. 활성/활성 및 활성/수동 구성을 통해 가용성을 제공하는 Azure와 달리, Azure Stack Hub는 활성/수동 구성만 지원합니다.

장애 조치

Azure Stack Hub에는 러기드화된 세 개의 다중 테넌트 게이트웨이 인프라 VM이 있습니다. 이러한 VM 중 2개는 활성 모드이고 세 번째 VM은 중복 모드입니다. 활성 VM을 사용하면 VPN 연결을 만들 수 있으며, 중복 VM은 장애 조치(failover)가 발생하는 경우에만 VPN 연결을 허용합니다. 활성 게이트웨이 VM을 사용할 수 없게 되면 짧은 기간(몇 초) 동안 연결이 손실된 후 VPN 연결이 중복 VM으로 장애 조치됩니다.

SKU 기준으로 예상된 총 처리량

다음 표에서는 게이트웨이 유형 및 게이트웨이 SKU별 예상 집계 처리량을 보여 줍니다.

VPN Gateway 처리량(1) VPN Gateway 최대 IPsec 터널(2)
기본 SKU(3) 100Mbps 20
표준 SKU 100Mbps 20
고성능 SKU 200Mbps 10

표 노트

(1) - VPN 처리량은 인터넷을 통해 프레미스 간 연결에 대해 보장되는 처리량이 아닙니다. 가능한 최대 처리량 측정값입니다.
(2) - 최대 터널은 모든 구독에 대한 Azure Stack Hub 러기드 배포당 총계입니다.
(3) - BGP 라우팅은 기본 SKU에 대해 지원되지 않습니다.

중요

두 개의 Azure Stack Hub 러기드 배포 간에 하나의 사이트 간 VPN 연결만 만들 수 있습니다. 이는 동일한 IP 주소에 대한 단일 VPN 연결만 허용하는 플랫폼의 제한 때문입니다. Azure Stack Hub 러기드화는 Azure Stack Hub 러기드 시스템의 모든 VPN 게이트웨이에 단일 공용 IP를 사용하는 다중 테넌트 게이트웨이를 활용하므로 두 Azure Stack Hub 러기드 시스템 간에는 VPN 연결이 하나만 있을 수 있습니다.

이 제한은 단일 IP 주소를 사용하는 모든 VPN 게이트웨이에 둘 이상의 사이트-사이트 VPN 연결을 연결하는 데에도 적용됩니다. 러기드화된 Azure Stack Hub는 동일한 IP 주소를 사용하여 둘 이상의 로컬 네트워크 게이트웨이 리소스를 만들 수 없습니다.**

IPsec/IKE 매개 변수

러기드화된 Azure Stack Hub에서 VPN 연결을 설정하는 경우 양쪽 끝에서 연결을 구성해야 합니다. Azure Stack Hub 러기드 디바이스와 하드웨어 디바이스 간에 VPN 연결을 구성하는 경우 해당 디바이스에서 추가 설정을 요청할 수 있습니다. 예를 들어 VPN 게이트웨이 역할을 하는 스위치 또는 라우터입니다.

초기자 및 응답자로 여러 제품을 지원하는 Azure와 달리 Azure Stack Hub는 기본적으로 하나의 제품만 지원합니다. VPN 디바이스에서 작동하기 위해 다른 IPSec/IKE 설정을 사용해야 하는 경우 연결을 수동으로 구성하는 데 사용할 수 있는 더 많은 설정이 있습니다.

IKE 1단계(주 모드) 매개 변수

속성
IKE 버전 IKEv2
Diffie-Hellman 그룹 ECP384
인증 방법 미리 공유한 키
암호화 & 해싱 알고리즘 AES256, SHA384
SA 수명(시간) 28,800초

IKE 2단계(빠른 모드) 매개 변수

속성
IKE 버전 IKEv2
암호화 & 해싱 알고리즘(암호화) GCMAES256
암호화 & 해싱 알고리즘(인증) GCMAES256
SA 수명(시간) 27,000초
SA 수명(킬로바이트) 33,553,408
PFS(Perfect Forward Secrecy) ECP384
작동하지 않는 피어 검색 지원됨

사용자 지정 IPSec/IKE 연결 정책 구성

IPsec 및 IKE 프로토콜 표준은 다양한 조합으로 광범위한 암호화 알고리즘을 지원합니다. 규정 준수 또는 보안 요구 사항을 충족하기 위해 러기드화된 Azure Stack Hub에서 지원되는 매개 변수를 확인하려면 IPsec/IKE 매개 변수를 참조하세요.

이 문서에서는 IPsec/IKE 정책을 만들고 구성하고 새 연결 또는 기존 연결에 적용하는 방법에 대한 지침을 제공합니다.

고려 사항

이러한 정책을 사용할 때 다음과 같은 중요한 고려 사항에 유의하세요.

  • IPsec/IKE 정책은 표준HighPerformance (경로 기반) 게이트웨이 SKU에서만 작동합니다.
  • 지정된 연결에 대해 하나의 정책 조합만 지정할 수 있습니다.
  • IKE(주 모드)와 IPsec(빠른 모드) 둘 다에 대한 모든 알고리즘 및 매개 변수를 지정해야 합니다. 부분 정책 사양은 허용되지 않습니다.
  • 해당 VPN 디바이스 공급업체 사양을 참조하여 정책이 해당 온-프레미스 VPN 디바이스에서 지원되는지 확인하세요. 정책과 호환되지 않는 경우 사이트 간 연결을 설정할 수 없습니다.

IPsec/IKE 정책을 만들고 설정하는 워크플로

이 섹션에서는 사이트 간 VPN 연결에서 IPsec/IKE 정책을 만들고 업데이트하는 데 필요한 워크플로를 간략하게 설명합니다.

  1. 가상 네트워크 및 VPN 게이트웨이를 만듭니다.
  2. 프레미스 간 연결을 위한 로컬 네트워크 게이트웨이를 만듭니다.
  3. 선택한 알고리즘 및 매개 변수를 사용하여 IPsec/IKE 정책을 만듭니다.
  4. IPsec/IKE 정책을 사용하여 IPSec 연결을 만듭니다.
  5. 기존 연결에 대한 IPsec/IKE 정책을 추가/업데이트/제거합니다.

지원되는 암호화 알고리즘 및 주요 강점

다음 표에는 Azure Stack Hub 러기드 고객이 구성할 수 있는 지원되는 암호화 알고리즘 및 주요 강점이 나와 있습니다.

IPsec/IKEv2 옵션
IKEv2 암호화 AES256, AES192, AES128, DES3, DES
IKEv2 무결성 SHA384, SHA256, SHA1, MD5
DH 그룹 ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None
IPsec 암호화 GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, 없음
IPsec 무결성 GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS 그룹 PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, 없음
QM SA 수명 (선택 사항: 지정되지 않으면 기본값이 사용됨)
초(정수, 최소 300/기본값 27,000초)
KBytes(정수, 최소 1024/기본값 102,400,000KB)
트래픽 선택기 정책 기반 트래픽 선택기는 러기드화된 Azure Stack Hub에서 지원되지 않습니다.

온-프레미스 VPN 디바이스 구성은 Azure IPsec/IKE 정책에서 지정한 다음 알고리즘 및 매개 변수가 일치하거나 포함해야 합니다.

  • IKE 암호화 알고리즘(기본 모드/1단계).
  • IKE 무결성 알고리즘(기본 모드/1단계).
  • DH 그룹(주 모드/1단계).
  • IPsec 암호화 알고리즘(빠른 모드/2단계).
  • IPsec 무결성 알고리즘(빠른 모드/2단계).
  • PFS 그룹(빠른 모드/2단계).
  • SA 수명은 로컬 사양에만 해당하며 일치시킬 필요가 없습니다.

GCMAES가 IPsec 암호화 알고리즘에 사용되는 경우 IPsec 무결성에 대해 동일한 GCMAES 알고리즘 및 키 길이를 선택해야 합니다. 예: 둘 다에 GCMAES128 사용

앞의 표에서 각 항목은 다음을 나타냅니다.

  • IKEv2는 주 모드 또는 1단계에 해당합니다.
  • IPsec은 빠른 모드 또는 2단계에 해당합니다.
  • DH 그룹은 주 모드 또는 1단계에서 사용되는 Diffie-Hellmen 그룹을 지정합니다.
  • PFS 그룹은 빠른 모드 또는 2단계에서 사용되는 Diffie-Hellmen 그룹을 지정합니다.
  • IKEv2 기본 모드 SA 수명은 Azure Stack Hub 러기드 VPN 게이트웨이에서 28,800초로 고정됩니다.

다음 표에는 사용자 지정 정책에서 지원하는 해당 Diffie-hellman 그룹이 나열되어 있습니다.

Diffie-Hellman 그룹 DHGroup PFSGroup 키 길이
1 DHGroup1 PFS1 768비트 MODP
2 DHGroup2 PFS2 1024비트 MODP
14 DHGroup14 PFS2048 2048비트 MODP
DHGroup2048
19 ECP256 ECP256 256비트 ECP
20 ECP384 ECP384 384비트 ECP
24 DHGroup24 PFS24 2048비트 MODP

Azure ExpressRoute를 사용하여 Azure로 러기드화된 Azure Stack Hub 커넥트

개요, 가정 및 필수 구성 요소

Azure ExpressRoute를 사용하면 온-프레미스 네트워크를 Microsoft 클라우드로 확장할 수 있습니다. 연결 공급자가 제공하는 프라이빗 연결을 사용합니다. ExpressRoute는 공용 인터넷을 통해 VPN 연결이 아닙니다.

Azure ExpressRoute에 대한 자세한 내용은 ExpressRoute 개요를 참조하세요.

가정

이 문서에서는 다음을 가정합니다.

  • Azure에 대한 실무 지식이 있습니다.
  • 러기드화된 Azure Stack Hub에 대한 기본적인 이해가 있습니다.
  • 네트워킹에 대한 기본적인 이해가 있습니다.

사전 요구 사항

ExpressRoute를 사용하여 Azure Stack Hub 러기드 및 Azure를 연결하려면 다음 요구 사항을 충족해야 합니다.

  • 연결 공급자를 통해 프로비전된 ExpressRoute 회로입니다.
  • Azure에서 ExpressRoute 회로 및 VNet을 만드는 Azure 구독입니다.
  • 다음을 지원하는 라우터:
    • LAN 인터페이스와 Azure Stack Hub 러기드 다중 테넌트 게이트웨이 간의 사이트 간 VPN 연결
    • Azure Stack Hub 러기드 배포에 둘 이상의 테넌트가 있는 경우 여러 VRF(가상 라우팅 및 전달)를 만듭니다.
  • 다음이 포함된 라우터입니다.
    • ExpressRoute 회로에 연결된 WAN 포트입니다.
    • Azure Stack Hub 러기드 다중 테넌트 게이트웨이에 연결된 LAN 포트입니다.

ExpressRoute 네트워크 아키텍처

다음 그림에서는 이 문서의 예제를 사용하여 ExpressRoute 설정을 완료한 후 Azure Stack Hub 러기드 및 Azure 환경을 보여 줍니다.

ExpressRoute network architecture

다음 그림에서는 여러 테넌트가 ExpressRoute 라우터를 통해 Azure Stack Hub 러기드 인프라에서 Azure로 연결하는 방법을 보여 줍니다.

ExpressRoute network architecture multi-tenant