NIC / IP Configuration

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を基準に、設計と運用で判断が必要な点をpacket path中心に整理。SKU、region、limitsは変更されるため、実装時はOfficial sourcesのcurrent documentationを再確認してください。

NIC / IP Configurationを理解するための前提

Azure NICは1つのprimary IP configurationと複数のsecondary IP configurationを持てる。 private IPはAzure DHCPを通じてguest OSへ提供され、Azure側のNIC configurationがsource of truthになる。

Azure上でDynamic private IPでも、NICが存在する間は通常同じaddressが保持されるが、保証が必要ならStatic allocationを使う。 guest OSへ手動設定する場合、Azure NIC側のprivate IPと一致させないとconnectivityを失う。

NVAとしてtrafficをforwardするNICはAzureのEnable IP forwardingを有効にし、さらにguest OS/appliance側もforward可能にする。 effective routes / effective security rulesはNIC contextで確認するため、route/NSG障害の実態確認に向く。

通信や判断の流れを追う

利用側VNet / SubnetNIC / Azure service接続先

Control plane と data plane

Control planePortal / ARM / CLIで定義されたresource、association、route advertisement、peering flagなど。設定がSucceededでもpacket到達を保証しない。

Data plane実際のsource/destination/5-tupleが選ぶroute、NAT、security device、return path。Effective state、Next hop、logs、packet capture、application testで証明する。

仕組み

packetはVM process→guest network stack→NIC→Azure SDNへ出る。AzureはNIC IP configurationとsubnet contextを使ってsource/destinationを扱う。

secondary IPを使うapplicationではguest OS binding、Azure NIC IP config、Load Balancer/backend設定を同じaddressで整合させる。

NVAではEnable IP forwardingだけでrouterになるわけではない。Azure側source/destination checkを許容したうえで、OS forwarding/firewall/vendor policyがdata planeを転送する。

public IPはNIC IP config等へ関連付くfrontend identityであり、guest OSへpublic addressを直接設定するモデルではない。

Packet path

routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。

applicationがprimary/secondary private IPから送信。
guest OSがNICへframe/packetを渡す。
Azure SDNがNIC/subnetのeffective route/securityを適用。
必要ならNAT/LB/NVA等を通過。
return packetが同一flow/stateへ戻り、guest OSの正しいIP/interfaceへ配送。

設計判断

判断点	推奨	理由
IP allocation	固定allowlist/DNS dependencyがあるprivate IPだけStaticを検討。	不要なmanual固定を減らしAzure管理とguest設定のdriftを避ける。
Secondary IP	用途・owner・backend associationを明示。	IPだけ増やすとguest bindingやNSGの見落としが増える。
NVA forwarding	Azure IP forwarding + OS/appliance forwardingの両方を確認。	片側だけ有効でも転送は成立しない。
Troubleshooting	NICを起点にeffective route/NSGを取得。	subnet route tableだけを見るより実効状態へ早く到達する。

確認手順

Azure Portal

VM → Networking → Network interface → IP configurations を確認。
NIC → Effective routes / Effective security rulesを取得。
NVAならNIC設定のIP forwardingとvendor/OS forwardingを別々に確認。

Verification discipline

subscription / resource group / resource IDを記録する。
同じsource・destinationでbefore/afterを比較する。
read-only evidenceを保存してから変更する。
control-plane successとapplication successを別々に判定する。

Azure CLI — read-only first

az network nic show -g <rg> -n <nic> -o jsonc
az network nic ip-config list -g <rg> --nic-name <nic> -o table
az network nic show-effective-route-table -g <rg> -n <nic> -o table

PowerShell — read-only first

Get-AzNetworkInterface -ResourceGroupName <rg> -Name <nic> | Format-List *

障害切り分け

症状	疑う点	証拠	次の確認
IP変更後にVMへ入れない	guest OS static IPとAzure NIC不一致	NIC IP configとipconfig/ip addrを比較	Azure側をsource of truthとして一致させる
NVAへUDRしたがpacketが止まる	IP forwardingまたはOS forwarding無効	NIC EnableIPForwarding + appliance routing table	両層を有効化しvendor policy確認
secondary IP宛のみ不達	guest binding/backend pool/NSG漏れ	NIC IP configとlistener/socket	IP config→guest→LB順に確認
route table通りに見えない	NICに別subnet/peering/BGP routeが作用	effective route table	NIC contextでselected routeを確認

変更時の確認と rollback

IP変更前にNIC JSONとguest IP/routing tableを保存。
primary/secondary変更はLoad Balancer・DNS・allowlist・health probe dependencyを確認。
NVA NICのIP forwarding変更はtraffic drain/failover pathを準備。
rollback後にsource IPまで含めてpacket capture/flow logで戻ったことを確認。