네트워크가 더 이상 물리적 또는 가상 LAN에 있지 않기 때문에 클라우드는 방화벽 설계를 포함한 인프라 설계 방식을 바꾸고 있습니다. 물리적 네트워크의 일부 기능을 가상 네트워크(VNet)에서 사용할 수 있는 것은 아닙니다. 여기에는 부동 IP 주소나 브로드캐스트 트래픽 사용이 포함되며 HA 아키텍처의 구현에 영향을 줍니다. NVA(Network Virtual Appliances) 의 부하 분산 장치는 가상 네트워크 내에서 고가용성(HA) 아키텍처를 구현하려면 특정 방법으로 구현할 수 있거나 구현해야 합니다. 이 가이드에서는 타사 가상 어플라이언스를 사용하여 Azure에서 HA 방화벽(FW)을 디자인하기 위해 구조화된 접근 방식을 제공합니다.
고가용성 NVA를 디자인하기 위한 옵션
HA 아키텍처를 배포할 때 장애 조치(failover)를 제공하는 몇 가지 옵션이 있습니다.
- Azure API 관리 경로 테이블: 이 옵션은 VNet/서브넷에서 실행되는 모든 서비스에 대해 활성 게이트웨이 IP를 전환하기 위해 두 개의 경로 테이블(하나는 활성, 하나는 수동)을 사용합니다.
- Azure API 관리 유동 IP: 이 옵션은 FW에서 활성 FW와 대기 FW 사이를 이동할 수 있는 보조 IP 주소를 사용합니다.
- Load Balancer 관리: 이 옵션은 Azure Load Balancer를 사용하여 서브넷의 게이트웨이 IP로 작동한 다음, 트래픽을 활성 FW로 전달합니다. 실제 부하 분산을 제공하기 위해 트래픽 활성-활성을 전달하기도 합니다.
첫 두 옵션의 문제점은 장애 조치(failover)가 느리다는 것입니다. FW는 반드시 새 배포를 통해 Azure 서비스를 “재구성”하는 장애 조치를 지시해야 합니다. 배포 완료 속도에 따라 트래픽 흐름이 몇 분 동안 중단됩니다. 또한 두 방화벽이 동시에 작동하는 활성-활성 구성은 허용되지 않습니다.
이것이 세 번째 옵션이 가장 선호되는 이유입니다. 부하 분산 장치가 거의 즉시 대기 방화벽(활성-수동)으로 장애 조치(failover)하거나 오류가 발생한 방화벽(활성-활성)에서 로드를 제거할 수 있으므로 가동 중지 시간이 최소화됩니다. 그러나 부하 분산 장치는 트래픽 흐름에 영향을 미치고 TCP 패킷은 상태 저장 상태여야 하므로 "기본 게이트웨이"로만 사용할 수 없습니다.
2-레그 방화벽
다음 그림은 외부 부하 분산 장치와 백 엔드 서버 S1이 있는 두 개의 FW(FW-1 및 FW-2)로 시작합니다.
이 아키텍처는 인바운드 트래픽에 사용되는 간단한 설정입니다. 패킷이 부하 분산 장치에 도달하면 그 구성에서 대상 FW를 선택합니다. 그러면 선택한 방화벽에서 백 엔드(웹) 서버로 트래픽을 보냅니다. FW-1이 SNAT를 사용하는 경우 서버 S1은 FW-1의 내부 IP에서 오는 트래픽을 확인하므로 패킷에 대한 응답도 FW-1로 보냅니다. 이 시나리오에서는 FW-2에 대한 장애 조치(failover)가 빠르게 수행될 수 있습니다. 아웃바운드 트래픽의 경우 내부 측에 다른 부하 분산 장치를 추가할 수 있습니다. 서버 S1에서 트래픽을 시작할 때 동일한 원칙이 적용됩니다. 트래픽이 내부 LB(iLB)에 도달하면 방화벽을 선택한 다음, 외부 확인을 위해 NAT를 변환합니다.
3-레그 방화벽
방화벽에 다른 인터페이스를 추가할 때 문제가 발생하며 내부 영역 간의 NAT 변환을 사용하지 않도록 설정해야 합니다. 이 경우 서브넷-B 및 서브넷-C를 참조하세요.
내부 영역(서브넷-B 및 서브넷-C) 간의 L3 라우팅은 모두 NAT 없이 부하를 분산할 수 있습니다. 이 설정은 다른 보기에서 부하 분산 장치를 포함한 트래픽 흐름을 보다 명확하게 볼 수 있습니다. 아래 다이어그램은 내부 Load Balancer[iLB]가 FW의 특정 NIC에 연결된 보기를 보여줍니다.
L3 트래픽(NAT 없음)을 사용하면 S2는 S1 IP 주소를 소스 주소로 간주합니다. 그런 다음, S2는 서브넷 B에 대한 반환 트래픽(S1-IP가 속한)을 서브넷-C의 iLB로 보냅니다. 서브넷 B의 iLB 및 서브넷-C의 iLB는 부하 분산 알고리즘에 따라 FW-2에서 종료될 수 있는 트래픽 상태를 동기화하지 않습니다. 기본적으로 FW-2는 초기(녹색) 패킷에 대해 알지 못하므로 연결을 끊습니다.
일부 방화벽 공급업체는 방화벽 간의 연결 상태를 유지하려고 하지만, 연결 상태의 최신 상태를 유지하려면 거의 즉각적인 동기화가 필요합니다. 방화벽 공급업체가 이 설정을 권장하는지 확인합니다.
이 문제를 해결하는 가장 좋은 방법은 이를 제거하는 것입니다. 위의 예에서 이 솔루션은 Virtualized VNet의 이점을 제공하는 서브넷-C를 제거하는 것을 의미합니다.
네트워크 보안 그룹을 사용하여 서브넷의 호스트 분리
단일 서브넷에 두 개의 VM이 있는 경우 두 서브넷 간에 트래픽을 격리하는 NSG를 적용할 수 있습니다. 기본적으로 VNet 내부의 트래픽은 완전히 허용됩니다. NSG에서 모두 거부 규칙을 추가하면 모든 VM이 서로 격리됩니다.
VNet은 동일한 백 엔드(가상) 라우터를 사용합니다.
VNet/서브넷은 Azure에서 단일 백 엔드 라우터 시스템을 사용하므로 각 서브넷에 대해 라우터 IP를 지정할 필요가 없습니다. 경로 대상은 동일한 VNET의 어디에나 심지어 외부에 있을 수 있습니다.
가상화된 네트워크를 사용하면 모든 서브넷의 경로를 제어할 수 있습니다. 이러한 경로는 다른 서브넷의 단일 IP를 가리킬 수도 있습니다. 위의 그림에서 서브넷-D의 iLB는 두 방화벽의 부하를 분산시킵니다. S1이 트래픽을 시작하면(녹색), 예를 들어 FW-1에 대해 부하 분산됩니다. 그러면 FW-1은 S2에 연결됩니다(계속 녹색). S2는 응답 트래픽을 S1의 IP로 보냅니다(NAT를 사용하지 않음). 경로 테이블로 인해 S2는 게이트웨이와 동일한 iLB IP를 사용합니다. iLB는 트래픽을 초기 세션에 일치시킬 수 있으므로 항상 이 트래픽을 FW-1로 다시 가리킵니다. 그런 다음, FW-1은 이를 S1로 전송하여 동기 트래픽 흐름을 설정합니다.
이 설정이 작동하려면 FW에 서브넷-B 및 서브넷-C가 기본 서브넷 GW를 가리키는 라우팅 테이블(내부)이 있어야 합니다. 해당 서브넷 GW는 해당 VNET의 서브넷 범위에서 논리적으로 사용 가능한 첫 번째 IP입니다.
역방향 프록시 서비스에 미치는 영향
역방향 프록시 서비스를 배포할 때 일반적으로 FW 뒤에 있습니다. 대신 FW와 인라인으로 배치하고 실제로 FW를 통해 트래픽을 라우팅할 수 있습니다. 이 설정의 장점은 역방향 프록시 서비스가 연결 클라이언트의 원래 IP를 참조한다는 것입니다.
이 구성의 경우 서브넷-E의 경로 테이블은 내부 부하 분산 장치를 통해 서브넷-B와 서브넷-C를 가리켜야 합니다. 일부 역방향 프록시 서비스에는 이 네트워크 흐름에서 FW를 모두 제거할 수 있는 기본 제공 방화벽이 있습니다. 기본 제공 방화벽은 역방향 프록시에서 직접 서브넷-B/C 서버를 가리킵니다.
이 시나리오에서는 역방향 프록시에서도 SNAT가 필요하므로 FW에 의해 서브넷-A로 전송 및 거부되는 반환 트래픽이 발생하지 않습니다.
VPN/ER
Azure는 Azure Virtual Network 게이트웨이를 통해 BGP 사용/고가용성 VPN/ER 서비스를 제공합니다. 대부분의 설계자는 백 엔드 또는 비인터넷 연결을 위해 이 기능을 유지합니다. 이 설정은 라우팅 테이블이 이러한 연결 뒤에 있는 서브넷도 수용해야 함을 의미합니다. 서브넷-B/C 연결에는 큰 차이가 없지만 반환 트래픽 디자인에 차이가 있으며, 다음과 그림을 완성합니다.
이 아키텍처에서는 예를 들어 서브넷-B에서 서브넷-X로 FW에 도달하는 트래픽이 iLB로 전송되고, 이 트래픽은 두 방화벽으로 전송됩니다. FW 내의 내부 경로는 서브넷-GW(서브넷-D에서 사용 가능한 첫 번째 IP)로 트래픽을 다시 보냅니다. 서브넷-D의 다른 경로에는 Virtual Network 게이트웨이를 가리키는 서브넷-X 경로가 있으므로 트래픽을 게이트웨이 어플라이언스로 직접 보낼 필요는 없습니다. Azure 네트워킹은 실제 라우팅을 처리합니다.
서브넷-X에서 오는 반환 트래픽은 서브넷-D의 iLB로 전달됩니다. 또한 GatewaySubnet에는 서브넷-B-C에서 iLB까지를 가리키는 사용자 지정 경로도 있습니다. 서브넷-D는 iLB를 거치지 않습니다. 이는 일반 VNET 간 라우팅으로 처리됩니다.
도면에는 없지만 서브넷-B/C/D/게이트웨이는 서브넷-A가 iLB를 가리키는 경로를 포함하는 것이 좋습니다. 이 배열은 “일반적인” VNET 라우팅이 FW를 우회하지 않도록 하기 위한 것입니다. 이 서브넷-A는 Azure 네트워킹 스택에 따라 VNET의 또 다른 서브넷입니다. 사용자가 DMZ/인터넷 등으로 취급하더라도 서브넷-A를 다르게 취급하지는 않습니다.
요약
정리하면, 인터페이스(가상 또는 실제) 수가 많은 온-프레미스(물리적/VLAN 기반) 네트워크에서 방화벽을 처리하는 방식은 Azure에서와 다릅니다. 필요한 경우 여전히 이런 방식으로 어느 정도 가능할 수 있겠지만, 장애 조치(failover) 가동 중지 시간을 최소화할 수 있는 더 나은 방법이 있습니다. 활성-활성 구현 및 클린 라우팅 테이블을 사용하는 것입니다.
모든 트래픽에 대해 부하 분산 장치를 게이트웨이로 사용하는 방법에 대한 자세한 내용은 고가용성 포트 개요에서 찾을 수 있습니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Roelf Zomerman | 선임 클라우드 솔루션 설계자
다음 단계
구성 요소 기술에 대해 자세히 알아보세요.
관련 참고 자료
관련 아키텍처 살펴보기: