이 문서에서는 Azure에서 고가용성을 위해 NVA(네트워크 가상 어플라이언스) 세트를 배포하는 가장 일반적인 옵션에 대해 설명합니다. NVA는 DMZ(비무장지대) 가상 네트워크 및 공용 인터넷과 같이 서로 다른 보안 수준으로 분류된 네트워크 세그먼트 간의 트래픽 흐름을 제어하기 위해 사용됩니다.
NVA를 사용하여 서로 다른 보안 영역 간의 트래픽을 검사하는 디자인 패턴에는 다음과 같이 여러 가지가 있습니다.
- 가상 머신에서 인터넷으로의 송신 트래픽을 검사하고 데이터 반출을 방지합니다.
- 인터넷에서 가상 머신으로의 수신 트래픽을 검사하고 공격을 방지합니다.
- Azure에서 가상 머신 간의 트래픽을 필터링하고 손상된 시스템의 횡방향 이동을 방지합니다.
- 보안 수준이 서로 다른 것으로 간주될 경우 온-프레미스 시스템과 Azure 가상 머신 간의 트래픽을 필터링합니다. (예를 들어 Azure가 DMZ를 호스트하는 경우 내부 애플리케이션을 온-프레미스합니다.)
네트워크 방화벽, 레이어 4 역방향 프록시, IPsec VPN 엔드포인트, 웹 애플리케이션 방화벽 기능이 포함된 웹 기반 역방향 프록시, Azure, 레이어 7 부하 분산 장치 및 기타 항목에서 액세스할 수 있는 인터넷 페이지를 제한하는 인터넷 프록시 등 많은 NVA 예가 있습니다. 이 문서에서 설명하는 패턴을 사용하여 Azure 디자인에 이 모두를 삽입할 수 있습니다. Azure Firewall 및 Azure Application Gateway와 같은 Azure 자사 네트워크 가상 어플라이언스에도 이 문서의 뒷부분에 설명된 디자인이 사용됩니다. 이러한 옵션을 이해하는 것이 디자인 측면뿐만 아니라 네트워크 문제를 해결할 때에도 매우 중요합니다.
가장 먼저 대답해야 할 질문은 네트워크 가상 어플라이언스에 고가용성이 필요한 이유입니다. 그 이유는 이러한 디바이스가 네트워크 세그먼트 간의 통신을 제어하기 때문입니다. 사용할 수 없으면 네트워크 트래픽이 이동할 수 없고 애플리케이션 작동이 중지됩니다. Azure 및 기타 클라우드의 다른 모든 가상 머신과 마찬가지로 예약된 중단 및 예약되지 않은 중단으로 인해 NVA 인스턴스가 중단될 수도 있고 때때로 중단되기도 할 것입니다. Azure에서 단일 인스턴스 SLA를 제공하도록 이러한 NVA가 Premium Managed Disks로 구성된 경우에도 인스턴스가 중단됩니다. 따라서 가용성이 높은 애플리케이션은 적어도 연결을 보장할 수 있는 보조 NVA가 필요할 것입니다.
사전 요구 사항: 이 문서에서는 Azure 네트워킹, Azure Load Balancer 및 가상 네트워크 트래픽 라우팅(UDR)에 대한 기본적인 이해를 전제로 합니다.
Azure VNet에 네트워크 가상 어플라이언스를 배포하는 데 가장 적합한 옵션을 선택할 때 고려해야 할 가장 중요한 측면은 NVA 공급업체가 특정 디자인을 검토하고 유효성을 검사했는지 여부입니다. 공급업체는 또한 Azure에서 NVA를 통합하는 데 필요한 NVA 구성을 제공해야 합니다. NVA 공급업체가 NVA에 지원되는 디자인 옵션과 다른 대안을 제공하는 경우 다음 요소가 결정에 영향을 줄 수 있습니다.
- 수렴 시간: 각 디자인에서 실패한 NVA 인스턴스 외부로 트래픽을 유도하는 데 시간이 얼마나 걸리나요?
- 토폴로지 지원: 각 디자인 옵션으로 지원되는 NVA 구성은 무엇인가요? 활성/활성, 활성/대기, n+1 중복성을 포함하는 스케일 아웃 NVA 클러스터인가요?
- 트래픽 대칭: 비대칭 라우팅을 방지하기 위해 패킷에서 NVA가 SNAT(Source Network Address Translation)를 수행하도록 강제하는 특정 디자인이 있나요? 아니면 트래픽 대칭이 다른 방법으로 적용되나요?
이 문서의 다음 섹션에서는 NVA를 허브 및 스포크 네트워크로 통합하는 데 사용되는 가장 일반적인 아키텍처에 대해 설명합니다.
참고 항목
이 문서는 허브 및 스포크 디자인에 중점을 줍니다. 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를 지원합니다. | 동-서 흐름 없이 인터넷으로 송수신되는 흐름을 지원합니다. |
| PIP/UDR 변경 | NVA에 특별한 기능이 필요하지 않습니다. 대칭 트래픽을 보장합니다. | 활성/수동 디자인에만 해당합니다. 1-2분 정도의 높은 수렴 시간 |
Load Balancer 디자인
이 디자인에서는 2개의 Azure Load Balancer를 사용하여 NVA 클러스터를 나머지 네트워크에 노출합니다.
- 내부 Load Balancer는 Azure 및 온-프레미스의 내부 트래픽을 NVA로 리디렉션하는 데 사용됩니다. 이 내부 부하 분산 장치는 HA 포트 규칙을 사용하여 구성되므로, 모든 TCP/UDP 포트가 NVA 인스턴스로 리디렉션됩니다.
- 공용 Load Balancer는 NVA를 인터넷에 노출합니다. HA 포트가 인바운드 트래픽용이므로 전용 부하 분산 규칙에서 모든 개별 TCP/UDP 포트를 열어야 합니다.
다음 다이어그램은 인터넷에서 스포크 VNet의 애플리케이션 서버로 전송되는 패킷에 사용되는 홉 순서에 대해 설명합니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
NVA를 통해 스포크에서 공용 인터넷으로 트래픽을 전송하는 메커니즘은 내부 Load Balancer의 IP 주소가 다음 홉인 0.0.0.0/0에 대한 사용자 정의 경로입니다.
Azure와 공용 인터넷 사이의 트래픽의 경우 트래픽 흐름의 각 방향이 서로 다른 Azure Load Balancer를 통과합니다(공용 ALB를 통한 수신 패킷과 내부 ALB를 통한 송신 패킷). 따라서 트래픽 대칭이 필요한 경우 NVA 인스턴스가 SNAT(Source Network Address Translation)를 수행하여 반환 트래픽을 유치하고 트래픽 비대칭을 방지해야 합니다.
이 디자인은 Azure와 온-프레미스 네트워크 사이의 트래픽 검사를 위해서도 사용할 수 있습니다.
NVA를 통해 스포크 간에 트래픽을 전송하는 메커니즘이 정확히 동일하므로 추가 다이어그램이 제공되지 않습니다. 위의 예제 다이어그램에서 spoke1이 spoke2의 범위를 모르기 때문에 0.0.0.0/0 UDR은 spoke2로 주소 지정된 트래픽을 NVA의 내부 Azure Load Balancer로 보냅니다.
온-프레미스 네트워크와 Azure 사이 또는 Azure 가상 머신 사이의 트래픽의 경우 내부 Azure Load Balancer에 의해 트래픽 대칭이 보장됩니다. 즉, 트래픽 흐름의 양쪽 방향이 동일한 Azure Load Balancer를 통과할 때 동일한 NVA 인스턴스가 선택됩니다.
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로 고려될 수 있음)와 같은 레이어 7 부하 분산 장치로 교체하는 경우입니다. 이 경우 애플리케이션 게이트웨이의 트래픽이 VNet 내부에서 소싱되고 트래픽 비대칭이 문제가 되지 않기 때문에 NVA에는 앞에 있는 내부 Load Balancer만 필요합니다.
NVA는 레이어 7 부하 분산 장치에서 지원되지 않는 프로토콜에 대한 인바운드 트래픽과 잠재적으로 모든 송신 트래픽을 수신해야 합니다. Azure Firewall을 NVA로 사용하고 Azure Application Gateway를 레이어 7 웹 역방향 프록시로 사용할 때 이 구성에 대한 자세한 내용은 가상 네트워크에 대한 방화벽 및 애플리케이션 게이트웨이를 참조하세요.
Azure Route Server
Azure Route Server는 NVA가 BGP(Border Gateway Protocol)를 통해 Azure SDN과 상호 작용할 수 있게 해주는 서비스입니다. NVA가 Azure VNet에 존재하는 IP 접두사를 학습할 뿐만 아니라 Azure에 있는 가상 머신의 유효 경로 테이블에 경로를 주입할 수 있습니다.
위 다이어그램에서 각 NVA 인스턴스는 BGP를 통해 Azure Route Server를 사용하여 피어링됩니다. Azure Route Server가 NVA에서 보급된 경로를 프로그래밍하므로 스포크 서브넷에 경로 테이블이 필요하지 않습니다. Azure 가상 머신에 2개 이상의 경로가 프로그래밍된 경우 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의 가장 일반적인 옵션입니다. 예를 들어 Azure VNet에 구성된 접두사를 학습하거나 ExpressRoute 개인 피어링을 통해 특정 경로를 보급해야 하는 VPN 종료 NVA입니다.
게이트웨이 부하 분산 장치
Azure Gateway Load Balancer는 사용자 정의 경로를 사용하여 트래픽을 조정할 필요 없이 데이터 경로에 NVA를 삽입하기 위한 새로운 방법입니다. Azure Load Balancer 또는 공용 IP 주소를 통해 워크로드를 노출하는 가상 머신의 경우 인바운드 및 아웃바운드 트래픽을 다른 VNet에 있는 NVA 클러스터에 투명하게 리디렉션할 수 있습니다. 다음 다이어그램은 워크로드가 Azure Load Balancer를 통해 애플리케이션을 노출하는 경우 공용 인터넷의 인바운드 트래픽에 대해 패킷에 사용되는 경로에 대해 설명합니다.
이 NVA 주입 방법의 주요 이점 중 하나는 SNAT(Source Network Address Translation)가 트래픽 대칭을 보장하기 위해 필요하지 않다는 것입니다. 이 디자인 옵션의 또 다른 이점은 동일한 NVA를 사용해서 서로 다른 VNet에 대한 송수신 트래픽을 검사할 수 있으므로, NVA 관점에서 다중 테넌시를 달성할 수 있다는 것입니다. NVA VNet과 워크로드 VNet 간에 VNet 피어링이 필요하지 않고 워크로드 VNet에 사용자 정의 경로가 필요하지 않으므로 구성이 크게 간소화됩니다.
게이트웨이 Load Balancer를 사용한 서비스 주입은 Azure 공용 Load Balancer에 도달하는 인바운드 흐름(및 해당 반환 트래픽)과 Azure에서 시작되는 아웃바운드 흐름에 사용할 수 있습니다. Azure 가상 머신 간의 동-서 트래픽은 NVA 주입에 게이트웨이 Load Balancer를 활용할 수 없습니다.
NVA 클러스터에서 Azure Load Balancer 상태 검사 프로브를 사용하여 개별 NVA 인스턴스 오류를 감지하므로 매우 빠른 수렴 시간(10-15초)을 달성합니다.
PIP-UDR 변경
이 디자인 이면의 아이디어는 NVA 중복성 없이 필요한 설정을 수행하고 NVA에 가동 중지 시간이 발생할 경우 이를 수정하는 것입니다. 아래 다이어그램은 Azure 공용 IP 주소가 활성 NVA(NVA1)와 연결되고 스포크의 사용자 정의 경로에 활성 NVA의 IP 주소가 다음 홉(10.0.0.37)으로 지정되는 방식을 보여줍니다.
활성 NVA를 사용할 수 없게 되면 대기 NVA가 Azure API를 호출하여 공용 IP 주소와 스포크 사용자 정의 경로를 자신에게 다시 매핑합니다(또는 개인 IP 주소도 이동). 이러한 API 호출은 적용될 때까지 몇 분 정도 걸릴 수 있습니다. 이것이 이 디자인이 이 문서의 모든 옵션 중에서 가장 나쁜 수렴 시간을 제공하는 이유입니다.
이 디자인의 또 다른 제한 사항은 활성/대기 구성만 지원되어 확장성 문제가 발생할 수 있다는 것입니다. 즉, NVA에서 지원되는 대역폭을 늘려야 할 때 이 디자인에서 유일한 옵션은 두 인스턴스를 모두 확장하는 것입니다.
이 디자인의 한 가지 이점은 어느 시점에서든 활성 NVA가 하나만 있기 때문에 트래픽 대칭을 보장하기 위해 SNAT(Source Network Address Translation)가 필요하지 않다는 것입니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Keith Mayer | 수석 클라우드 솔루션 설계자
- Telmo Sampaio | 수석 서비스 엔지니어링 관리자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
- Azure Firewall을 사용하여 보안 하이브리드 네트워크를 구현하는 방법을 알아보세요.
- 경계 네트워크 - 클라우드 채택 프레임워크
- 클라우드 DMZ - 클라우드 채택 프레임워크