Azure Firewall UDR·DNS 설계: 규칙보다 먼저 트래픽 경로 증명하기
UDR, 대칭 반환 경로, DNS Proxy, Private Resolver, DNAT, 하이브리드 라우팅과 통제된 강제 터널링 분기를 사용해 단일 리전 Azure Firewall 허브-스포크 경로를 설계하고 검증합니다.
- Microsoft Learn 검토
- 2026-08-11
이 글의 목차
- 이 글에서 명시적으로 다루지 않는 범위
- 1. 이 글이 도와줄 의사결정
- 2. 처음부터 끝까지 하나의 고정 토폴로지 사용하기
- 3. 경로를 만들기 전에 트래픽 계약 작성하기
- 4. 머릿속에서 다섯 영역을 분리하기
- 5. Firewall 배포 전에 플랫폼 전용 서브넷 예약하기
- 2026년 사설 서브넷 기본값 반영하기
- 6. 롤백 지점을 보존하는 순서로 배포하기
- 7. 자동 전이가 아닌 전달 트래픽을 위해 피어링 구성하기
- 8. 경로 원본 우선순위보다 최장 접두사 일치를 먼저 적용하기
- 9. 경로와 연결 대상별로 경로 테이블 만들기
- 10. 아웃바운드 경로를 한 번에 하나의 결정으로 추적하기
- 11. 워크로드 간 내부(east-west) 트래픽을 양방향으로 추적하기
- 12. 하이브리드 트래픽을 경로가 있는 두 구간으로 다루기
- 13. 인바운드 DNAT를 좁게 유지하고 웹 인그레스와 구분하기
- 14. 애플리케이션 로그를 읽기 전에 주소 변환 예상하기
- 15. 각 DNS 구성요소에 하나의 명확한 역할 부여하기
- 현재 정책 상속 문서의 충돌 기록하기
- 16. DNS Proxy를 하나의 완전한 연결 사슬로 구성하기
- 17. 하이브리드 이름을 위해 Private Resolver를 Proxy의 상위 DNS로 배치하기
- 18. FQDN 네트워크 규칙을 클라이언트의 응답과 일치시키기
- 19. 0.0.0.0/0을 의도적으로 또는 우연히 우회하는 경로 목록화하기
- 20. Management NIC와 실제 강제 터널링 구분하기
- NAT Gateway는 선택된 인터넷 다음 홉을 따른다
- 21. 증상과 가장 먼저 확인할 계층 연결하기
- 22. 정해진 순서로 진단하고 검증하기
- 최소 검증 행렬
- 23. 체크리스트, 자가 점검과 기억 카드로 마무리하기
- 아키텍처 및 배포 체크리스트
- DNS 및 우회 체크리스트
- 운영 및 전환 체크리스트
- 자가 점검 질문
- 1분 기억 카드
- 참고 자료
Azure Firewall 리소스가 정상이고 정책에 올바른 규칙이 있어도 애플리케이션 트래픽은 Firewall을 완전히 우회할 수 있다. 첫 패킷은 Firewall을 지났지만 응답이 다른 경로로 돌아올 수도 있고, 클라이언트와 Firewall이 같은 이름을 서로 다른 주소로 해석할 수도 있다. 더 구체적인 플랫폼 경로를 통해 프라이빗 엔드포인트에 바로 도달할 수도 있다. 어느 경우든 규칙을 하나 더 바꾼다고 실제 문제가 해결될 가능성은 낮다.
설계할 때 유용한 단위는 Firewall 리소스 하나가 아니라 연결의 전체 대화다.
이름 확인
→ 선택된 경로
→ Firewall 판단
→ 필요한 경우 주소 변환
→ 목적지 리스너
→ 대칭 반환 경로
→ 타임스탬프가 있는 증적이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 모듈 1을 12개 주제로 나눈 학습 계획의 일곱 번째 상세 노트다. 모듈 1 복습 글은 더 넓은 보안 지도를 제공한다. 바로 앞의 Azure Firewall SKU 비교 글에서는 기능과 성능의 경계를 선택했다. 이번 글은 그 결정 이후부터 시작해, 선택한 Firewall이 실제로 의미를 갖게 만드는 경로를 구축한다.
이 글은 강의 녹취록, 평가 답안, 운영 환경 변경 기록 또는 모든 환경에 적용되는 랜딩 존 템플릿이 아닌 독립 학습 노트다. 라우팅 동작, DNS 동작, 플랫폼 기본값과 알려진 문제는 2026년 8월 11일 Microsoft 공식 자료를 기준으로 검토했다.
이 글에서 명시적으로 다루지 않는 범위
예제는 Azure Firewall Standard, IPv4, 단일 리전의 고객 관리형 허브 하나를 사용한다. Basic, Standard, Premium 비교는 반복하지 않는다. 포털 전체 실습, Bicep·Terraform 모듈, 다중 리전 허브, Virtual WAN 라우팅 의도(Routing Intent), TLS 검사, IDPS 조정, SNAT 확장 설계, 인바운드 웹 아키텍처도 다루지 않는다. 상세 규칙 컬렉션, 구조화된 KQL 쿼리와 재사용 가능한 검증 명령은 다음 예정 글인 azure-firewall-rules-logging-validation에서 다룬다. 아직 작성하지 않은 그 글로 연결되는 URL은 만들지 않는다.
1. 이 글이 도와줄 의사결정
결정해야 할 질문은 다음과 같다.
소규모 허브-스포크 환경에 Azure Firewall을 어디에 배치하고, 필요한 각 흐름을 어떻게 Firewall로 보내며, DNS 응답과 반환 경로를 어떻게 일치시키고, 상세 규칙에 투자하기 전에 그 결과를 어떻게 증명할 것인가?
이 글을 읽은 뒤에는 다음 작업을 할 수 있어야 한다.
- 배포 성공과 데이터 경로 성공을 구분한다.
- VNet 피어링이 제공하는 것과 전이 라우팅을 제공하지 않는 이유를 설명한다.
- Route Table(경로 테이블) 화면만 믿지 않고 실제 목적지에 대한 유효 경로를 읽는다.
- 경로 원본의 우선순위보다 최장 접두사 일치가 먼저 적용되는 이유를 설명한다.
- 아웃바운드, 워크로드 간 내부(east-west), 하이브리드와 인바운드 트래픽의 경로 레코드를 각각 만든다.
- 각 방향의 반환 경로를 어디서 통제해야 하는지 식별한다.
- VNet DNS 설정, Azure Firewall DNS Proxy, 사용자 지정 상위 DNS, Azure Private DNS와 Azure DNS Private Resolver를 구분한다.
- FQDN 네트워크 규칙에 클라이언트와 Firewall의 일치된 이름 확인이 필요한 이유를 설명한다.
- 직접 피어링, 서비스 엔드포인트와 프라이빗 엔드포인트 우회 경로를 식별한다.
- Management NIC와 실제 강제 터널링(Forced Tunneling)을 구분한다.
- 선택된 다음 홉이 가상 어플라이언스(Virtual appliance)인 흐름을 NAT Gateway가 처리하지 않는 이유를 설명한다.
- 정해진 순서로 실패한 연결을 진단한다.
- 필요한 모든 경로에 대해 성공, 실패, 우회와 복구 증적을 만든다.
결과물은 도식 하나가 아니라 다음과 같은 경로 기록이어야 한다.
주소와 서브넷 계획
+ 트래픽 계약
+ 피어링 설정
+ 경로 테이블 연결과 유효 경로
+ DNS 클라이언트, Proxy, 상위 DNS와 프라이빗 영역 연결 구조
+ 정방향과 반환 경로 증명
+ NAT 예상 결과
+ 필수 허용 및 인접 거부 테스트
+ 진단 목적지와 타임스탬프
+ 전환, 롤백과 재평가 조건2. 처음부터 끝까지 하나의 고정 토폴로지 사용하기
예제는 의도적으로 작게 구성한다. 이 워크로드에는 DNS Proxy, 사용자 지정 DNS와 네트워크 규칙의 FQDN이 필요하므로 Azure Firewall Standard를 이미 선택했다. SKU를 다시 정당화하는 것이 목적이 아니다. 입문자도 모든 홉을 예측할 수 있을 만큼 하나의 설계를 이해하는 것이 목적이다.
인터넷 및 승인된 파트너
↑ 아웃바운드 ↓ 인바운드 DNAT
데이터 공용 IP
┌──────────────────┐
│ Azure Firewall │
│ Standard │
│ 사설 10.0.0.4 │
└────────┬─────────┘
│
허브 VNet 10.0.0.0/16
┌────────────────────┼─────────────────────┐
│ │ │
DNS Private VPN/ExpressRoute 관리 경로
Resolver 게이트웨이 활성화된 경우
고정 인바운드 플랫폼 전용
10.0.1.4
│
├──────────── 허브-스포크 피어링 ────────────────┐
│ │
애플리케이션 스포크 10.10.0.0/16 데이터 스포크 10.20.0.0/16
애플리케이션 서브넷 10.10.1.0/24 서비스 서브넷 10.20.1.0/24
애플리케이션 VM 10.10.1.4 API VM 10.20.1.4
│ │
└──── 애플리케이션-데이터 직접 피어링 없음 ──────┘
온프레미스: 허브 게이트웨이를 통하는 172.20.0.0/16뒤에서 사용하는 공용 주소는 배포값이 아니라 문서 작성용 예시 주소다. 애플리케이션 VM에는 공용 IP가 없다. 관리 접근은 앞선 VM 설계 노트의 사설 관리 방식을 따르며, 임의의 공용 SSH 규칙을 만들지 않는다.
Firewall을 다시 배포하지 않고 강제 터널링 분기를 설명할 수 있도록 이 예제에서는 Management NIC를 활성화한다. 그러나 그 설정만으로 트래픽이 온프레미스로 강제 전송되는 것은 아니다. 기본 경로에서는 여전히 테넌트의 인터넷 트래픽이 Firewall 데이터 경로에서 직접 나간다.
3. 경로를 만들기 전에 트래픽 계약 작성하기
경로는 이름이 지정된 하나의 연결에 맞을 때만 올바르다. 5-튜플, 이름 확인 예상 결과, 주소 변환 예상 결과와 반환 경로 담당 주체부터 정의한다.
| ID | 시작 주체 | 요청 목적지 | 프로토콜 | 예상 경로와 결과 |
|---|---|---|---|---|
DNS-PUBLIC | 애플리케이션 VM 10.10.1.4 | Firewall DNS Proxy 10.0.0.4 | UDP/TCP 53 | Proxy가 승인된 상위 DNS로 전달하고 공용 응답을 돌려줌 |
OUT-HTTPS | 애플리케이션 VM 10.10.1.4 | packages.vendor.example | TCP 443 | 애플리케이션 UDR → Firewall → 데이터 경로 공용 SNAT → 인터넷, 허용 |
EW-API | 애플리케이션 VM 10.10.1.4 | api.internal.contoso.com → 10.20.1.4 | TCP 8443 | 애플리케이션 UDR → Firewall → 데이터 스포크, 대칭 반환, 허용 |
HYB-API | 애플리케이션 VM 10.10.1.4 | 온프레미스 API 172.20.10.20 | TCP 443 | 애플리케이션 UDR → Firewall → 허브 게이트웨이, 게이트웨이 반환 → Firewall → 애플리케이션 스포크 |
IN-PARTNER | 문서 예시용 파트너 범위 198.51.100.0/24 | Firewall 데이터 공용 IP, 포트 9443 | TCP 9443 | 제한된 DNAT → 10.10.1.4:9443, 승인된 출발지만 허용 |
NEG-OUT | 애플리케이션 VM 10.10.1.4 | 유사하지만 승인되지 않은 공급업체 이름 | TCP 443 | 동일한 Firewall 경로, 거부 |
NEG-EW | 애플리케이션 VM 10.10.1.4 | 데이터 VM, 포트 9444 | TCP 9444 | 동일한 Firewall 경로, 거부 |
NEG-IN | 승인되지 않은 공용 출발지 | Firewall 데이터 공용 IP, 포트 9443 | TCP 9443 | 일치하는 DNAT 없음, 거부 |
표에서 거부 테스트(negative test)에 의도적으로 “동일한 Firewall 경로”라고 썼다. Firewall을 우회한 실패 연결은 Firewall이 거부했다는 증거가 아니다. 일치하는 경로와 Firewall 레코드가 없는 성공 테스트(positive test)도 의도한 통제가 허용했다는 증거가 아니다.
상세 규칙 이름과 컬렉션 우선순위는 다음 글에서 구현한다. 지금은 경로, DNS, 정책과 증적 레코드가 같은 요구사항을 가리킬 수 있도록 각 흐름의 의도 ID를 유지한다.
4. 머릿속에서 다섯 영역을 분리하기
입문자는 흔히 “Firewall이 이 URL을 허용하나요?”라는 하나의 질문에 너무 많은 의미를 넣는다. 이를 다섯 개의 작은 영역으로 나눈다.
| 영역 | 질문 | 증적 |
|---|---|---|
| 이름 확인 | 어느 Resolver가 응답했고 어떤 IPv4 주소를 반환했는가? | 클라이언트 Resolver 설정과 타임스탬프가 있는 쿼리 결과 |
| 정방향 경로 | 반환된 IP에 대해 Azure가 어느 다음 홉을 선택했는가? | 출발지 NIC의 유효 경로와 Network Watcher 다음 홉 |
| 정책 적용 | 어느 정책과 규칙 동작이 연결을 처리했는가? | 실제 적용된 Firewall 정책과 일치하는 Firewall 이벤트 |
| 주소 변환 | 출발지 또는 목적지 주소가 변환되었는가? | SNAT/DNAT 예상 결과, Firewall 레코드와 목적지 관찰값 |
| 반환 경로 | 응답이 동일한 상태 저장형 Firewall을 통과하는가? | 목적지 측 유효 경로, 게이트웨이 경로와 응답 증적 |
순서가 중요하다.
DNS가 올바른 주소를 반환해도 라우팅이 Firewall을 우회할 수 있다.
라우팅이 Firewall에 도달해도 정책이 연결을 거부할 수 있다.
정책이 요청을 허용해도 백엔드에 리스너가 없을 수 있다.
백엔드가 요청을 받아도 응답이 다른 경로로 돌아갈 수 있다.이렇게 분리하면 DNS, 라우팅 또는 애플리케이션 실패를 숨기려고 무작위로 규칙을 바꾸는 일을 피할 수 있다.
5. Firewall 배포 전에 플랫폼 전용 서브넷 예약하기
허브에는 각 전용 서비스를 위한 겹치지 않는 주소 공간이 있어야 한다. Firewall을 일반 워크로드 서브넷에 배치하거나 소규모 실습용 서브넷이 나중에도 안전하게 확장될 것이라고 가정하지 않는다.
| VNet 또는 서브넷 | 예시 범위 | 용도 | 중요 제약 조건 |
|---|---|---|---|
| 허브 VNet | 10.0.0.0/16 | 공유 라우팅, 보안, DNS와 하이브리드 서비스 | 두 스포크 및 온프레미스와 겹치면 안 됨 |
AzureFirewallSubnet | 10.0.0.0/26 | Azure Firewall 테넌트 데이터 경로 | 정확한 예약 이름, 최소 /26 |
AzureFirewallManagementSubnet | 10.0.0.64/26 | 분리된 플랫폼 관리 경로 | 정확한 예약 이름, 최소 /26, Management NIC 활성화 시 필수 |
| Resolver 인바운드 서브넷 | 10.0.1.0/28 | Private Resolver 고정 인바운드 엔드포인트 10.0.1.4 | 위임된 전용 서브넷, 최소 /28 |
| Resolver 아웃바운드 서브넷 | 10.0.1.16/28 | Private Resolver 아웃바운드 엔드포인트와 규칙 세트 | 위임된 별도 전용 /28 서브넷 |
GatewaySubnet | 10.0.2.0/27 | VPN 또는 ExpressRoute 게이트웨이 | 정확한 예약 이름, 0.0.0.0/0을 포함한 경로 테이블 연결 금지 |
| 애플리케이션 스포크 | 10.10.0.0/16 | 애플리케이션 워크로드 | 이 예제에서는 허브에만 피어링 |
| 애플리케이션 서브넷 | 10.10.1.0/24 | 애플리케이션 VM 10.10.1.4 | rt-app 연결 |
| 데이터 스포크 | 10.20.0.0/16 | 내부 서비스 워크로드 | 이 예제에서는 허브에만 피어링 |
| 서비스 서브넷 | 10.20.1.0/24 | API VM 10.20.1.4 | rt-data 연결 |
| 온프레미스 | 172.20.0.0/16 | 하이브리드 종속 대상 | 명시적으로 광고하고 필터링함 |
허브 VNet 접두사를 목적지로 하고 Firewall 사설 IP를 다음 홉으로 지정하는 경로를 만들지 않는다. 스포크-허브 피어링을 통해 10.0.0.4가 다음 홉으로 도달 가능해야 한다. 다음 홉을 다시 그 자신으로 보내면 루프가 생기거나 연결이 끊길 수 있다.
2026년 사설 서브넷 기본값 반영하기
Microsoft 문서에 따르면 2026년 3월 31일 이후 공개된 API 버전을 사용하는 새 VNet의 서브넷은 defaultOutboundAccess=false가 기본값이다. 포털에서도 이미 새 서브넷의 기본값은 사설이다. 기존 VNet은 자동으로 바뀌지 않으며, 오래된 배포 API 버전은 이 속성을 설정하지 않은 채 암시적인 기본 아웃바운드 액세스를 허용할 수 있다.
이 설계는 암시적인 아웃바운드 액세스에 의존하지 않는다. 모든 워크로드 송신 경로는 Azure Firewall을 통해 명시적으로 구성한다. 포털, Terraform 공급자와 오래된 템플릿이 똑같이 동작한다고 가정하지 말고 API 버전과 실제 defaultOutboundAccess 값을 기록한다. 사설 서브넷에 Internet 다음 홉 예외가 있어도 명시적인 아웃바운드 방식이 없으면 실패한다는 점도 기억해야 한다. “경로에 Internet이라고 쓰여 있다”는 사실만으로 공용 출발지 주소가 생기는 것은 아니다.
6. 롤백 지점을 보존하는 순서로 배포하기
가장 안전한 순서는 새 Firewall, DNS 연결 사슬, 정책 의도와 증적 목적지가 준비될 때까지 기존 트래픽 경로를 유지하는 것이다.
- 주소 계획, 트래픽 계약, 담당자, 유지 관리 시간과 롤백 기준을 확정한다.
- 진단 목적지를 만들고 어떤 구조화된 Firewall 및 DNS 범주를 보존할지 정한다.
- 서비스를 배치하기 전에 모든 예약 서브넷을 포함한 허브와 스포크 VNet을 만든다.
- 데이터 경로 공용 IP, 관리 공용 IP, Firewall 정책과 Management NIC가 활성화된 Standard Firewall을 만든다.
- 배포가 정상 상태가 될 때까지 기다린 뒤 실제 Firewall 사설 IP, 데이터 공용 IP, 관리 공용 IP와 리소스 ID를 기록한다.
- Private Resolver 엔드포인트와 전달 규칙을 배포한 뒤, 워크로드 클라이언트를 개입시키지 않고 상위 DNS 이름 확인 경로를 증명한다.
- 두 허브-스포크 피어링을 만들고 설정을 검증한다.
- Firewall의 상위 DNS를 구성하고 DNS Proxy를 활성화하되 아직 모든 클라이언트를 전환하지 않는다.
- 경로 테이블을 만들되 운영 서브넷에는 연결하지 않는다.
- 테스트 흐름에 필요한 최소 정책 의도만 준비한다. 상세 규칙 구현은 다음 글의 범위다.
- 카나리 워크로드 서브넷 하나를 고르고 VNet DNS 설정을 변경한 뒤 클라이언트를 재시작하거나 DHCP를 갱신하고 경로 테이블을 연결한다.
- 다른 서브넷으로 연결 범위를 넓히기 전에 허용, 거부, 우회, DNS와 반환 경로 테스트를 실행한다.
경로 테이블을 마지막에 연결하는 것이 중요하다. Firewall이 준비되지 않았거나 사설 다음 홉이 틀렸거나 피어링이 완성되지 않았거나 정책에 승인된 초기 연결 흐름이 없으면, 0.0.0.0/0 UDR 하나가 정상 서브넷을 블랙홀로 만들 수 있다.
Azure Firewall의 사설 주소는 AzureFirewallSubnet에서 동적으로 할당된다. 문서화된 알려진 문제에 따르면 Firewall을 할당 해제(deallocate)한 뒤 다시 할당(allocate)하면 주소가 바뀔 수 있다. 할당 관련 작업을 수행한 뒤에는 트래픽을 다시 열기 전에 실제 사설 IP를 모든 UDR 다음 홉 및 VNet DNS 서버 설정과 비교한다. “리소스 이름이 바뀌지 않았다”는 사실은 충분한 증적이 아니다.
7. 자동 전이가 아닌 전달 트래픽을 위해 피어링 구성하기
VNet 피어링은 두 VNet 사이에 직접 도달할 수 있는 경로를 제공한다. 허브를 모든 스포크 사이의 라우터로 만들어 주지는 않는다. 애플리케이션 스포크와 데이터 스포크가 각각 허브에 피어링되어 있다는 이유만으로 서로 통신할 수 있는 것은 아니다.
| 피어링 방향 | Allow VNet access | Allow forwarded traffic | 게이트웨이 설정 |
|---|---|---|---|
| 허브 → 애플리케이션 | 예 | 예 | 허브 게이트웨이를 사용할 때만 Allow gateway transit |
| 애플리케이션 → 허브 | 예 | 예 | 승인된 하이브리드 설계에서만 Use remote gateways |
| 허브 → 데이터 | 예 | 예 | 필요할 때만 Allow gateway transit |
| 데이터 → 허브 | 예 | 예 | 필요할 때만 Use remote gateways |
| 애플리케이션 ↔ 데이터 | 직접 피어링 없음 | 해당 없음 | 경로를 검토하지 않고 추가하면 중앙 검사를 우회함 |
Allow forwarded traffic이 중요한 이유는 일반적인 사설 라우팅에서 Azure Firewall을 떠나는 패킷의 원래 출발지가 Firewall 자체의 사설 주소가 아니기 때문이다. 다른 VNet에서 넘어온 전달 트래픽이다. 해당 경로와 관계있는 양방향에서 이 설정을 구성하고 검증한다.
애플리케이션-데이터 직접 피어링을 만들면 원격 VNet에 대해 더 구체적인 시스템 경로가 생긴다. 의도적으로 짧은 지연 시간의 직접 연결을 중시하는 설계라면 유용할 수 있다. 그러나 여기서는 트래픽 계약에 중앙 검사가 필요하므로 사용하지 않는다. 누군가 나중에 이 피어링을 추가하면 유효 경로를 다시 검토해야 한다.
8. 경로 원본 우선순위보다 최장 접두사 일치를 먼저 적용하기
Azure는 경로 테이블을 위에서 아래로 읽지 않는다. 먼저 목적지 IP를 포함하는 가장 구체적인 주소 접두사를 선택한다. /32는 /24, /16, 0.0.0.0/0보다 더 구체적이다. 후보 경로의 접두사가 같을 때에만 일반적인 원본 우선순위가 적용된다.
가장 긴 일치 접두사가 먼저
→ 같은 접두사라면 UDR > BGP 경로 > 시스템 경로플랫폼 예외도 있다. 로컬 VNet 또는 VNet 피어링 관련 트래픽의 시스템 경로는 BGP 경로가 더 구체적이더라도 우선한다. VirtualNetworkServiceEndpoint 경로는 UDR로 재정의할 수 없다. 하나의 구호를 모든 Azure 서비스에 적용하지 말고 항상 실제 목적지에 대한 유효 결과를 확인한다.
| 애플리케이션 VM에서 본 목적지 | 후보 경로 | 선택 결과 | 교훈 |
|---|---|---|---|
| 공용 공급업체 IP | 시스템 0.0.0.0/0 → Internet, UDR 0.0.0.0/0 → 10.0.0.4 | Firewall로 가는 UDR | 접두사가 같으므로 UDR이 우선 |
Firewall 10.0.0.4 | UDR 0.0.0.0/0, 허브 피어링 10.0.0.0/16 | 허브 피어링 | 더 구체적인 경로 덕분에 다음 홉에 도달 가능 |
데이터 VM 10.20.1.4 | UDR 10.20.0.0/16 → 10.0.0.4, 같은 접두사가 될 수 있는 피어링 경로 | Firewall로 가는 UDR | 명시적인 같은 접두사 UDR이 향후 직접 피어링 우회를 방지 |
프라이빗 엔드포인트 10.20.2.7 | UDR 10.20.0.0/16, 이 NIC까지 전파되었다면 시스템 10.20.2.7/32 → InterfaceEndpoint | 출발지 NIC의 유효 경로에 실제로 나타날 때만 /32가 우선 | 실제 출발지 확인: 이 토폴로지에서 애플리케이션과 데이터는 직접 피어링되지 않음 |
| 서비스 엔드포인트를 사용하는 Azure 서비스 | UDR 0.0.0.0/0, 서비스 접두사 경로 | VirtualNetworkServiceEndpoint | 서비스 엔드포인트는 의도적으로 허용되는 우회 유형 |
실무 원칙은 다음과 같다.
기본 경로는 Azure가 더 구체적인 모든 경로를 제외한 뒤에야 포괄 경로로 동작한다.
9. 경로와 연결 대상별로 경로 테이블 만들기
경로 이름보다 중요한 것은 접두사, 다음 홉 유형, 다음 홉 주소, 전파 동작과 연결된 서브넷이다. 이 예제에서는 현재 기본 경로만으로도 전달할 수 있는 원격 접두사를 명시적으로 정의한다. 나중에 더 구체적인 피어링 또는 BGP 경로가 나타나도 검사 의도를 보호하기 위한 선택이다.
| 경로 테이블과 연결 대상 | 접두사 | 다음 홉 유형 | 다음 홉 주소 | 용도 |
|---|---|---|---|---|
rt-app → 애플리케이션 서브넷 | 0.0.0.0/0 | Virtual appliance | 10.0.0.4 | Firewall을 통한 공용 아웃바운드 |
rt-app → 애플리케이션 서브넷 | 10.20.0.0/16 | Virtual appliance | 10.0.0.4 | Firewall을 통한 애플리케이션-데이터 통신 |
rt-app → 애플리케이션 서브넷 | 172.20.0.0/16 | Virtual appliance | 10.0.0.4 | Firewall을 통한 애플리케이션-온프레미스 통신 |
rt-data → 서비스 서브넷 | 0.0.0.0/0 | Virtual appliance | 10.0.0.4 | Firewall을 통한 데이터 워크로드의 공용 아웃바운드 |
rt-data → 서비스 서브넷 | 10.10.0.0/16 | Virtual appliance | 10.0.0.4 | Firewall을 통한 데이터-애플리케이션 반환 |
rt-data → 서비스 서브넷 | 172.20.0.0/16 | Virtual appliance | 10.0.0.4 | Firewall을 통한 데이터-온프레미스 통신 |
rt-gateway → GatewaySubnet | 10.10.0.0/16 | Virtual appliance | 10.0.0.4 | 하이브리드 인바운드와 반환 트래픽이 애플리케이션보다 먼저 Firewall에 도달 |
rt-gateway → GatewaySubnet | 10.20.0.0/16 | Virtual appliance | 10.0.0.4 | 하이브리드 인바운드와 반환 트래픽이 데이터보다 먼저 Firewall에 도달 |
이 하이브리드 예제에서 스포크 경로 테이블은 게이트웨이가 전파한 온프레미스 경로에 의존하지 않는다. 명시적인 온프레미스 접두사가 Firewall로 향한다. 그와 별개로 Firewall 데이터 서브넷에는 Firewall에서 허브 게이트웨이로 향하는 유효한 경로가 학습되거나 정의되어 있어야 한다. 모든 경로 테이블에서 BGP 전파 확인란을 그대로 복사하지 말고 명시적인 설계 결정으로 취급한다.
GatewaySubnet에는 0.0.0.0/0을 넣지 않는다. Microsoft 문서에 따르면 이 구성은 게이트웨이 작동을 중단시킬 수 있다. 정확한 스포크 접두사만 사용한다. 워크로드 경로 테이블을 AzureFirewallSubnet에 연결하지 않으며, Firewall 공용 IP를 가상 어플라이언스 다음 홉으로 사용하지도 않는다. UDR의 대상은 Firewall 사설 IP다.
연결한 뒤에는 각 출발지와 목적지 NIC에서 유효 경로를 내보낸다. 경로 테이블 리소스는 의도한 입력을 보여주지만, 유효 경로 테이블은 시스템, 피어링, BGP와 UDR이 합쳐진 실제 결과를 보여준다.
10. 아웃바운드 경로를 한 번에 하나의 결정으로 추적하기
OUT-HTTPS 흐름은 이미 알고 있는 IP가 아니라 이름에서 시작한다.
1. 애플리케이션 VM이 구성된 Resolver 10.0.0.4에 packages.vendor.example을 질의한다.
2. Azure Firewall DNS Proxy가 승인된 상위 Resolver로 쿼리를 전달한다.
3. 클라이언트는 Firewall이 FQDN 정책에 사용할 수 있는 것과 같은 응답을 받는다.
4. 애플리케이션 VM이 반환된 공용 IPv4 주소의 TCP 443으로 연결한다.
5. rt-app이 0.0.0.0/0 → Virtual appliance 10.0.0.4를 선택한다.
6. 허브 피어링을 통해 사설 다음 홉에 도달한다.
7. Azure Firewall이 의도한 정책을 평가하고 연결을 허용한다.
8. Firewall이 사설 출발지를 데이터 경로 공용 IP로 SNAT한다.
9. 인터넷 서비스가 해당 공용 IP로 응답한다.
10. 상태 저장형 연결 추적이 응답을 10.10.1.4로 다시 매핑한다.10.0.0.4로 보내는 DNS 쿼리는 워크로드의 기본 UDR 때문에 원을 그리며 전달되지 않는다. 더 구체적인 허브 피어링 경로를 통해 Firewall 사설 주소에 도달하고, DNS Proxy가 Firewall에서 쿼리를 종료한다. 그 뒤의 데이터 연결은 목적지가 공용이므로 기본 UDR을 사용한다.
서로 독립적인 네 가지 관찰값으로 흐름을 증명한다.
- 클라이언트가
10.0.0.4를 Resolver로 사용하고 예상한 응답을 받는다. - Network Watcher가 반환된 목적지 IP에 대해
VirtualAppliance와10.0.0.4를 보고한다. - 테스트 타임스탬프에 예상한 Firewall 판단이 나타난다.
- 목적지가 승인된 송신 공용 IP를 관찰하고 애플리케이션 응답에 성공한다.
NEG-OUT도 실행한다. 이름 확인과 경로는 동일하게 성공하되 Firewall에서 거부되어야 한다. DNS 실패 또는 경로 우회를 정책 거부 증적 대신 사용할 수 없다.
11. 워크로드 간 내부(east-west) 트래픽을 양방향으로 추적하기
EW-API는 목적지가 일반적으로 실제 출발지를 볼 수 있어야 하는 사설 연결이다.
정방향
애플리케이션 VM 10.10.1.4
→ DNS Proxy가 api.internal.contoso.com을 10.20.1.4로 확인
→ rt-app: 10.20.0.0/16 → 10.0.0.4
→ 허브 피어링 → Azure Firewall
→ 사설 트래픽 정책 판단
→ 허브-데이터 피어링
→ API VM 10.20.1.4:8443
반환
API VM 10.20.1.4
→ rt-data: 10.10.0.0/16 → 10.0.0.4
→ Azure Firewall 상태 테이블
→ 허브-애플리케이션 피어링
→ 애플리케이션 VM 10.10.1.4이 예제는 의도적으로 TCP 8443에 네트워크 규칙을 사용한다. Azure Firewall은 RFC 1918 사설 목적지로 가는 네트워크 규칙 트래픽을 기본적으로 SNAT하지 않는다. 따라서 API VM은 애플리케이션 VM의 사설 출발지를 보며 API VM의 라우팅 결정이 중요하다. 반면 애플리케이션 규칙 트래픽은 사설 목적지로 보낼 때도 항상 SNAT된다. 이 흐름에 애플리케이션 규칙을 사용했다면 관찰되는 출발지와 주소 변환 레코드가 달라졌을 것이다. 응답이 상태 저장형 Firewall을 우회하면 요청이 API에 도달했더라도 연결이 실패할 수 있다.
설계에는 서로 다른 네 가지 허용이 필요하다. 피어링은 전달 트래픽을 운반해야 하고, 출발지 NSG는 송신을 허용해야 하며, Azure Firewall 정책은 의도한 흐름을 허용해야 한다. 목적지 NSG와 게스트 리스너도 연결을 받아야 한다. 이들은 중복 통제가 아니다. 서로 다른 경계를 적용한다.
나중에 애플리케이션-데이터 직접 피어링이 추가되면 10.20.0.0/16 피어링 시스템 경로가 우회 후보가 된다. rt-app의 명시적인 같은 접두사 UDR은 동일한 접두사에서 UDR이 우선하므로 선택된 다음 홉을 Firewall로 유지한다. 피어링 또는 주소 공간이 변경될 때마다 유효 경로를 다시 내보낸다.
12. 하이브리드 트래픽을 경로가 있는 두 구간으로 다루기
HYB-API 흐름은 Firewall과 VPN 또는 ExpressRoute 게이트웨이를 모두 통과한다. 터널이 정상이라는 사실만으로 Azure Firewall이 경로에 놓이는 것은 아니다.
Azure에서 온프레미스로
애플리케이션 VM
→ rt-app: 172.20.0.0/16 → Azure Firewall 10.0.0.4
→ Firewall 사설 정책 판단
→ 허브 게이트웨이 방향으로 학습되거나 정의된 경로
→ VPN/ExpressRoute
→ 온프레미스 API 172.20.10.20
온프레미스 응답
온프레미스 API
→ VPN/ExpressRoute를 통해 10.10.0.0/16으로 가는 온프레미스 경로
→ Azure GatewaySubnet
→ rt-gateway: 10.10.0.0/16 → Azure Firewall 10.0.0.4
→ Firewall 상태 테이블
→ 허브-애플리케이션 피어링
→ 애플리케이션 VM게이트웨이 경로 테이블에는 0.0.0.0/0이 아니라 정확한 스포크 접두사가 들어간다. 온프레미스 라우팅도 정확한 Azure 접두사를 알아야 한다. Azure의 경로는 지사 라우터에 없는 경로를 고칠 수 없다.
각 방향에 대해 다음 증적을 보존한다.
172.20.10.20에 대한 애플리케이션 NIC의 유효 경로- 허브 게이트웨이 방향의 Firewall 경로
10.10.0.0/16에 대한 온프레미스 경로10.0.0.4로 향하는GatewaySubnetUDR- Firewall의 허용 판단과 상태 저장형 응답
- 조직이 SNAT 범위를 의도적으로 변경하지 않았다면 사설 경로 SNAT이 없다는 예상 결과
이것은 사설 하이브리드 전송이지 아직 인터넷 강제 터널링이 아니다. 실제 강제 터널링은 Firewall 데이터 경로가 0.0.0.0/0을 온프레미스 에지로 보낼 때에만 시작된다.
13. 인바운드 DNAT를 좁게 유지하고 웹 인그레스와 구분하기
IN-PARTNER 흐름은 문서에 명시된 파트너 범위 하나에 비 HTTP/S 서비스 하나만 공개한다. 공용 웹 애플리케이션은 일반적으로 승인된 WAF 또는 역방향 프록시에서 연결을 종료해야 한다. 이 예제에서는 인바운드 네트워크 경로를 학습할 목적으로만 Azure Firewall DNAT를 사용한다.
승인된 파트너 198.51.100.0/24
→ Azure Firewall 데이터 공용 IP:9443
→ 특정 출발지, 프로토콜, 포트에 대한 DNAT 일치
→ 변환된 목적지 10.10.1.4:9443
→ 애플리케이션 서브넷 NSG와 게스트 리스너
→ 응답이 Azure Firewall 상태로 반환
→ 공용 클라이언트DNAT가 일치하면 목적지를 변환하고 변환된 연결을 암시적으로 허용한다. 이를 보완한다는 이유로 넓은 Any 출발지를 사용하지 않는다. 실제 파트너 범위, 목적, 담당자, 만료일과 반드시 실패해야 할 인접 출발지를 기록한다. 규칙 컬렉션 구현은 다음 글에서 다루지만, 경로 계약은 이미 설명할 수 없는 와일드카드를 거부해야 한다.
Azure Firewall은 대칭 라우팅을 유지하기 위해 인바운드 DNAT 연결의 출발지를 자체 사설 주소 중 하나로 SNAT한다. 따라서 백엔드가 패킷의 출발지로 원래 공용 클라이언트 주소를 받지 않는다. HTTP 애플리케이션에 원본 클라이언트 추적이 필요하다면 애플리케이션 인식 프록시 헤더를 통해 이를 보존하면서 헤더의 신뢰 경계를 보호하는 아키텍처를 사용한다. Azure Firewall DNAT는 인바운드 WAF도, 원본 출발지 보존 기능도 아니다.
인바운드 출발지 주소 변환이 대칭 경로 유지에 도움이 되더라도 반환 경로를 검증해야 한다. 백엔드 리스너, 서브넷 NSG, 게스트 방화벽, Firewall NAT 이벤트, 응답과 관찰된 출발지를 확인한다. 내부 VM이 Firewall 자체 공용 IP를 통해 DNAT 백엔드에 도달할 수 있다고 가정해서도 안 된다. Azure Firewall은 이러한 헤어핀 패턴을 알려진 제한 사항으로 문서화하고 있다.
이 인바운드 분기는 기본 직접 인터넷 데이터 경로에 속한다. 20절의 실제 강제 터널링 분기에 그대로 적용하지 않는다. Microsoft 문서에 따르면 Firewall 데이터 경로가 온프레미스로 강제될 때 공용 인터넷 DNAT는 비대칭 반환 경로가 생길 수 있어 지원되지 않는다.
14. 애플리케이션 로그를 읽기 전에 주소 변환 예상하기
주소 변환은 각 참여자가 관찰할 수 있는 값을 바꾼다. 테스트 전에 예상 출발지와 목적지를 적는다.
| 흐름 | 기본 변환 동작 | 목적지에서 일반적으로 보이는 값 | 반환 요구사항 |
|---|---|---|---|
| DNS 클라이언트 → Firewall DNS Proxy | 고객 데이터 경로의 SNAT을 가정할 필요 없음, 쿼리가 Proxy에서 종료됨 | Firewall이 DNS 확인자로 보임 | Proxy가 정상 상위 DNS에 도달해야 함 |
| 스포크 → 공용 인터넷 | Firewall이 사설 출발지를 데이터 경로 공용 IP로 SNAT | Firewall 공용 IP | 응답이 동일한 Firewall 상태로 반환 |
| 네트워크 규칙을 사용하는 애플리케이션 스포크 → 데이터 스포크 | RFC 1918 목적지에는 기본적으로 SNAT 없음 | 애플리케이션 VM 10.10.1.4 | rt-data가 10.10.0.0/16을 Firewall로 반환 |
| 네트워크 규칙을 사용하는 스포크 → RFC 1918 온프레미스 | 기본적으로 SNAT 없음 | 원래 스포크 사설 IP | 온프레미스와 GatewaySubnet 경로가 Firewall을 통해 반환 |
| 애플리케이션 규칙을 사용하는 사설 목적지 | Azure Firewall이 항상 SNAT | Firewall 사설 주소 | 변환된 출발지를 통해 반환이 Firewall 상태로 진입 |
| 공용 클라이언트 → DNAT 백엔드 | 목적지가 변환되고 인바운드 출발지가 SNAT됨 | Firewall 사설 주소 | Firewall 상태가 응답을 다시 공용 흐름으로 변환 |
| 강제 터널링에서 Firewall → 온프레미스 인터넷 에지 | 인터넷 흐름이 Firewall 사설 IP로 SNAT될 수 있음 | 사설 범위 동작을 의도적으로 바꾸지 않았다면 Firewall 사설 주소 | 온프레미스 에지가 인터넷 송신과 반환 경로를 담당 |
이는 기본값일 뿐 검증을 생략해도 된다는 뜻은 아니다. 네트워크 규칙에서 Azure Firewall의 기본 사설 범위에는 RFC 1918 범위와 RFC 6598 공유 주소 공간인 100.64.0.0/10이 포함된다. 다른 내부 접두사를 사용하는 조직은 사용자 지정 사설 범위 구성을 기록해야 한다. 0.0.0.0/0을 사설 범위로 설정하면 네트워크 규칙이 처리하는 목적지에 SNAT을 수행하지 않으며, 해당 흐름은 인터넷으로 직접 나갈 수 없게 된다. 애플리케이션 규칙의 SNAT까지 비활성화하는 것은 아니며 애플리케이션 규칙은 항상 SNAT한다. 이를 가벼운 최적화가 아니라 강제 터널링 설계 결정으로 다룬다.
지원되는 직접 송신 설계에서 나중에 NAT Gateway를 AzureFirewallSubnet에 연결하면 인터넷 목적지에는 NAT Gateway 공용 IP가 보인다. 이 변화는 트래픽 계약, 파트너 허용 목록, 비용 모델과 증적에 반영해야 한다. NAT Gateway를 Firewall 서브넷에 올바르게 통합했을 때 Azure Firewall이 검사 경로에서 사라지는 것은 아니다.
15. 각 DNS 구성요소에 하나의 명확한 역할 부여하기
“Azure DNS를 사용한다”는 말만으로는 완전한 DNS 아키텍처가 되지 않는다. 클라이언트, Proxy, 상위 Resolver, 전달 규칙과 영역 연결은 서로 다른 구성요소다.
| 구성요소 | 이 예제에서의 역할 | 흔한 실수 |
|---|---|---|
| 스포크 VNet DNS 설정 | 워크로드 클라이언트에 10.0.0.4를 Resolver로 제공 | VNet 설정을 바꾼 뒤 기존 VM을 재시작하거나 갱신하지 않음 |
| Azure Firewall DNS Proxy | 포트 53에서 수신하고 쿼리를 전달하며 클라이언트와 Firewall의 이름 확인을 일치시킴 | 권한 있는 프라이빗 DNS 영역으로 오해 |
| Firewall 또는 Firewall 정책 DNS 설정 | 상위 DNS 서버 지정, 이 예제에서는 10.0.1.4 | 도달할 수 없는 서버를 지정하거나 전달 루프 생성 |
| Private Resolver 인바운드 엔드포인트 | 허브 내부의 고정 주소 10.0.1.4에서 재귀 쿼리 수신 | 온프레미스 클라이언트가 Azure 플랫폼 Resolver에 직접 쿼리할 수 있다고 기대 |
| Private Resolver 아웃바운드 엔드포인트와 규칙 세트 | corp.contoso.com 같은 선택된 네임스페이스를 온프레미스 DNS로 전달 | 쿼리를 다시 Firewall Proxy로 보내는 . 규칙 생성 |
| Azure Private DNS 영역과 VNet 연결 | 승인된 VNet Resolver 경로에 사설 레코드 공개 | Microsoft 소유의 넓은 기본 도메인을 Firewall 허브에 연결 |
| 온프레미스 DNS | 승인된 사내 네임스페이스의 권한 있는 서버 역할 유지 | 정의된 조건부 경로로 Azure 스포크 레코드를 반환하지 못함 |
일반적인 순서는 다음과 같다.
클라이언트는 VNet과 DHCP 상태에 구성된 Resolver에 질의한다.
Firewall DNS Proxy는 응답을 만들어 내지 않고 쿼리를 전달한다.
구성된 상위 DNS가 해당 사설, 사내 또는 공용 네임스페이스를 찾는다.
응답이 Proxy를 통해 돌아온다.
클라이언트는 반환된 IP로 별도의 데이터 연결을 시작한다.
라우팅은 DNS 경로와 별개로 해당 IP를 평가한다.DNS 응답은 UDR을 만들지 않고, UDR은 올바른 DNS 응답을 보장하지 않는다. 두 증적을 모두 보존한다.
현재 정책 상속 문서의 충돌 기록하기
Microsoft의 DNS 설정 가이드에는 자식 Firewall 정책이 부모 DNS 설정을 상속하고 재정의할 수 있다고 나온다. 그러나 현재 Azure Firewall 알려진 문제 페이지에는 자식 정책이 해당 설정을 안정적으로 상속하지 못해 부모 변경 후 규칙 FQDN을 확인하지 못할 수 있다고 나온다. Microsoft가 대상 환경에서 이 충돌을 해결할 때까지는 상속에 의존하지 말고 각 자식 정책에 DNS 설정을 직접 구성하고 검증한다. 운영 결정에는 두 문서의 날짜를 함께 기록한다.
16. DNS Proxy를 하나의 완전한 연결 사슬로 구성하기
DNS Proxy 구성에는 세 가지 필수 통제 지점이 있다.
- Azure Firewall이 사용할 상위 DNS를 구성하고 검증한다.
- 해당 Firewall 또는 Firewall 정책에서 DNS Proxy를 활성화한다.
- 각 클라이언트 VNet에서 Firewall 사설 IP를 사용자 지정 DNS 서버로 설정한다.
기존 VM은 DHCP 임대를 갱신할 때까지 현재 DNS 설정을 유지한다. Microsoft는 VNet DNS 서버를 변경한 뒤 연결된 VM을 재시작하라고 명시한다. 포털 설정에 10.0.0.4가 보여도 게스트가 여전히 오래된 DNS 서버에 쿼리한다면 변경이 완료된 것이 아니다.
올바른 구성
애플리케이션 VM → Firewall Proxy 10.0.0.4 → Private Resolver 10.0.1.4
├─ Azure/사설 응답
└─ 조건에 따라 온프레미스로 전달
피해야 할 루프
Firewall Proxy → Private Resolver → 기본 전달 → Firewall Proxy경로에 필요한 곳에서는 UDP와 TCP 53을 모두 허용한다. DNS는 흔히 UDP로 시작하지만 큰 응답이나 다른 조건에서는 TCP를 사용할 수 있다. Firewall 데이터 경로에서 모든 상위 DNS에 도달할 수 있는지 테스트하고 Resolver 응답이 돌아올 수 있는지 확인한다.
Azure Firewall은 사용자 지정 DNS 서버 주소를 최대 15개 지원한다. 여러 서버를 구성하면 클라이언트가 정한 기본·보조 순서로 처리하지 않고 하나를 무작위로 선택한다. DNS Proxy는 비정상 상위 DNS를 감시하고 사용 가능한 다른 서버로 옮길 수 있지만, 구성한 상위 DNS가 모두 가용하지 않을 때 Azure DNS로 조용히 대체하지 않는다. 실제 이중화를 설계하고 모든 상위 DNS가 실패하는 조건을 테스트한다.
Proxy는 성공 응답을 TTL에 따라 최대 1시간, 부정 응답을 최대 30분간 캐시한다. 레코드가 만료되기 전에 미리 가져오지는 않는다. 따라서 수정한 DNS 레코드가 한동안 계속 잘못된 것처럼 보일 수 있으며 “매초 재시도”는 유용한 복구 계획이 아니다. 쿼리 시간, 응답 서버, 응답값, TTL과 캐시 예상 동작을 기록한다.
17. 하이브리드 이름을 위해 Private Resolver를 Proxy의 상위 DNS로 배치하기
예제에서는 클라이언트에 세 종류의 네임스페이스가 필요하므로 중앙 Azure DNS Private Resolver를 사용한다.
애플리케이션 VM, Resolver = 10.0.0.4
→ Azure Firewall DNS Proxy
→ 사용자 지정 상위 DNS = Private Resolver 고정 인바운드 엔드포인트 10.0.1.4
├─ api.internal.contoso.com
│ → 허브 Resolver 경로에 연결된 Private DNS 영역
├─ service.corp.contoso.com
│ → 아웃바운드 엔드포인트와 전달 규칙
│ → 온프레미스 DNS
└─ packages.vendor.example
→ Azure 제공/공용 이름 확인Private Resolver 인바운드와 아웃바운드 엔드포인트는 서로 분리된 전용 서브넷을 사용한다. 이 중앙 설계에서 corp.contoso.com → 온프레미스 DNS를 포함한 전달 규칙 세트는 허브 VNet에 연결한다. Firewall Proxy가 Resolver 인바운드 엔드포인트로 쿼리를 보내면 허브 VNet 컨텍스트에 연결된 전달 규칙이 적용된다. 온프레미스 DNS 서비스는 Azure가 호스팅하는 사설 네임스페이스에 대해 168.63.129.16을 직접 쿼리하지 않고 인바운드 엔드포인트를 사용한다. Azure 플랫폼 Resolver 주소는 Azure VNet 내부에서만 도달할 수 있다.
인바운드 주소 10.0.1.4는 Firewall이 사용자 지정 상위 DNS로 저장하므로 명시적으로 고정 할당한다. 동적으로 할당된 인바운드 엔드포인트 주소는 엔드포인트를 다시 프로비저닝한 뒤 바뀔 수 있다. 동적 할당을 사용한다면 재프로비저닝 작업을 DNS 드리프트 이벤트로 취급하고 Firewall 설정과 이름 확인 테스트를 다시 검증해야 한다.
사내 규칙이 같은 인바운드 엔드포인트가 아니라 온프레미스 DNS로 전달되므로 이 규칙 세트를 허브에 연결해도 안전하다. 사설 네임스페이스를 허브 인바운드 엔드포인트로 전달하는 다른 설계에서는 해당 전달 규칙 세트를 허브 VNet에도 연결하면 안 된다. DNS 확인 루프가 생길 수 있다.
미묘하지만 중요한 경계가 있다. Private DNS 영역을 Firewall VNet에 연결하면 Azure Firewall 자체가 규칙을 처리하기 위해 해당 영역의 이름을 확인할 수 있다. 그러나 DNS Proxy가 그 영역을 모든 하위 클라이언트 응답에 합쳐 준다는 뜻은 아니다. Proxy는 하위 쿼리를 구성된 상위 DNS로 전달한다. 그 상위 DNS도 Private DNS 영역에 접근할 수 있어야 한다. 이 예제에서는 Private Resolver가 그 접근을 제공한다.
Firewall 허브에서 blob.core.windows.net처럼 Microsoft가 소유한 넓은 기본 도메인을 재정의하는 영역을 만들고 연결하지 않는다. Microsoft는 이 구성이 Azure Firewall의 관리, 로깅, 모니터링과 업데이트에 필요한 엔드포인트 이름 확인을 방해할 수 있다고 경고한다. 워크로드 서비스에는 문서화된 Private Link 영역 및 영역 그룹 패턴, 적절한 경우 직접 소유한 고유 하위 도메인, 또는 Firewall 플랫폼의 이름 확인을 오염시키지 않는 별도 VNet 설계를 사용한다.
각 네임스페이스를 독립적으로 검증한다.
- 공용 이름이 의도한 공용 주소를 반환한다.
api.internal.contoso.com이10.20.1.4를 반환한다.- 사내 이름이 전달 규칙을 통해 온프레미스 응답을 반환한다.
- 존재하지 않는 이름이 예상한 부정 결과를 만든다.
- 어떤 상위 DNS도 같은 쿼리를 다시 순환 경로로 보내지 않는다.
18. FQDN 네트워크 규칙을 클라이언트의 응답과 일치시키기
Azure Firewall Standard는 애플리케이션 규칙이 처리하지 않는 TCP·UDP 프로토콜의 네트워크 규칙 목적지에 FQDN을 사용할 수 있다. Firewall이 확인된 IP 주소로 규칙을 구현하므로 이 설계에는 DNS Proxy가 필요하다.
규칙이 time.vendor.example을 지정한다고 가정한다.
Firewall 상위 DNS가 time.vendor.example → IP1로 확인
Firewall이 네트워크 규칙의 주소 집합을 IP1으로 갱신
클라이언트가 Firewall Proxy를 우회해 같은 이름 → IP2로 확인
클라이언트가 IP2로 연결
결과: 경로는 Firewall에 도달하지만 FQDN 네트워크 규칙과 일치하지 않음광범위한 IP 허용을 추가하는 것은 해결책이 아니다. 클라이언트가 Firewall Proxy를 사용하게 구성하여 두 관찰값이 같은 이름 확인 경로를 공유하도록 한다.
Microsoft 문서에 따르면 Azure Firewall은 네트워크 규칙의 FQDN-IP 매핑을 15초마다 새로 확인한다. 이름 확인 결과가 바뀌면 새 주소를 추가하고, 더 이상 반환되지 않는 이전 주소는 15분 뒤 만료한다. 네트워크 규칙 FQDN은 와일드카드를 지원하지 않는다. 따라서 호스트 이름이 안정적으로 보여도 여러 A 레코드, 지리적으로 분산된 응답, 짧은 TTL과 Resolver 위치가 테스트에 영향을 줄 수 있다.
지원되는 HTTP/S와 MSSQL 시나리오에서 애플리케이션 규칙은 다르게 작동한다. 호스트 헤더 또는 SNI 같은 애플리케이션 계층 정보를 사용하며 같은 IP를 공유하는 이름도 구분할 수 있다. 상세 규칙 선택은 다음 글에서 다룬다. 여기서 기억할 경로 원칙은 더 좁다.
FQDN 네트워크 규칙에서는 같은 시점에 클라이언트의 Resolver, Firewall의 상위 DNS, 반환된 IP 집합과 실제 선택된 IP로 향하는 경로를 증명해야 한다.
19. 0.0.0.0/0을 의도적으로 또는 우연히 우회하는 경로 목록화하기
기본 UDR은 유용하지만 “모든 것을 검사한다”는 보장은 아니다.
| 우회 유형 | 기본 UDR보다 우선하거나 피하는 이유 | 안전한 처리 방식 |
|---|---|---|
| 허브 피어링 경로 | 허브 접두사가 0.0.0.0/0보다 구체적임 | Firewall 사설 다음 홉과 DNS Resolver에 도달하기 위해 필요한 경로 |
| 새로운 직접 스포크 피어링 | 원격 스포크 접두사가 기본 경로보다 구체적임 | 같은 접두사의 Firewall UDR을 추가하거나 직접 우회를 수용하고 문서화 |
| Virtual Network 서비스 엔드포인트 | 플랫폼 서비스 경로에 특별한 우선순위가 있으며 UDR로 재정의할 수 없음 | 우회를 기록하고, 검사가 필수라면 엔드포인트 정책 또는 다른 액세스 설계 사용 |
| 프라이빗 엔드포인트 | 유효한 /32 InterfaceEndpoint 시스템 경로는 최장 접두사 일치에 따라 더 넓은 UDR보다 우선 | 먼저 출발지 NIC에 /32가 존재하는지 확인하고 직접 액세스를 수용하거나 지원되는 검사 구성 |
| 로컬 VNet 목적지 | VNet 시스템 접두사가 더 구체적임 | NSG, 지원되는 엔드포인트 정책 또는 의도적으로 라우팅한 토폴로지에 통제 경계 배치 |
| DNS 응답이 공용에서 사설로 변경 | 이제 데이터 연결이 다른 경로 유형과 일치함 | 이름 확인 뒤 경로 선택을 테스트하며, 사설 DNS가 Firewall 검사를 뜻하지 않음을 확인 |
프라이빗 엔드포인트는 특별히 주의해야 한다. 기본적으로 프라이빗 엔드포인트가 배치된 서브넷에서는 네트워크 정책이 비활성화된다. 적용 가능한 네트워크 도달성이 있는 출발지에는 Azure가 엔드포인트를 /32 InterfaceEndpoint 경로로 표시할 수 있다. 그 /32가 출발지 NIC의 유효 경로에 실제로 나타나면, 0.0.0.0/0 또는 10.0.0.0/8 UDR이 사용자 정의라는 이유만으로 이를 재정의할 수 없다. 모든 출발지가 그 경로를 받는다고 가정하지 않는다. 이 고정 토폴로지에서 애플리케이션과 데이터는 직접 피어링이 없으므로 애플리케이션 NIC의 유효 경로가 판단 근거다.
승인된 아키텍처에서 프라이빗 엔드포인트 트래픽이 반드시 Firewall을 통과해야 한다면 프라이빗 엔드포인트가 있는 서브넷에서 해당 경로 테이블 네트워크 정책을 활성화하고, VNet 주소 공간보다 넓지 않은 접두사를 사용하는 지원되는 UDR을 구성한다. /16 VNet이라면 사용할 수 있는 접두사 길이는 /16부터 /32이며 0.0.0.0/0은 해당하지 않는다. Firewall을 가리키는 명시적인 /32 경로가 가장 좁고 명확한 예다. 그런 다음 양방향, 엔드포인트 서비스의 지원 경계, NSG와 유효 경로를 검증한다. 엔드포인트 주소가 바뀔 때 누가 경로를 갱신할지 결정하기 전에 /32 경로를 대량 배포하지 않는다.
UDR만으로 실제 사용 가능한 검사 연결이 보장되는 것은 아니다. Microsoft는 애플리케이션 규칙 트래픽이 항상 SNAT되어 Firewall로 반환되므로 프라이빗 엔드포인트 검사에 Azure Firewall 애플리케이션 규칙을 권장한다. 대신 Azure Firewall 네트워크 규칙 또는 다른 NVA를 사용한다면 프라이빗 엔드포인트 응답이 비대칭 직접 경로로 빠지지 않도록 명시적인 SNAT을 구성한다. 검증할 때 변환된 출발지와 양쪽 유효 경로를 증명한다.
우회 목록은 반드시 남겨야 할 산출물이다.
목적지 또는 서비스
+ 선택된 유효 경로
+ 의도된 우회인가? 예/아니요
+ 보완 통제
+ 담당자와 검토 날짜
+ 성공·거부 증적20. Management NIC와 실제 강제 터널링 구분하기
Management NIC 기능은 원래 강제 터널링과 결합되어 있었지만 지금은 별도의 기능이다. 이를 활성화하면 보호된 플랫폼 관리 경로가 생기지만 테넌트 인터넷 트래픽의 출구를 자동으로 바꾸지는 않는다.
| 상태 | Management NIC | 데이터 경로 기본 경로 | 결과 |
|---|---|---|---|
| 이 글의 기본 구성 | 활성화 | Firewall의 일반적인 직접 인터넷 경로 | 관리 경로와 테넌트 데이터 경로가 분리됨, 강제 터널링 아님 |
| 실제 강제 터널링 | 활성화 | VPN 게이트웨이 또는 NVA를 가리키는 UDR, 또는 ExpressRoute에서 BGP로 학습한 기본 경로 | Firewall이 검사한 인터넷 트래픽이 온프레미스 또는 다른 승인된 에지로 나감 |
| 분할 경로 | 활성화 | 특정 접두사는 온프레미스로, 나머지 인터넷 목적지는 직접 경로 사용 | 각 예외에 명시적인 경로와 SNAT 레코드 필요 |
관리 경로는 의도적으로 제한된다.
AzureFirewallManagementSubnet
→ 관리 공용 IP
→ Azure 플랫폼 작업을 위한 인터넷
허용되는 경로 모델:
0.0.0.0/0 → Internet
게이트웨이 경로 전파 비활성화Microsoft는 AzureFirewallManagementSubnet에 고객 경로 테이블을 두지 않도록 권고한다. 연결해야 한다면 허용되는 유일한 경로는 기본 인터넷 경로이며 게이트웨이 전파도 계속 비활성화해야 한다. 관리 공용 IP는 고객 인그레스가 아니라 Azure 플랫폼용이다.
실제 강제 터널링은 테넌트 경로를 바꾼다.
스포크 워크로드
→ 스포크 UDR → Azure Firewall 데이터 경로
→ Firewall 정책
→ AzureFirewallSubnet 기본 경로
→ UDR을 통한 VPN 게이트웨이/NVA 또는 BGP로 학습한 ExpressRoute 기본 경로
→ 온프레미스 보안 에지
→ 인터넷다음 홉 방식은 게이트웨이 종류에 따라 달라진다. Virtual network gateway 다음 홉을 사용하는 0.0.0.0/0 UDR은 VPN 게이트웨이를 대상으로 할 수 있다. Azure는 해당 UDR 다음 홉 유형으로 ExpressRoute 게이트웨이에 트래픽을 강제 전송하는 방식을 지원하지 않는다. ExpressRoute에서는 기본 경로를 BGP로 광고하고 학습하거나, 승인된 NVA를 가상 어플라이언스로 지정한 UDR을 사용해야 한다.
온프레미스 에지는 Azure 출발지 범위를 알고 필요한 인터넷 송신을 수행하며 동일한 경로로 흐름을 반환해야 한다. 사설 범위 동작을 의도적으로 변경하지 않았다면 Azure Firewall은 강제 터널링된 인터넷 트래픽을 Firewall 사설 주소로 SNAT할 수 있다. 에지가 원래 워크로드 IP를 받는다고 가정하지 말고 실제 관찰값을 증명한다.
Microsoft의 현재 알려진 문제 지침에 따르면 실제 강제 터널링에서는 공용 인터넷 DNAT가 지원되지 않는다. 연결 상태를 보지 못한 온프레미스 장치를 통해 반환될 수 있기 때문이다. Management NIC를 활성화했다고 이 데이터 경로 제한을 무시할 수 있는 것은 아니다. Microsoft가 대상 구성을 명확히 지원한다고 확인하기 전까지 직접 인그레스 DNAT 예제와 강제 인터넷 송신 예제를 별개의 검증된 아키텍처로 유지한다.
NAT Gateway는 선택된 인터넷 다음 홉을 따른다
NAT Gateway는 UDR 다음 홉 유형이 아니다. 선택된 경로가 Internet 다음 홉을 사용할 때 아웃바운드 SNAT을 수행한다. 따라서 다음과 같이 동작한다.
- 워크로드의
0.0.0.0/0 → Virtual appliance 10.0.0.4경로는 워크로드 서브넷에만 연결된 NAT Gateway를 우회한다. - 직접 송신 Firewall은 Firewall의 선택된 아웃바운드 다음 홉이 여전히 Internet이므로 지원되는 구성에서
AzureFirewallSubnet의 NAT Gateway를 사용할 수 있다. - Firewall의
0.0.0.0/0 → Virtual network gateway/NVA강제 경로는 NAT Gateway를 우회한다.
기억할 원칙은 “NAT Gateway를 연결했으니 주소를 변환한다”가 아니다. “먼저 선택된 다음 홉을 확인하며, NAT Gateway는 인터넷 경로에서만 참여한다”다.
21. 증상과 가장 먼저 확인할 계층 연결하기
문제를 해결할 때 DNS, UDR, NSG와 Firewall 정책을 한꺼번에 바꾸지 말고 실패한 영역의 범위를 좁혀야 한다.
| 증상 | 가능성이 높은 계층 | 가장 먼저 볼 만한 증적 |
|---|---|---|
| 클라이언트가 모든 이름 확인에서 시간 초과 | 클라이언트 DNS, 포트 53, Proxy 또는 상위 DNS | 게스트 내부에 표시되는 Resolver, TCP/UDP 53 도달성, Proxy와 상위 DNS 상태 |
공용 이름은 동작하지만 사설 이름이 NXDOMAIN 반환 | 프라이빗 영역 공개 범위 또는 전달 규칙 | 사용된 상위 DNS, 영역 연결, Resolver 규칙 세트 연결, 권한 있는 레코드 |
| 클라이언트와 Firewall이 같은 FQDN을 다르게 확인 | 클라이언트의 Proxy 우회, 지역별 응답, 캐시 또는 상위 DNS 불일치 | 클라이언트 경로와 Firewall 상위 DNS의 타임스탬프가 있는 응답 |
| 주소 변경 후 FQDN 네트워크 규칙이 간헐적으로 동작 | DNS TTL, 15초 새로 고침, 15분 이전 주소 만료 또는 여러 A 레코드 | 기억에 의존한 IP 하나가 아닌 전체 응답 집합과 타임스탬프 |
| 애플리케이션은 성공하지만 Firewall 이벤트가 없음 | 더 구체적인 경로, 직접 피어링, 서비스 엔드포인트, 프라이빗 엔드포인트 또는 진단 누락 | 확인된 목적지에 대한 유효 경로와 진단 설정 |
| 애플리케이션-데이터 SYN은 도착하지만 연결 시간 초과 | 반환 UDR, 전달 트래픽 설정, NSG 또는 게스트 리스너 누락 | 애플리케이션 접두사에 대한 데이터 NIC 경로와 백엔드 리스너 증적 |
| Azure-온프레미스는 동작하지만 온프레미스가 시작한 반환은 실패 | GatewaySubnet 경로 또는 온프레미스 접두사 광고 | 온프레미스 에지와 GatewaySubnet의 정확한 경로 |
| Firewall 공용 IP가 파트너 연결을 받지 않음 | DNAT 일치, 출발지 접두사, 포트, 강제 터널링 모드, 백엔드 경로 | NAT 의도, 출발지 테스트 주소, Firewall 모드, 백엔드 리스너 |
| 백엔드에 공용 클라이언트 IP 대신 Firewall 사설 IP가 보임 | 예상된 인바운드 DNAT 출발지 SNAT | 주소 변환 설계, 원본 웹 클라이언트 식별이 필수라면 애플리케이션 Proxy 사용 |
| 스포크 VM이 Firewall 공용 IP 자체의 DNAT 백엔드에 도달하지 못함 | 지원되지 않는 헤어핀 패턴 | 내부 목적지와 Firewall의 알려진 제한 사항 비교 |
| NAT Gateway 공용 IP가 전혀 보이지 않음 | 선택된 경로가 Internet이 아니라 가상 어플라이언스 또는 게이트웨이 | 송신 담당 구성요소의 유효 다음 홉 |
| 프라이빗 엔드포인트가 사설로 확인되지만 Firewall 우회 | /32 InterfaceEndpoint 경로와 비활성화된 엔드포인트 네트워크 정책 | 출발지 유효 경로와 프라이빗 엔드포인트 서브넷 정책 |
| 강제 터널링 작업 후 상태, 로그 또는 업데이트가 사라짐 | 관리 서브넷 또는 플랫폼 DNS 경로가 변경됨 | Management NIC 상태, 관리 경로, DNS 재정의 목록 |
| Firewall 재시작 후 모든 스포크 경로 실패 | 할당 해제·재할당 뒤 Firewall 사설 IP 변경 | 현재 사설 IP와 UDR·VNet DNS 설정 비교 |
Firewall 로그가 없다는 사실에는 구분해야 할 두 가지 의미가 있다. 트래픽이 Firewall에 도달하지 않았거나, 진단 전달이 구성되지 않았거나 정상 동작하지 않을 수 있다. 경로와 원격 분석 파이프라인을 각각 독립적으로 증명한다.
22. 정해진 순서로 진단하고 검증하기
성공한 테스트와 실패한 테스트에 같은 순서를 사용한다.
- 출발지 IP, 요청한 FQDN, 확인된 목적지 IP, 프로토콜, 포트, 방향과 정확한 UTC 타임스탬프를 기록한다.
- 클라이언트가 실제 사용한 DNS 서버를 확인하고 전체 응답 집합과 TTL을 캡처한다.
- 호스트 이름만 사용하지 말고 확인된 목적지 IP로 Network Watcher 다음 홉을 실행한다.
- 출발지 NIC의 유효 경로를 내보내고 정확히 일치한 접두사, 경로 원본, 다음 홉 유형과 다음 홉 주소를 식별한다.
- 피어링 상태, 전달 트래픽 설정과 게이트웨이 설정을 검증한다.
- 출발지와 목적지의 유효 NSG 규칙을 검토하되 Firewall 정책과 혼동하지 않는다.
- Azure Firewall 상태, 사설 IP, 적용된 정책, DNS 설정과 진단 전달을 확인한다.
- 테스트 타임스탬프에 해당하는 예상 Firewall 판단 또는 NAT 이벤트를 찾는다.
- 목적지 리스너와 게스트 방화벽을 독립적으로 증명한다.
- 목적지 측 또는
GatewaySubnet반환 경로를 내보내고 동일한 Firewall을 통과하는지 증명한다. - 목적지가 관찰한 출발지 주소를 계획한 SNAT 동작과 비교한다.
- 성공을 선언하기 전에 인접 거부 테스트와 우회 테스트를 실행한다.
Network Watcher 연결 문제 해결(Connection Troubleshoot)은 라우팅, 필터링과 게스트 내부 원인을 구분하는 데 도움이 된다. 다음 홉은 선택된 Azure 다음 홉 유형과 경로 테이블 ID를 식별한다. 유효 경로는 시스템, 피어링, BGP와 UDR이 결합된 상태를 보여준다. 이 중 어떤 것도 단독으로 Firewall 정책 판단을 증명하지 못하므로 일치하는 Firewall 증적도 함께 보존한다.
최소 검증 행렬
| 테스트 | 예상 DNS 결과 | 예상 다음 홉 | 예상 결과 | 필수 증적 |
|---|---|---|---|---|
| 공용 DNS 성공 | Firewall Proxy를 통한 공용 IPv4 | 쿼리는 Proxy, 데이터는 Firewall | 이름 확인 성공 | 클라이언트 DNS 서버, 응답, TTL |
| 사설 DNS 성공 | 10.20.1.4 | 쿼리는 Proxy | 이름 확인 성공 | 영역·상위 DNS와 클라이언트 응답 |
| 사설 DNS 실패 | NXDOMAIN | 쿼리는 Proxy | 데이터 흐름 없음 | 부정 캐시를 고려한 쿼리 결과 |
| 아웃바운드 허용 | 승인된 공급업체 IP | VirtualAppliance 10.0.0.4 | 연결 성공 | 유효 경로, 허용 이벤트, 송신 IP |
| 아웃바운드 거부 | 유사하지만 승인되지 않은 이름 | 동일한 Firewall 다음 홉 | 거부 | 유효 경로와 거부 이벤트 |
| 워크로드 간 허용 | 10.20.1.4 | 양방향 모두 Firewall | 연결 성공 | 양쪽 NIC 경로, 허용, 리스너 응답 |
| 워크로드 간 거부 | 포트 9444의 10.20.1.4 | 동일한 Firewall 경로 | 거부 | 양쪽 경로와 거부 이벤트 |
| 하이브리드 허용 | 172.20.10.20 | Firewall 다음 게이트웨이 | 연결 성공 | 애플리케이션, Firewall, 게이트웨이, 온프레미스 경로 |
| 인바운드 파트너 허용 | 데이터 공용 IP | Firewall DNAT | 연결 성공 | 출발지 제한, NAT 이벤트, 백엔드 응답 |
| 인접 인바운드 거부 | 데이터 공용 IP | Firewall | 거부 | 일치하는 DNAT 없음과 타임스탬프 증적 |
| 직접 인터넷 우회 | 공용 테스트 주소 | 스포크에서 Internet이면 안 됨 | 우회 시도로 실패 | 다음 홉과 유효 경로 |
| 프라이빗 엔드포인트 경로 | 사설 /32 | 승인된 직접 엔드포인트 또는 Firewall | 설계와 일치 | 엔드포인트 정책과 유효 경로 |
경로 테이블을 넓은 범위에 연결하기 전에 카나리 테스트를 실행한다. 롤백은 이전 경로 연결과 이전 DNS 설정을 모두 복구해야 한다. 클라이언트가 사용할 수 없는 Proxy를 계속 가리키는 상태에서 UDR만 되돌리면 불완전한 롤백이다.
23. 체크리스트, 자가 점검과 기억 카드로 마무리하기
아키텍처 및 배포 체크리스트
- Standard, IPv4, 단일 리전, 고객 관리형 허브 가정을 기록했다.
- 허브, 두 스포크와 온프레미스 접두사가 서로 겹치지 않는다.
-
AzureFirewallSubnet이 정확한 이름과 최소/26을 사용한다. - Management NIC를 활성화했다면
AzureFirewallManagementSubnet이 정확한 이름과 최소/26을 사용한다. - Private Resolver 엔드포인트가 최소
/28인 서로 다른 전용 서브넷을 사용한다. -
GatewaySubnet에0.0.0.0/0UDR이 없다. - 배포 후 Firewall 사설·공용 주소를 기록했다.
- 피어링이 필요한 전달 트래픽을 허용한다.
- 직접 스포크 피어링이 없거나 그 우회를 명시적으로 수용했다.
- 경로 테이블은 의도한 서브넷에만 연결했다.
- 필요한 모든 사설 흐름에 반환 경로가 있다.
- 경로 정의뿐 아니라 유효 경로도 내보냈다.
DNS 및 우회 체크리스트
- 워크로드 클라이언트가 실제로 Firewall 사설 IP를 DNS 서버로 사용한다.
- VNet DNS 변경 후 기존 VM을 재시작하거나 갱신했다.
- 실제 적용된 정책 또는 리소스에서 Firewall DNS Proxy를 활성화했다.
- UDP와 TCP 53으로 상위 DNS에 도달할 수 있다.
- 모든 상위 DNS 실패 시 동작을 수용했으며 숨겨진 Azure DNS 대체 동작을 가정하지 않는다.
- 상위 DNS가 필요한 공용, 사설과 사내 네임스페이스를 확인할 수 있다.
- 어떤 전달 규칙도 쿼리를 Proxy 루프로 돌려보내지 않는다.
- 상속 문제가 남아 있는 동안 자식 정책 DNS를 직접 구성하고 검증했다.
- Microsoft 소유의 넓은 기본 DNS 영역을 Firewall 허브에 연결하지 않았다.
- FQDN 네트워크 규칙 테스트에서 응답 집합과 타임스탬프를 보존한다.
- 서비스 엔드포인트와 프라이빗 엔드포인트 경로를 우회 목록에 기록했다.
- 프라이빗 엔드포인트 네트워크 정책과 UDR 동작이 승인된 검사 결정과 일치한다.
운영 및 전환 체크리스트
- 트래픽 전환 전에 진단 전달이 정상이다.
- 넓은 범위에 연결하기 전에 카나리 서브넷 하나를 테스트했다.
- 허용과 인접 거부 테스트가 의도한 동일 경로를 따른다.
- 아웃바운드, 워크로드 간 내부, 하이브리드와 인바운드 반환 경로에 각각 별도의 증적이 있다.
- NAT 예상 결과가 각 목적지의 관찰값과 일치한다.
- Management NIC를 활성화된 강제 터널링으로 잘못 표시하지 않았다.
- 실제 강제 터널링 설계에서 관리 서브넷의 인터넷 경로를 보존했다.
- 실제 강제 터널링 경로에 공용 인터넷 DNAT를 약속하지 않는다.
- NAT Gateway의 참여 여부는 선택된 인터넷 다음 홉을 근거로 한다.
- Firewall 할당 해제·재할당 절차에서 사설 IP 경로와 DNS 드리프트를 확인한다.
- 롤백이 경로 연결과 클라이언트 DNS 설정을 모두 복구한다.
- 피어링, BGP, 엔드포인트, DNS와 경로에 담당자와 재평가 조건이 있다.
자가 점검 질문
- 정상인 Azure Firewall에 올바른 규칙이 있어도 워크로드 트래픽을 전혀 처리하지 않을 수 있는 이유는 무엇인가?
- VNet 피어링은 무엇을 제공하며 왜 전이 라우팅을 제공하지 않는가?
- Azure는 왜 UDR·BGP·시스템이라는 경로 원본의 우선순위보다 접두사 길이를 먼저 비교하는가?
- 직접 스포크 피어링이
0.0.0.0/0Firewall UDR을 우회할 수 있는 이유는 무엇인가? - Firewall 사설 IP로 가는 허브 피어링 경로가 필요한 예외인 이유는 무엇인가?
- VM이 실제로 선택한 경로를 증명하는 경로 증적은 무엇인가?
- 사설 워크로드 간 트래픽에 두 스포크의 경로가 모두 필요한 이유는 무엇인가?
GatewaySubnet이 기본 UDR 대신 정확한 스포크 경로를 사용해야 하는 이유는 무엇인가?- Firewall DNS Proxy와 Azure DNS Private Resolver가 같은 구성요소가 아닌 이유는 무엇인가?
- 구성된 사용자 지정 상위 DNS를 모두 사용할 수 없게 되면 어떻게 되는가?
- 연결된 Private DNS 영역이 DNS Proxy를 사용하는 하위 클라이언트에 응답하지 못할 수 있는 이유는 무엇인가?
- 클라이언트와 Firewall이 서로 다른 DNS 서버를 사용하면 FQDN 네트워크 규칙이 실패할 수 있는 이유는 무엇인가?
- 서비스 엔드포인트와 프라이빗 엔드포인트 경로는 어떻게 넓은 기본 UDR을 우회하는가?
- 지원되는 UDR이 프라이빗 엔드포인트 라우팅을 재정의하려면 먼저 무엇을 활성화해야 하는가?
- Management NIC 활성화가 실제 강제 터널링을 만들지 않는 이유는 무엇인가?
- NAT Gateway는 어느 경우에 경로 선택과 SNAT에 참여하는가?
- DNAT 백엔드에 일반적으로 Firewall 사설 출발지 주소가 보이는 이유는 무엇인가?
- 경로와 DNS를 함께 전환한 뒤 롤백할 때 복구해야 하는 두 설정은 무엇인가?
1분 기억 카드
이름 → 정방향 경로 → 정책 → NAT → 반환 경로 → 증적
DNS는 클라이언트에 사용할 IP를 알려 준다.
최장 접두사는 경로 원본 우선순위보다 먼저 경로를 선택한다.
피어링은 도달성을 제공하지만 자동 전이는 제공하지 않는다.
트래픽이 Firewall에 도달해야 Firewall 규칙이 의미가 있다.
사설 트래픽에는 명시적인 대칭 반환 경로가 필요하다.
DNS Proxy는 클라이언트와 Firewall의 FQDN 해석을 일치시킨다.
서비스 엔드포인트와 프라이빗 엔드포인트 경로는 기본 UDR을 우회할 수 있다.
Management NIC ≠ 강제 터널링.
NAT Gateway는 선택된 다음 홉이 Internet일 때만 참여한다.
경로 정의 ≠ 유효 경로.
연결 성공 ≠ Firewall 경로 증명.
로그 없음 ≠ Firewall 거부 확인.마지막으로 기억할 문장은 다음과 같다.
Firewall 규칙을 더 작성하기 전에 실제 연결 하나에 대해 확인된 주소, 선택된 경로, Firewall 판단, 주소 변환과 반환 경로를 허용과 거부 두 경우 모두 증명한다.
다음 예정 모듈 1 글인 azure-firewall-rules-logging-validation에서는 규칙 컬렉션, 구조화된 로깅, 쿼리와 반복 가능한 검증 명령을 구현한다. 완성된 영어·한국어 글 한 쌍이 준비되기 전까지는 일반 텍스트로만 남겨 두며 빈 경로를 연결하지 않는다.
참고 자료
- Coursera: Azure Cybersecurity Solutions and Microsoft Defender
- Microsoft Learn: Azure Firewall과 트래픽 검사
- Microsoft Learn: Azure 포털을 사용해 Azure Firewall 배포 및 구성
- Microsoft Learn: 허브-스포크 네트워크 토폴로지
- Microsoft Learn: Azure Virtual Network와 서브넷
- Microsoft Learn: Azure Virtual Network 트래픽 라우팅
- Microsoft Learn: 경로 테이블로 네트워크 트래픽 라우팅
- Microsoft Learn: Virtual Network 피어링
- Microsoft Learn: 가상 머신 라우팅 문제 진단
- Microsoft Learn: Network Watcher 다음 홉
- Microsoft Learn: Network Watcher 연결 문제 해결
- Microsoft Learn: Azure Firewall DNS 설정
- Microsoft Learn: Azure Firewall DNS Proxy 상세 정보
- Microsoft Learn: Azure Firewall 네트워크 규칙의 FQDN 필터링
- Microsoft Learn: Azure DNS Private Resolver 아키텍처
- Microsoft Learn: Azure DNS Private Resolver 엔드포인트와 규칙 세트
- Microsoft Learn: 허브-스포크 네트워크의 Azure DNS Private Resolver
- Microsoft Learn: Azure Private DNS란?
- Microsoft Learn: Azure Private Endpoint DNS 통합
- Microsoft Learn: Private Endpoint의 네트워크 정책 관리
- Microsoft Learn: Private Endpoint 연결 문제 해결
- Microsoft Learn: Azure Firewall로 Private Endpoint 트래픽 검사
- Microsoft Learn: Azure Virtual Network 서비스 엔드포인트
- Microsoft Learn: Azure Firewall 강제 터널링
- Microsoft Learn: Azure Firewall Management NIC
- Microsoft Learn: Azure Firewall 목적지 NAT 규칙
- Microsoft Learn: Azure Firewall SNAT 사설 IP 주소 범위
- Microsoft Learn: Azure Firewall 알려진 문제와 제한
- Microsoft Learn: Azure Firewall 모니터링
- Microsoft Learn: Azure NAT Gateway로 가상 네트워크 설계
- Microsoft Learn: Azure Firewall과 NAT Gateway 통합
- Microsoft Learn: Azure 기본 아웃바운드 액세스
시리즈
Azure 사이버 보안 및 Microsoft Defender 수강 노트
전체 11편 중 8편입니다. 관련 구축 기록을 순서대로 모아 전체 맥락을 쉽게 확인할 수 있습니다.
- 1. 모듈 1 복습: Azure 기본 보안 기능
- 2. Azure Defense in Depth: 한 계층이 실패해도 작동하는 보안 설계
- 3. Azure 기본 DDoS 인프라 보호의 실제 범위: 자동 보호와 고객 책임 구분
- 4. Azure DDoS IP Protection과 Network Protection 비교: 범위·운영·비용으로 선택하기
- 5. Public IP 없이 Azure VM을 안전하게 설계하기: 관리·인바운드·아웃바운드 경로 분리
- 6. Azure VNet·Subnet·NSG 기초: 주소 계획부터 트래픽 규칙 검증까지
- 7. Azure Firewall Basic·Standard·Premium 비교: 트래픽·검사·운영 요구로 선택하기
- 8. Azure Firewall UDR·DNS 설계: 규칙보다 먼저 트래픽 경로 증명하기
- 9. 모듈 2 복습: Azure 보안 관리
- 10. 모듈 3 복습: Microsoft Defender 위협 신호를 하나의 사건으로 연결하기
- 11. 모듈 4 복습: 계층형 Azure VM 보안을 설계하고 증명하는 방법
