Azure Firewall DNAT

運用前提: Portal上のresource stateだけでなく、対象5-tupleのeffective state・route・security logs・new connectionを組み合わせてdata planeを確認します。SKU/limit/preview statusは変更されるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

Azure Firewall DNATを理解するための前提

DNAT ruleはFirewall public IP/port宛のinboundをtranslated private IP/portへ変換する。 Firewall PolicyではDNATがNetwork/Applicationより先に処理され、DNAT matchはterminatingする。

DNAT ruleはtranslated trafficを許可する対応Network ruleを暗黙に追加するため、同じflowへ別Network Allowを重ねる前にprocessingを理解する。 Internet sourceを*で広く公開せず、可能な場合specific source prefixへ制限する。

Application rulesはinbound connectionsへ適用されない。HTTP/S公開でOWASP/L7 inspectionが必要ならWAFを前段/別設計で使う。 Azure Firewallはstatefulなのでreturn trafficを処理する。backend subnetへ誤った戻りUDRを追加してasymmetryを作らない。

通信や判断の流れを追う

SourceRouteNSG / PolicyWorkloadResponse

Control plane と data plane

Control planecontrol planeではpublic frontend IP/port、source、translated address/port、protocol、NAT collection priorityをPolicyで定義する。public IP ownershipとbackend lifecycleも変更管理対象。

Data planedata planeではInternet packetがFirewall public IPへ到達し、DNAT passでmatchするとdestinationを書き換え、stateを作りbackendへforwardする。responseは同じstate/NAT mappingで戻る。

仕組み

clientがFirewall public IP:portへ新規connectionを開始する。

DNAT RCG/collectionをpriority順に評価する。

matchしたruleでdestination IP/portをprivate backendへtranslateし、trafficをallowする。

backendまでroute/NSG/guest firewallを通過する。

responseはFirewallのstate/NAT mappingを通りclientへ戻る。

Packet / decision path

障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。

public exposure inventoryとowner/expiryをDNAT ruleに紐付ける。
sourceをspecific CIDR/service要件へ絞る。
backendはpublic IPを持たせず、必要なinbound pathをFirewall/WAFへ集約する。
HTTP/SはDNATだけでL7 securityを満たしたと判断しない。
return routeを変更するときはstateful symmetryを必ず検証する。

設計判断

判断点	推奨	理由
Exposure	DNATごとにexternal attack surfaceとして管理。	policy allowだけでなく公開port inventoryになる。
Source	管理系portは固定source/VPN/Bastion等を優先。	* sourceの恒久運用を避ける。
Web	L7要件はWAF/Front Door/Application Gatewayと組み合わせる。	DNATはL3/L4 publishing。
HA backend	translated destinationのavailability方式を別設計する。	Firewall HAとbackend HAは別。

確認手順

Azure Portal / Network Watcher

Firewall Policy → DNAT collectionsでsource/destination/translated address/portを確認。
Firewall public IPが意図したresourceへ関連付くか確認。
Network/Application/DNAT logsでincoming flowとtranslation結果を確認。
backend側NSGとguest firewall/listenerを確認。

Verification discipline

subscription / resource group / resource ID / NIC / direction / 5-tupleを記録する。
同じ条件でbefore/afterを比較し、既存sessionとnew connectionを区別する。
configuration、effective state、logs、application resultを別々の証拠として残す。
変更成功はcontrol-plane Succeededではなくobservable data-plane behaviorで判定する。

Azure CLI — read-only first

az network firewall show -g <rg> -n <firewall> -o jsonc
az network firewall policy rule-collection-group list -g <rg> --policy-name <policy> -o jsonc

PowerShell — read-only first

Get-AzFirewall -ResourceGroupName <rg> -Name <firewall>
Get-AzFirewallPolicy -ResourceGroupName <rg> -Name <policy>

障害切り分け

症状	疑う点	証拠	次の確認
public IPへ接続できない	DNAT no-match/public IP mismatch/upstream DDoS/WAF	DNAT logsとpublic IP association	frontend tupleを固定
DNAT hitするがbackend無応答	backend NSG/listener/route	backend packet pathとsocket	backend側を切り分け
return packetが落ちる	backend UDRでFirewallを迂回/asymmetry	effective route + flow log	return pathをstateful Firewallへ戻す
Web公開は通るが攻撃防御不足	DNATのみでL7 inspectionなし	architecture review	WAFを導入/適切なedgeへ移す

変更時の確認と rollback

DNAT rule削除前にpublic endpoint利用者とbackend dependencyを確認。
rollbackはfrontend tupleとtranslated tupleの両方を元へ戻し、external clientからnew connectionで確認する。