이 문서에서는 Azure에서 고가용성을 위해 NVA(네트워크 가상 어플라이언스) 집합을 배포하는 가장 일반적인 옵션을 설명합니다. NVA는 일반적으로 DMZ(De-Militarized Zone) Virtual Network와 공용 인터넷 간에 서로 다른 보안 수준으로 분류된 네트워크 세그먼트 간의 트래픽 흐름을 제어하거나 VPN 또는 SDWAN(Software-Defined WAN) 어플라이언스와 같은 외부 위치를 Azure에 연결하는 데 사용됩니다.
NVA를 사용하여 서로 다른 보안 영역 간의 트래픽을 검사하는 여러 디자인 패턴이 있습니다. 예를 들면 다음과 같습니다.
- 가상 머신에서 인터넷으로의 송신 트래픽을 검사하고 데이터 반출을 방지합니다.
- 인터넷에서 가상 머신으로의 수신 트래픽을 검사하고 공격을 방지합니다.
- Azure에서 가상 머신 간의 트래픽을 필터링하여 손상된 시스템의 횡적 이동을 방지합니다.
- 온-프레미스 시스템과 Azure 가상 머신 간의 트래픽을 필터링하려면 서로 다른 보안 수준에 속하는 것으로 간주됩니다. (예를 들어 Azure에서 DMZ를 호스트하고 내부 애플리케이션을 온-프레미스로 호스트하는 경우).
- 온-프레미스 네트워크 또는 기타 퍼블릭 클라우드와 같은 외부 위치에서 VPN 또는 SDWAN 터널을 종료하려면
NVA의 예는 다음과 같습니다.
- 네트워크 방화벽
- 계층 4 역방향 프록시
- IPsec VPN 엔드포인트
- SDWAN 어플라이언스
- 웹 애플리케이션 방화벽 기능이 있는 웹 기반 역방향 프록시
- Azure에서 액세스할 수 있는 인터넷 페이지를 제한하는 인터넷 프록시
- 계층 7 부하 분산 장치
이러한 모든 NVA는 이 문서에 설명된 패턴을 사용하여 Azure 디자인에 삽입할 수 있습니다. Azure Firewall , Azure Application Gateway 같은 Azure 자사 네트워크 가상 어플라이언스도 이 문서의 뒷부분에 설명된 디자인을 사용할 있습니다. 이러한 옵션을 이해하는 것은 디자인 관점에서 그리고 네트워크 문제를 해결할 때 모두 중요합니다.
대답해야 할 첫 번째 질문은 네트워크 가상 어플라이언스에 대한 고가용성이 필요한 이유입니다. 그 이유는 이러한 디바이스가 네트워크 세그먼트 간의 통신을 제어하기 때문입니다. 사용할 수 없는 경우 네트워크 트래픽이 흐르지 않고 애플리케이션이 작동을 중지합니다. 예약된 중단 및 예약되지 않은 중단은 때때로 NVA 인스턴스(Azure 또는 다른 클라우드의 다른 가상 머신)를 중단합니다. Azure에서 단일 인스턴스 SLA를 제공하도록 해당 NVA가 프리미엄 Managed Disks로 구성된 경우에도 인스턴스가 중단됩니다. 따라서 고가용성 애플리케이션에는 연결을 보장할 수 있는 두 번째 NVA 이상이 필요합니다.
필수 구성 요소: 이 문서에서는 Azure 네트워킹, Azure Load Balancer및 UDR(가상 네트워크 트래픽 라우팅)에 대한 기본적인 이해를 가정합니다.
Azure VNet에 네트워크 가상 어플라이언스 배포를 위한 최상의 옵션을 선택할 때 고려해야 할 가장 중요한 측면은 NVA 공급업체가 해당 특정 디자인을 검토하고 유효성을 검사했는지 여부입니다. 또한 공급업체는 Azure에서 NVA를 통합하는 데 필요한 필수 NVA 구성을 제공해야 합니다. NVA 공급업체가 NVA에 대해 지원되는 디자인 옵션으로 다른 대안을 제공하는 경우 이러한 요소는 결정에 영향을 줄 수 있습니다.
- 수렴 시간: 실패한 NVA 인스턴스에서 트래픽을 멀리 조종하기 위해 각 디자인에서 얼마나 걸리나요?
- 토폴로지 지원: 각 디자인 옵션에서 지원하는 NVA 구성은 무엇인가요? n+1 중복성이 있는 활성/활성/대기, 스케일 아웃 NVA 클러스터
- 트래픽 대칭: 특정 디자인에서 비대칭 라우팅을 방지하기 위해 NVA가 패킷에서 SNAT(원본 네트워크 주소 변환)를 수행하도록 강제하나요? 아니면 트래픽 대칭이 다른 수단에 의해 적용되는가?
문서의 다음 섹션에서는 NVA를 허브 및 스포크 네트워크에 통합하는 데 사용되는 가장 일반적인 아키텍처에 대해 설명합니다.
비고
이 문서에서는 Hub & 스포크 디자인집중합니다. Virtual WAN은 특정 NVA가 Virtual WAN 허브에서 지원되는지 여부에 따라 NVA를 배포하는 방법에 훨씬 더 규범적이므로 Virtual WAN 다루지 않습니다. 자세한 내용은 Virtual WAN 허브 네트워크 가상 어플라이언스를 참조하세요.
HA 아키텍처 개요
다음 아키텍처에서는 고가용성 NVA에 필요한 리소스 및 구성에 대해 설명합니다.
해결 방법 | 혜택 | 고려 사항 |
---|---|---|
Azure Load Balancer | 수렴 시간이 양호한 활성/활성, 활성/대기 및 스케일 아웃 NVA를 지원합니다. | NVA는 특히 활성/대기 배포의 경우 상태 프로브에 대한 포트를 제공해야 합니다. 트래픽 대칭이 필요한 방화벽과 같은 상태 저장 어플라이언스의 경우 인터넷을 오가는 흐름에는 SNAT가 필요합니다. |
Azure Route Server | NVA는 BGP를 지원해야 합니다. 활성/활성, 활성/대기 및 스케일 아웃 NVA를 지원합니다. | 트래픽 대칭에도 SNAT가 필요합니다. |
게이트웨이 부하 분산 장치 | 트래픽 대칭은 SNAT 없이 보장됩니다. NVA는 테넌트 간에 공유할 수 있습니다. 좋은 수렴 시간. 활성/활성, 활성/대기 및 스케일 아웃 NVA를 지원합니다. | East-West 흐름 없이 인터넷에서 들어오고 가는 흐름을 지원합니다. |
PIP/UDR 변경 | NVA에는 특별한 기능이 필요하지 않습니다. 대칭 트래픽 보장 | 활성/수동 디자인에만 해당합니다. 1-2분의 높은 수렴 시간 |
Load Balancer 디자인
이 디자인에서는 두 개의 Azure Load Balancer를 사용하여 NVA 클러스터를 네트워크의 나머지 부분에 노출합니다. 이 방법은 상태 저장 NVA와 상태 비주류 NVA 모두에 자주 사용됩니다.
- 내부 Load Balancer는 Azure 및 온-프레미스에서 NVA로 내부 트래픽을 리디렉션하는 데 사용됩니다. 이 내부 부하 분산 장치는 HA 포트 규칙으로 구성되므로 모든 TCP/UDP 포트가 NVA 인스턴스로 리디렉션됩니다.
- 공용 Load Balancer는 NVA를 인터넷에 노출합니다. HA 포트 인바운드 트래픽용이므로 모든 개별 TCP/UDP 포트는 전용 부하 분산 규칙에서 열어야 합니다.
다음 다이어그램에서는 인터넷에서 스포크 VNet의 애플리케이션 서버로 패킷이 공용 인터넷(남북 트래픽이라고도 함)을 제어하기 위해 방화벽 NVA를 트래버스하는 데 따르는 홉 시퀀스를 설명합니다.
Azure Load Balancer 통합
이 아키텍처의 Visio 파일 다운로드합니다.
NVA를 통해 스포크에서 공용 인터넷으로 트래픽을 보내는 메커니즘은 내부 Load Balancer의 IP 주소를 다음 홉으로 0.0.0.0/0
위한 User-Defined 경로입니다.
Azure와 공용 인터넷 간의 트래픽의 경우 트래픽 흐름의 각 방향이 다른 Azure Load Balancer를 교차합니다. 이는 수신 패킷이 공용 ALB를 통과하고 송신 패킷이 내부 ALB를 통과하기 때문에 방화벽 NVA에 공용 및 내부 네트워크 모두에 대한 단일 NIC가 있는 경우에도 발생합니다. 흐름의 양방향이 서로 다른 부하 분산 장치를 통과하기 때문에 트래픽 대칭이 필요한 경우 대부분의 방화벽에서와 같이 반환 트래픽을 유치하고 트래픽 비대칭을 방지하기 위해 NVA 인스턴스에서 SNAT(원본 네트워크 주소 변환)를 수행해야 합니다.
부하 분산 장치와 동일한 디자인을 사용하여 내부 부하 분산 장치만 관련된 Azure와 온-프레미스 네트워크(동/서부) 간의 트래픽을 검사할 수 있습니다.
사용하여 온-프레미스 트래픽을ALB Onpremises
NVA를 통해 스포크 간에 트래픽을 보내는 메커니즘은 정확히 동일하므로 다른 다이어그램이 제공되지 않습니다. 위의 예제 다이어그램에서 spoke1은 스포크2의 범위에 대해 알지 못하므로 0.0.0.0/0
UDR은 스포크2로 주소가 지정된 트래픽을 NVA의 내부 Azure Load Balancer로 보냅니다.
온-프레미스 네트워크와 Azure 간 또는 Azure 가상 머신 간 트래픽의 경우 트래픽 대칭은 내부 Azure Load Balancer에 의해 단일 NIC NVA에서 보장됩니다. 트래픽 흐름의 양방향이 동일한 Azure Load Balancer를 트래버스하는 경우 부하 분산 장치에서 동일한 NVA 인스턴스를 선택합니다. 통신의 각 감각에 대한 내부 부하 분산 장치가 있는 이중 NIC NVA의 경우 위의 남북 예제와 같이 SNAT를 통해 트래픽 대칭을 제공해야 합니다.
이 디자인에서 이중 NIC NVA가 직면하는 또 다른 과제는 부하 분산 장치의 상태 검사에 회신을 다시 보내는 것입니다. Azure Load Balancer는 항상 상태 검사 원본과 동일한 IP 주소를 사용합니다(168.63.129.16). NVA는 수신된 것과 동일한 인터페이스의 이 IP 주소에서 제공되는 상태 검사에 대한 답변을 보낼 수 있어야 합니다. 대상 기반 라우팅은 항상 동일한 NIC를 통해 상태 검사에 회신을 보내므로 일반적으로 운영 체제에서 여러 라우팅 테이블이 필요합니다.
Azure Load Balancer는 개별 NVA 중단에서 적절한 수렴 시간을 제공합니다. 상태 프로브 5초마다 전송할 수 있으며 백 엔드 인스턴스를 서비스에서 선언하는 데 3개의 실패한 프로브가 필요하므로 Azure Load Balancer가 트래픽을 다른 NVA 인스턴스로 수렴하는 데 일반적으로 10-15초가 걸립니다.
이 설정은 활성/활성 및 활성/대기 구성을 모두 지원합니다. 활성/대기 구성의 경우 NVA 인스턴스는 활성 역할에 있는 인스턴스에 대한 Load Balancer 상태 프로브에만 응답하는 TCP/UDP 포트 또는 HTTP 엔드포인트를 제공해야 합니다.
L7 부하 분산 장치 사용
보안 어플라이언스에 대한 이 디자인의 특정 사례는 Azure 공용 Load Balancer를 Azure Application Gateway(자체적으로 NVA로 간주될 수 있는)와 같은 Layer-7 부하 분산 장치로 대체하는 것입니다. 이 경우 NVA에는 워크로드 시스템에서 들어오는 트래픽에 대한 내부 Load Balancer만 필요합니다. 이 메커니즘은 이전 섹션에서 설명한 Azure Load Balancer의 상태 검사에서 라우팅 문제를 방지하기 위해 이중 NIC 디바이스에서 사용되는 경우가 있습니다. 이 디자인의 한 가지 제한 사항은 Layer-7 부하 분산 장치(일반적으로 HTTP(S))에서 지원하는 Layer-7 프로토콜만 지원한다는 것입니다.
NVA는 계층 7 부하 분산 장치에서 지원하지 않는 프로토콜 및 잠재적으로 모든 송신 트래픽에 대한 인바운드 트래픽을 가져와야 합니다. Azure Firewall을 NVA로 사용하고 Azure Application Gateway를 Layer-7 웹 역방향 프록시로 사용하는 경우 이 구성에 대한 자세한 내용은 가상 네트워크 대한방화벽 및 Application Gateway를 참조하세요.
Azure Route Server
Azure Route Server NVA가 BGP(Border Gateway Protocol)를 통해 Azure SDN과 상호 작용할 수 있는 서비스입니다. NVA는 Azure VNet에 존재하는 IP 접두사를 학습할 뿐만 아니라 Azure에서 가상 머신의 유효 경로 테이블에 경로를 삽입할 수 있습니다.
Azure Route Server 통합
위의 다이어그램에서 각 NVA 인스턴스는 Azure Route Server를 사용하여 BGP를 통해 피어됩니다. Azure Route Server는 NVA에서 보급한 경로를 프로그래밍하므로 스포크 서브넷에는 경로 테이블이 필요하지 않습니다. 둘 이상의 경로가 Azure 가상 머신에서 프로그래밍된 경우 ECMP(Equal Cost MultiPathing)를 사용하여 모든 트래픽 흐름에 대해 NVA 인스턴스 중 하나를 선택합니다. 결과적으로 트래픽 대칭이 요구 사항인 경우 이 디자인에서 SNAT는 필수입니다.
이 삽입 메서드는 활성/활성(모든 NVA가 Azure Route Server에 동일한 경로를 보급함) 및 활성/대기(하나의 NVA는 다른 경로보다 짧은 AS 경로로 경로를 보급함)를 모두 지원합니다. Azure Route Server는 최대 8개의 BGP 인접성을 지원합니다. 따라서 활성 NVA의 스케일 아웃 클러스터를 사용하는 경우 이 디자인은 최대 8개의 NVA 인스턴스를 지원합니다.
이 설정에서는 수렴 시간이 빠르며 BGP 인접성의 유지 및 대기 시간 타이머의 영향을 받습니다. Azure Route Server에는 기본 유지 및 홀드타임 타이머(각각 60초 및 180초)가 있지만 NVA는 BGP 인접 설정 중에 더 낮은 타이머를 협상할 수 있습니다. 이러한 타이머를 너무 낮게 설정하면 BGP가 불안정해질 수 있습니다.
이 디자인은 Azure 라우팅과 상호 작용해야 하는 NVA의 가장 일반적인 옵션입니다(예: 일반적으로 좋은 BGP 지원을 받고 Azure VNet에 구성된 접두사를 학습하거나 ExpressRoute 프라이빗 피어링을 통해 특정 경로를 보급해야 하는 SDWAN 또는 IPsec NVA). 이 유형의 어플라이언스는 일반적으로 상태 비대칭이므로 트래픽 대칭은 문제가 되지 않으므로 SNAT가 필요하지 않습니다.
게이트웨이 부하 분산 장치
azure Gateway Load Balancer User-Defined 경로로 트래픽을 조종할 필요 없이 데이터 경로에 NVA를 삽입하는 새로운 방법입니다. Azure Load Balancer 또는 공용 IP 주소를 통해 워크로드를 노출하는 Virtual Machines의 경우 인바운드 및 아웃바운드 트래픽을 다른 VNet에 있는 NVA 클러스터로 투명하게 리디렉션할 수 있습니다. 다음 다이어그램에서는 워크로드가 Azure Load Balancer를 통해 애플리케이션을 노출하는 경우 공용 인터넷의 인바운드 트래픽에 대해 패킷이 따르는 경로를 설명합니다.
게이트웨이 Load Balancer 통합
이 NVA 삽입 방법의 주요 장점 중 하나는 트래픽 대칭을 보장하기 위해 SNAT(Source Network Address Translation)가 필요하지 않다는 것입니다. 이 디자인 옵션의 또 다른 이점은 동일한 NVA를 사용하여 다른 VNet 간 트래픽을 검사하여 NVA 관점에서 다중 테넌트 기능을 달성할 수 있다는 것입니다. NVA VNet과 워크로드 VNet 간에 VNet 피어링이 필요하지 않으며 워크로드 VNet에는 User-Defined 경로가 필요하지 않으며, 이는 구성을 크게 간소화합니다.
게이트웨이 Load Balancer를 사용한 서비스 주입은 Azure 공용 Load Balancer(및 반환 트래픽)에 도달하는 인바운드 흐름 및 Azure에서 시작되는 아웃바운드 흐름에 사용할 수 있습니다. Azure 가상 머신 간의 East-West 트래픽은 NVA 주입을 위해 게이트웨이 Load Balancer를 활용할 수 없습니다.
NVA 클러스터에서 Azure Load Balancer 상태 검사 프로브는 개별 NVA 인스턴스 오류를 감지하는 데 사용되어 빠른 수렴 시간(10-15초)을 달성합니다.
PIP-UDR 변경
이 디자인의 이면에는 NVA 중복성 없이 필요한 설정이 있으며 NVA 가동 중지 시간이 발생할 경우 수정해야 한다는 개념이 있습니다. 아래 다이어그램은 Azure 공용 IP 주소가 활성 NVA(NVA1)에 연결되고 스포크의 User-Defined 경로에 활성 NVA의 IP 주소를 다음 홉(10.0.0.37
)으로 갖는 방법을 보여 줍니다.
이동 PIP/UDR
활성 NVA를 사용할 수 없게 되면 대기 NVA는 Azure API를 호출하여 공용 IP 주소와 스포크 User-Defined 경로를 자체로 다시 매핑합니다(또는 개인 IP 주소도 이동). 이러한 API 호출을 적용하는 데 몇 분 정도 걸릴 수 있으므로 이 디자인은 이 문서의 모든 옵션 중 최악의 수렴 시간을 제공합니다.
이 디자인의 또 다른 제한 사항은 활성/대기 구성만 지원되므로 확장성 문제가 발생할 수 있습니다. NVA에서 지원하는 대역폭을 늘려야 하는 경우 이 디자인의 유일한 옵션은 두 인스턴스를 모두 확장하는 것입니다.
이 디자인의 한 가지 이점은 지정된 시점에 NVA가 하나만 활성화되어 있으므로 트래픽 대칭을 보장하기 위해 SNAT(원본 네트워크 주소 변환)가 필요하지 않는다는 것입니다.
기여자
Microsoft에서 이 문서를 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.
주요 작성자:
- 키스 메이어 | 주요 클라우드 솔루션 설계자
- Telmo Sampaio | 수석 서비스 엔지니어링 관리자
- 호세 모레노 | 수석 엔지니어
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
- Azure Firewall을 사용하여 보안 하이브리드 네트워크 구현하는 방법을 알아봅니다.
- 경계 네트워크 - 클라우드 채택 프레임워크
- Cloud DMZ - 클라우드 채택 프레임워크