Cloud/AZURE

Azure Firewall을 위한 라우팅 정리

BOKCH1 2025. 4. 16. 14:57

Azure Firewall을 위해 알아야 할  포인트

User Defined Route (UDR) 기본 경로를 오버라이드해서 트래픽을 Firewall로 보냄, 사용자 지정 라우팅 테이블
Virtual Appliance Azure Firewall은 “가상 어플라이언스”로 취급됨
라우팅 테이블 연결 UDR은 특정 Subnet에 연결해야 효과가 있음
SNAT 이해 Azure Firewall이 인터넷으로 나갈 땐 SNAT을 사용하여 자신의 Public IP로 변환함

 

 

클라우드에서의 라우팅

클라우드에서는 일반적으로 다음과 같은 구조를 사용합니다:

  • 서브넷 단위로 라우팅 테이블(Route Table) 관리
  • 인터넷 통신은 IGW(Internet Gateway)
  • 온프렘 연동은 VPN Gateway or ExpressRoute
  • 특정 리소스끼리만 통신 허용 시 사용자 정의 라우팅(User Defined Route, UDR)

라우팅 설계 시 고려사항

  • 최단 경로가 항상 최적 경로는 아님 (보안, 트래픽 부하, SLA 고려)
  • 멀티 테넌시를 고려한 격리 정책 필요
  • HA (고가용성): 장애 대비 이중화 및 failover 설계
  • 모니터링 및 로깅: 트래픽 흐름 추적 필요

 

Azure Firewall과 라우팅의 관계

Azure Firewall 구조 이해

Azure Firewall은 보안 경계(Segmentation Boundary) 역할을 하며, 중앙에서 트래픽을 제어하는 허브(Hub)가 주 역할.

  • VNet 내 서브넷에 배포됨 (AzureFirewallSubnet 이라는 이름으로 고정)
  • 기본적으로 정책 기반 제어(네트워크/애플리케이션 규칙) 가능
  • 하지만! 트래픽이 Azure Firewall을 반드시 통과하도록 유도해야 의미 있음 👉 바로 이때 라우팅 설정 필요.

라우팅 테이블(Route Table) 관련

Azure에서는 서브넷 단위로 라우팅 테이블을 연결.
Azure의 기본 라우팅은 매우 간단하지만, 보안 제어를 위해 직접 구성하는 경우가 많음 👉 User Defined Route(UDR) 라고 부름

✅ 예시: Azure Firewall을 거쳐 나가는 아웃바운드 트래픽

[구성 가정]

  • VNet: VNet-A
  • Subnet1: AppSubnet (애플리케이션 서버)
  • Subnet2: AzureFirewallSubnet (Azure Firewall이 위치)
  • Azure Firewall의 프라이빗 IP: 10.0.2.4
  • 목적: AppSubnet에서 인터넷으로 나가는 트래픽을 모두 Firewall을 거치게 만들기

[라우팅 테이블 예시: AppSubnet에 연결할 UDR]

경로 대상 (Address Prefix)            다음 홉 유형 (Next Hop Type)                                             다음 홉 주소 (Next Hop IP)
0.0.0.0/0 Virtual Appliance 10.0.2.4

✅ 0.0.0.0/0 은 "인터넷 전체"를 의미, AppSubnet에서 출발하는 트래픽이 Azure Firewall의 IP (10.0.2.4)를 거쳐가도록 설정

       즉 : [App VM] → [라우팅 테이블] → [Azure Firewall] → [인터넷]

 

 

Hub-Spoke 구조란?

  • Hub VNet: 중앙 네트워크. 공통 인프라(예: Azure Firewall, VPN Gateway, Bastion 등) 이 위치
  • Spoke VNet들: 실제 애플리케이션이 배포된 각 업무 시스템의 네트워크
  • Hub와 Spoke는 VNet Peering으로 연결.

Azure Firewall이 포함된 Hub-Spoke 구조는 중앙 집중식 보안 제어(Centralized Security) 를 위한 대표적인 아키텍처

 

<참고>

- Hub-spoke network pattern : 고객 관리형 허브 인프라 솔루션

- Virtual WAN을 사용한 hub-spoke network pattern : MS 관리형 허브 인프라 솔루션

 

 

 

라우팅 흐름 요약 (Spoke → Internet 예시)

  1. Spoke VNet의 App VM에서 트래픽 발생
  2. 연결된 라우팅 테이블(UDR) 이 트래픽을 Hub VNet의 Azure Firewall로 전송 (Next Hop = Virtual Appliance)
  3. Azure Firewall에서 정책 확인 → 허용 시 인터넷으로 전달
  4. 나가는 트래픽은 SNAT되어 Azure Firewall의 Public IP로 나감

Firewall 없는 경우, 라우팅 흐름

  1. Spoke VNet의 App VM에서 트래픽 발생
  2. 연결된 **UDR(User Defined Route)**에 의해 트래픽은 Next Hop으로 지정된 NVA VM으로 전달
    • 예: Next hop = Virtual appliance, IP = NVA VM의 private IP
  3. NVA에서 트래픽 정책/라우팅 처리
    • iptables, NAT, 로그 수집 등 기능 수행 가능
  4. 허용된 트래픽은 인터넷으로 SNAT 후 전송
    • NVA VM의 Public IP로 나가거나,
    • Azure NAT Gateway를 따로 설정하여 SNAT 가능

 

왜 이렇게 구성할까?

장점                                           설명
중앙 집중 보안 관리 여러 Spoke의 트래픽을 하나의 Azure Firewall에서 제어 가능
비용 최적화 Spoke마다 Firewall 만들 필요 없음
정책 일관성 모든 VNet에 동일한 정책 적용 가능

 

 

✅ Azure Firewall SNAT / DNAT 통신 가능 조건 요약

항목                                                           조건
Firewall Policy / Rule 설정 Allow Rule로 포트 및 IP 허용해야 함
** SNAT은 Allow Rule, DNAT은 DNAT Rule + Allow Rule
라우팅 (UDR) Spoke Subnet의 UDR이 Azure Firewall을 Next Hop으로 지정해야 함
NSG (Network Security Group) NSG에서 포트를 허용하고 있어야 함 (종종 놓치기 쉬움)
Firewall에 Public IP 있음 DNAT 시 필수 (외부에서 접근 가능해야 하므로)
Inbound일 경우 DNAT Rule 추가 Azure Firewall → 내부 IP 매핑 명시

 

쉽게 기억하는 포인트설명

🚪 NSG = 문 앞의 경비 "이 포트로 들어오지 마!" (VM 바로 앞에서 제어)
🧱 Firewall Policy = 성문 앞의 보안 관제탑 "들어오는 놈들 다 검사하고 악성은 차단!" (중앙 집중형 통제)

 

아키텍처 흐름 예시

[User] 
  ↓
[NSG: 포트 확인]
  ↓
[Spoke Subnet]
  ↓
[UDR: 트래픽 -> Azure Firewall로 이동]
  ↓
[Azure Firewall + Policy: 허용 여부 판단]
  ↓
[인터넷 or 내부 서버로 전달]