【テクニカル・上級編】 Azure ExpressRoute環境下におけるUser Defined Routes (UDR)とNATの挙動 – クラウド＆コンテナネットワーク実践ガイド

承知いたしました。Azure ExpressRoute環境下におけるUser Defined Routes (UDR)とNATの挙動に焦点を当て、パケットレベルの内部挙動、パフォーマンス、セキュリティの観点から深く掘り下げた技術ブログ記事を執筆します。教科書的な説明ではなく、現場で培われた知見に基づき、人間味あふれる豊かな文脈で解説します。

—

Azure ExpressRoute 環境における UDR と NAT ゲートウェイの深淵：パケットはどこへ向かうのか？

メガクラウドの広大なネットワーク空間で、我々SREやインフラアーキテクトが日々格闘しているのは、単なるリソースの配置だけではない。パケットがどのように流れ、どこで最適化され、そしてどこに脆弱性が潜んでいるのか。今回は、Azure ExpressRouteという、オンプレミスとAzureを繋ぐ高速道路を利用する際に、しばしば悩みの種となる「User Defined Routes (UDR)」と「NAT Gateway」の挙動に、パケットレベルで深淵を覗き込んでみよう。特に、プライベートサブネットからインターネットへのトラフィックを、Azure FirewallやNAT Gatewayへと強制転送するシナリオに焦点を当てる。

なぜ、プライベートサブネットからのインターネットアクセスを制御する必要があるのか？

まず、なぜ我々がこんなにもプライベートサブネットからのインターネットアクセスにこだわるのか、その動機を明確にしておく必要がある。

セキュリティの強化: プライベートサブネットは、本来インターネットから直接アクセスされないように設計されている。しかし、インフラの運用や管理、あるいは特定のアプリケーション要件（例えば、外部APIへのアクセス）のために、インターネットへのアウトバウンド通信が必要になる場合がある。この際、直接インターネットに出てしまうと、予期せぬ脅威に晒されるリスクがある。Azure FirewallやNAT Gatewayを介することで、通信の可視化、脅威検出、そしてIPアドレスの統一といったセキュリティ対策を施すことができる。
IPアドレス管理: プライベートサブネットから直接インターネットへアクセスさせると、送信元IPアドレスは動的に変化し、外部サービスからのアクセス制御が困難になる。NAT Gatewayを利用することで、固定のパブリックIPアドレスでアウトバウンド通信を行うことができ、IPアドレスベースのホワイトリスト認証などが容易になる。
コンプライアンス要件: 一部のコンプライアンス基準では、アウトバウンド通信の制御や監視が義務付けられている。

ExpressRoute環境では、オンプレミスネットワークとの接続が確立されているため、Azure VNet内のサブネットは、デフォルトではAzureのルーティングテーブルに従って通信を行う。しかし、プライベートサブネットからインターネットへのトラフィックを意図したゲートウェイ（Azure FirewallやNAT Gateway）へ確実に誘導するためには、UDRの出番となる。

UDRの舞台裏：ルーティングテーブルの書き換えという名の魔法

UDR、すなわちUser Defined Routesは、Azure VNet内のルーティングテーブルに、管理者が定義したカスタムルートを追加する機能だ。これにより、デフォルトのシステムルートを上書きし、トラフィックの転送先を細かく制御できる。

ExpressRoute環境で、プライベートサブネット 10.0.1.0/24 からインターネット (0.0.0.0/0) へのトラフィックを、10.0.0.4 というIPアドレスを持つNAT Gatewayへ強制転送したい場合を考えてみよう。

まず、VNet内にNAT Gatewayをデプロイし、適切なパブリックIPアドレスを関連付ける。そして、NAT Gatewayが配置されているサブネット、あるいはトラフィックをルーティングしたいサブネットに、UDRを適用したルートテーブルをアタッチする。

ここで重要なのは、UDRで設定する「宛先」と「ネクストホップ」だ。

宛先: インターネット全体を指す 0.0.0.0/0 を指定する。
ネクストホップ: NAT GatewayのIPアドレスではなく、VirtualAppliance を指定する。そして、VirtualAppliance のネクストホップアドレスとして、Azure FirewallやNVA（Network Virtual Appliance）のプライベートIPアドレス（この例では10.0.0.4）を指定する。NAT Gateway自体は、このUDRのネクストホップとしては直接指定できない。NAT Gatewayは、そのアタッチされているサブネットのデフォルトゲートウェイとして機能し、そのサブネットのトラフィックを自動的に処理する。

UDR設定の具体例（Azure CLI）

以下に、Azure CLIを使ったUDRの設定例を示す。

まず、ルートテーブルを作成する。

# ルートテーブル名
ROUTE_TABLE_NAME="udr-for-internet-outbound"
# リソースグループ名
RESOURCE_GROUP_NAME="my-expressroute-rg"
# VNet名
VNET_NAME="my-vnet"
# NAT Gatewayが配置されているサブネット名
NAT_SUBNET_NAME="nat-subnet"
# Azure FirewallまたはNVAのプライベートIPアドレス
FIREWALL_PRIVATE_IP="10.0.0.4"
# UDRのルート名
ROUTE_NAME="to-nat-gateway"

# ルートテーブルの作成
az network route-table create \
  --name $ROUTE_TABLE_NAME \
  --resource-group $RESOURCE_GROUP_NAME

# ルートの追加 (インターネット向けトラフィックをVirtualApplianceへ)
az network route-table route create \
  --route-table-name $ROUTE_TABLE_NAME \
  --name $ROUTE_NAME \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address $FIREWALL_PRIVATE_IP

# 作成したルートテーブルをNAT Gatewayが配置されているサブネットにアタッチ
# まず、サブネットのリソースIDを取得
SUBNET_ID=$(az network vnet subnet show \
  --resource-group $RESOURCE_GROUP_NAME \
  --vnet-name $VNET_NAME \
  --name $NAT_SUBNET_NAME \
  --query id -o tsv)

# ルートテーブルをサブネットにアタッチ
az network vnet subnet update \
  --ids $SUBNET_ID \
  --route-table $ROUTE_TABLE_NAME

解説:

az network route-table create: 新しいルートテーブルを作成します。
az network route-table route create: 作成したルートテーブルに、具体的なルートを追加します。
--address-prefix 0.0.0.0/0: すべての宛先IPアドレス（インターネット）を対象とします。
--next-hop-type VirtualAppliance: 次のホップとして、仮想アプライアンス（Azure Firewallやサードパーティ製NVA）を指定します。
--next-hop-ip-address $FIREWALL_PRIVATE_IP: 仮想アプライアンスのプライベートIPアドレスを指定します。このIPアドレスを持つデバイスが、トラフィックをルーティングします。
az network vnet subnet update: 作成したルートテーブルを、トラフィックをルーティングさせたいサブネット（ここではNAT Gatewayが配置されているサブネット）にアタッチします。これにより、そのサブネット内のVMなどから発信されるトラフィックは、このカスタムルートに従って転送されます。

注意点:

VirtualAppliance のネクストホップIPアドレスには、Azure FirewallのプライベートIPアドレス、あるいはサードパーティ製のNVAのプライベートIPアドレスを指定します。NAT GatewayのパブリックIPアドレスや、NAT Gateway自体を直接指定することはできません。
NAT Gatewayは、そのアタッチされているサブネットのデフォルトゲートウェイとして機能するため、そのサブネットのトラフィックは自動的にNAT Gatewayへ流れます。しかし、UDRで VirtualAppliance を経由させることで、NAT Gatewayよりも前にAzure FirewallやNVAにトラフィックを到達させ、より詳細な制御やセキュリティチェックを行うことが可能になります。
ExpressRoute環境では、オンプレミスネットワークからのルート（BGP経由でアドバタイズされる）もVNetに影響を与えます。UDRは、これらのシステムルートよりも優先度が高いため、意図したルーティングを実現できます。

パケットはどこへ？：ExpressRoute、UDR、NAT Gateway、そしてAzure Firewallの連携

さて、ここからが本題。パケットは実際にどのように流れるのか、その軌跡を追ってみよう。

1. プライベートサブネットのVMからインターネットへパケット送信:
VM（例: 10.0.1.10）が、外部のWebサーバー（例: 8.8.8.8）へTCPコネクションを確立しようとします。パケットは、VMのローカルルーティングテーブルに従い、デフォルトゲートウェイ（通常はVNetのゲートウェイ）へと向かいます。

2. VNetルーティングテーブルの参照:
パケットは、VMが所属するサブネットにアタッチされたルートテーブルを参照します。このサブネットにUDRが適用されている場合、UDRのルートが最優先されます。

宛先 0.0.0.0/0 に対して、ネクストホップが VirtualAppliance (10.0.0.4) と定義されているUDRがヒットします。

3. Azure Firewall/NVAへの転送:
パケットは、VNet内のルーティングに従い、ネクストホップとして指定された 10.0.0.4（Azure FirewallまたはNVA）へ転送されます。この際、パケットの送信元IPアドレスはVMのプライベートIP (10.0.0.10) のままです。

4. Azure Firewall/NVAでの処理:
10.0.0.4 のAzure Firewall（またはNVA）は、受信したパケットを検査します。ここで、ファイアウォールルールに基づいて、通信の許可/拒否、ログ記録、脅威検出などが行われます。

5. NAT Gateway (またはAzure FirewallのDNAT/SNAT) による変換:

Azure Firewall の場合: Azure Firewall自体がSNAT（Source Network Address Translation）機能を持つため、ここで送信元IPアドレスがAzure FirewallのパブリックIPアドレスに変換され、インターネットへ向かいます。
NAT Gateway の場合: Azure Firewall（またはNVA）は、インターネットへの送信元IPアドレスを、NAT GatewayのパブリックIPアドレスに変換する必要があります。この変換は、UDRのネクストホップとして指定されたAzure Firewall/NVAが、さらにその先にNAT Gatewayを「知っている」必要があります。
正しい構成: NAT Gatewayは、特定のサブネット（例: nat-subnet）にデプロイされます。そして、このnat-subnetには、デフォルトゲートウェイとしてNAT Gatewayが自動的に設定されます。UDRで VirtualAppliance (10.0.0.4) を経由させた後、10.0.0.4 は、その先のパケットをnat-subnetのデフォルトゲートウェイ（つまりNAT Gateway）へルーティングします。NAT Gatewayが、最終的に送信元IPアドレスを自身のパブリックIPアドレスに変換してインターネットへ送信します。
UDRのネクストホップとしてNAT Gatewayを直接指定できない理由: NAT Gatewayは、VNet内のルーティングテーブルに直接ルートとして登録されるような「ルーター」ではなく、サブネットのデフォルトゲートウェイとして機能するサービスです。UDRのネクストホップは、ルーティングを処理するネットワークインターフェース（VirtualAppliance）を指す必要があります。

6. インターネットへの到達:
送信元IPアドレスがNAT GatewayのパブリックIPアドレスに変換されたパケットは、インターネットへ到達します。

7. 応答パケットの返送:
インターネット上のサーバーからの応答パケットは、NAT GatewayのパブリックIPアドレス宛に返送されます。

8. NAT Gatewayによる逆変換 (DNAT):
NAT Gatewayは、受信した応答パケットの宛先IPアドレス（自身のパブリックIPアドレス）を、対応するプライベートIPアドレス（VMの 10.0.1.10）に逆変換します。

9. Azure Firewall/NVAでの処理 (オプション):
必要に応じて、応答パケットもAzure Firewall/NVAで再度検査されます。

10. VMへの返送:
宛先IPアドレスがVMのプライベートIPアドレスに変換されたパケットは、VNet内のルーティングに従い、VMへ返送されます。

このように、UDRはパケットをAzure Firewall/NVAという「関門」へ誘導し、そこでセキュリティチェックやポリシー適用が行われた後、最終的にNAT Gatewayによって送信元IPアドレスが変換されてインターネットへ旅立っていきます。

パフォーマンスとセキュリティの極限追求：RTT、TLS、ヘッダー圧縮

ここまで、ルーティングの基本を解説してきましたが、SREやテックリードが真に求めるのは、この基盤の上でいかにパフォーマンスとセキュリティを最大化するか、という点です。

RTT（Round Trip Time）削減:

ExpressRouteの帯域幅とレイテンシは、オンプレミスとAzure間の通信に大きな影響を与えます。VNet内のルーティングも、ホップ数が増えればRTTは増加します。

Azure Firewall/NVAの配置: Azure FirewallやNVAは、VNetピアリングされたハブ＆スポークモデルのハブVNetに配置するのが一般的です。これにより、スポークVNetからのトラフィックはハブVNetを経由してインターネットへ向かいます。VNet内のホップ数を最小限に抑える設計が重要です。
ExpressRouteの最適化: BGPセッションの監視、適切なASパスの選定、ExpressRoute FastPathの活用（可能な場合）など、ExpressRoute自体を最適化することで、オンプレミスからAzureへの、そしてAzureからオンプレミスへの戻りのRTTも削減できます。
TCPバッファチューニング: LinuxカーネルにおけるTCPバッファサイズ（net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem）のチューニングは、高帯域幅・高レイテンシ環境でのスループット向上に不可欠です。Azure VMのOSレベルで、ワークロードの特性に合わせてこれらのパラメータを調整することで、TCPウィンドウが常に最大化され、効率的なデータ転送が可能になります。

トランスポート層セキュリティ (TLS/SSL) の最適化:

TLSハンドシェイクは、数回の往復通信を伴うため、レイテンシの影響を大きく受けます。

TLSセッション再開: クライアントとサーバーがTLSセッションIDを再利用することで、ハンドシェイクの回数を削減できます。これは、アプリケーションレベルでの実装や、ロードバランサー/API Gatewayでのセッション管理機能に依存します。
TLS 1.3: TLS 1.3は、TLS 1.2に比べてハンドシェイクが1-RTTに短縮されるなど、パフォーマンスが大幅に向上しています。可能な限りTLS 1.3を利用するように構成することが推奨されます。
証明書管理: 証明書の検証プロセスもレイテンシに影響します。証明書失効リスト（CRL）やOnline Certificate Status Protocol (OCSP) の応答時間を最適化するために、CDNsを利用したり、ローカルキャッシュを効果的に利用したりする戦略も考慮します。

ヘッダー圧縮アルゴリズム:

HTTP/2やQUIC（HTTP/3）では、ヘッダー圧縮が標準で利用されます。

HPACK (HTTP/2): 静的および動的なテーブルを用いてヘッダーを効率的に圧縮します。これにより、TCPペイロードのサイズが削減され、レイテンシの影響を受けにくくなります。
QPACK (HTTP/3): QUIC上で動作するHTTP/3では、HPACKをベースとしたQPACKが使用されます。

これらのプロトコルをサポートするロードバランサーやアプリケーションゲートウェイ、そしてアプリケーション自体を利用することで、ネットワーク帯域幅の効率化とパフォーマンス向上に繋がります。

重大なネットワーク脆弱性の回避策:
TCP SYN Flood/ACK Flood: Azure FirewallやWAF（Web Application Firewall）は、これらのDoS攻撃に対する軽減策を提供します。UDRでトラフィックをこれらのセキュリティサービスに強制転送することで、攻撃の影響を最小限に抑えることができます。
IPフラグメンテーション攻撃: Azure Firewallは、IPフラグメントパケットの再構築と検査を行うことで、フラグメンテーションを利用した攻撃から保護します。
不正なパケットのフィルタリング: UDRとAzure Firewall/NVAを組み合わせることで、期待されるプロトコルやポート以外からの通信をブロックし、攻撃対象領域を縮小します。

BGPプレフィックスアドバタイズメントの制御

ExpressRoute環境では、オンプレミスネットワークからのプレフィックスがBGP経由でAzure VNetにアドバタイズされます。この制御も、ルーティング戦略において重要です。

BGPコミュニティ値の利用: Azureは、アドバタイズされるプレフィックスに対してBGPコミュニティ値を付与します。これを利用して、オンプレミスのルーターで特定のコミュニティ値が付与されたプレフィックスをフィルタリングしたり、優先度を調整したりできます。
VirtualNetworkGateway-All: すべてのAzure VNetプレフィックスをアドバタイズします。
VirtualNetworkGateway-Local: ローカルVNetピアリングされたプレフィックスのみをアドバタイズします。
VirtualNetworkGateway-Global: グローバルVNetピアリングされたプレフィックスもアドバタイズします。
NoExportコミュニティ: オンプレミスルーターで、NoExportコミュニティが付与されたプレフィックスは、BGPネイバー間で再配布しないように設定します。これにより、意図しないネットワークへのプレフィックス漏洩を防ぎます。
ASパスフィルタリング: 特定のASパスを持つプレフィックスのみを許可または拒否することで、ルーティングパスを制御します。
Azure VPN Gateway / Virtual WAN Hub の設定: ExpressRouteとVPN Gatewayを共存させる場合や、Virtual WAN Hubを利用する場合、それらの設定におけるBGPアドバタイズメントの制御も重要になります。例えば、ExpressRoute経由でオンプレミスにのみプレフィックスをアドバタイズし、VPN経由ではアドバタイズしない、といった制御が可能です。

まとめ：深淵を覗き、最適解を導き出す

Azure ExpressRoute環境下でのUDRとNAT Gatewayの挙動は、一見すると複雑に見えます。しかし、パケットがどのようにルーティングテーブルを参照し、ネクストホップへと転送されるのか、その一連の流れを正確に理解することで、セキュリティとパフォーマンスのトレードオフを最適化する設計が可能になります。

UDRは、インターネット向けトラフィックをVirtualAppliance（Azure Firewall/NVA）へ強制転送するための要。
NAT Gatewayは、VirtualApplianceからインターネットへ送信されるトラフィックの送信元IPアドレスを変換する役割。
ExpressRoute、VNetルーティング、Azure Firewall、NAT Gatewayは、それぞれが連携し、全体としてセキュリティと可用性の高いネットワークを構築する。

我々SREは、単に「動けば良い」というレベルを超えて、パケットの鼓動を聞き、その微細な揺らぎからパフォーマンスのボトルネックやセキュリティの綻びを見つけ出す必要があります。今回解説したUDRとNAT Gatewayの深淵は、そのための深い洞察を与えてくれるはずです。極限のパフォーマンスとセキュリティを追求する旅は、常に続くのです。