Azure サイト間 VPN トラフィックで NSG を適用する場所

サイト間トンネルは稼働しており、オンプレミスのクライアントは一部の Azure ホストには到達しますが、別のホストには到達しません。そこで GatewaySubnet にネットワーク セキュリティ グループを付けた人がいます。そこは止めてください。Azure は GatewaySubnet 上の NSG をサポートせず、そのグループはワークロードの規則のように内側のパケットを見ることはできません。ポリシーは宛先サブネットまたは NIC に置き、復号後に存在する送信元アドレスを一致させ、古い接続ではなく新しい接続で確認してください。

Azure が評価する場所に NSG を置く

ワークロードのフィルター処理でサポートされる境界は、宛先サブネットまたは宛先ネットワーク インターフェイスです。ゲートウェイ サブネットはインフラストラクチャであり、Azure はそこでの NSG がサポートされず、ゲートウェイの動作を損なう可能性があると文書化しています。

配置には論理的な問題もあります。GatewaySubnet の NSG は外側の IPsec 交換を評価しますが、そのアドレスは二つのゲートウェイのものです。アプリケーションの規則に必要なのはトンネル内側のプライベート送信元であり、そのパケットはゲートウェイが復号した後にのみ存在します。グループをワークロードのサブネットに付ければ、規則は意図したアドレスを見ます。

変更する前に現在の関連付けを確認し、何を移すのかを把握してください。

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

復号後の送信元アドレスを見つける

内側の送信元はオンプレミス クライアントのプライベート アドレス、またはアプライアンスや VPN の NAT が変換後に提示するアドレスです。オンプレミス VPN ゲートウェイのパブリック アドレスではありません。それは外側の交換に属します。

NAT が設計に含まれる場合は、想定せずに提示された送信元を確認してください。Azure VM でのパケット キャプチャ、またはサービスの接続ログの送信元フィールドが、オンプレミス構成を読むより速く結論を出します。その後、そのアドレスと実際の宛先ポートに対して規則を書きます。

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

公開するサービスごとに一つの規則を使い、ポート一覧は短く保ってください。オンプレミス範囲のすべてのポートを許可する規則は、NSG を形だけのものにします。

既定の VirtualNetwork スコープを確認する

VirtualNetwork サービス タグはローカルの仮想ネットワークより広い範囲です。その定義には接続されたオンプレミスのアドレス空間、ピアリングされたネットワーク、ゲートウェイ経由で接続された他のプレフィックスが含まれます。つまり VirtualNetwork に限定した既定の許可規則が、運用者が外部と見なしていたトンネル トラフィックをすでに許可している可能性があります。

狭い規則を追加する前に既定の規則を読み、先に一致し得る優先度の高い規則をすべて読んでください。明示的な許可を追加しても、すでにフローを許可している広い規則は削除されません。ポリシーが拒否を求める場合は、許可より前に実際に評価される優先度に置いてください。

Microsoft のサービス タグのドキュメントは VirtualNetwork タグが何を対象とするかを示しており、タグが VNet の範囲だけを意味すると主張するときに引用する資料です。

両方の境界で有効な規則を読む

サブネットの NSG と NIC の NSG の両方が適用される場合、フローは両方を満たす必要があります。片方の許可がもう片方の拒否を打ち消すことはなく、パケットが実際に直面するのは集約された見え方です。

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Azure Virtual Network Manager のセキュリティ管理者規則が関与する場合は、その層も確認してください。管理者の Always allow 規則は NSG の評価なしにトラフィックを届け、管理者の Deny は NSG が見る前に停止します。その構成では NSG だけの確認は不完全です。

NSG はステートフルです。規則を編集しても、既存の許可済み接続が必ず終了するわけではないため、受け入れテストには新しいフローが必要です。この性質は本番では有用で、変更作業中は誤解を招きます。

新しい接続で確認する

オンプレミス クライアントからサービスのポートへ新しいセッションを開き、拒否されるべきホストからも繰り返してください。VM 側からもフロー テストを実行し、戻り経路が健全であることを確認します。

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG の許可は一つのアクセス判断であり、ルートでもリスナーでもありません。規則がフローを許可しても接続が失敗する場合は、グループを再編集する前に クライアントの VPN へのルート、Azure の戻りルート、ホストのファイアウォールを確認してください。実際の送信元アドレス、NSG の関連付け、一致した規則を承認済みサービスとともに記録してください。次のピアリングやルートの変更で、VirtualNetwork タグの対象が変わる可能性があります。