Azure ネットワークルーティングのプラクティス④

Azure ネットワークルーティングのプラクティス エピソード①～③を公開して早 3 か月、次のイベント準備まで少し手が空けられそうでしたので次のエピソードを書いていきます。

4. App Service のルーティング (1回目)

第 4 回は App Service のルーティング (1回目) です、仮想ネットワーク統合中心にお送りします。

システム構成

本稿の基本的なシステム構成は下図となります。

構築手順はざっくり、

1. 仮想ネットワーク回りの作成
2. プライベート DNS ゾーンを作成して仮想ネットワークにリンク
3. NAT ゲートウェイを作成してすべてのサブネットに割り当て
   → パブリック IP: 20.222.38.218
4. Web Apps を作成して仮想ネットワーク統合を設定
   → 送信インターネットトラフィック: 有効
5. 仮想マシンを作成
   → プライベート IP: 10.0.1.4 / パブリック IP: 13.78.88.120

と言う感じです。

ベースライン

まずは何もいじらずに Web App から仮想マシンのプライベート IP に tcpping を打つと、

と疎通が確認できました。
これを仮想マシン側のパケットキャプチャーで見ると、

と送信元は Web App のプライベート IP : 10.0.2.254 であることが分かります。
ここからさらに仮想マシンのパブリック IP に tcpping を打つと、

と疎通し、

送信元は NAT ゲートウェイのパブリック IP: 20.22.38.218 になります。

ルートはこんな感じですね。

仮想ネットワーク統合の送信インターネットトラフィックを無効化

次に仮想ネットワーク統合の送信インターネットトラフィックを無効化してみます。
まずプライベート IP に tcpping

ここは Web App のプライベート IP: 10.0.2.254 のままです。
ではパブリック IP に tcpping

こちらは送信元の IP アドレスが変わりました: 13.78.17.86。
この IP アドレスは Web App の送信 IP アドレスの中の 1 つで、送信インターネットトラフィックを無効化するとパブリック IP には仮想ネットワーク統合を使わない動きになることが分かります。

ルートはこう変わりました。

受信トラフィック

次に受信トラフィックを送信インターネットトラフィック ON/OFF 両方で確認してみます。

結果は両方同じで Web App の仮想 IP アドレス: 13.78.106.98 とのトラフィックが発生します。
では今度は Web App 側から ↑ の送信元へ tcpping してみましょう。(送信インターネットトラフィック ON)

すると Web App 側が NAT ゲートウェイのアドレス: 20.222.38.218 になりました。

ルートはこう。

同じ宛先でも受信か送信かでルートが変わる動きになります。

この同じ宛先に対してルートが変わるのは一般的なネットワークの知識ではあり得ないのですが、Azure の世界では珍しいこともなく例えばパブリック IP を付けた仮想マシンでも同じ動き (受信はパブリック IPで送信は NAT ゲートウェイ) になります。
仮想マシンのルートテーブルを見ると同一サブネット (と特別な IP アドレス群) 以外はすべてデフォルトゲートウェイを向いていますので、デフォルトゲートウェイかその先のどこかで何か動的な処理をしているのでしょうか。
ここではその中身に踏み込むのは詳細に過ぎますので Azure ではこのような構成も一般的だと言うところまでにとどめたいと思います。

おわりに

第4回は App Service の仮想ネットワーク統合を中心にお送りしました。
送信インターネットトラフィック ON/OFF でルートが変わるところはそんなもんだろうと言う感じでしたかね。
受信トラフィックの動きに関してはブラックボックスが含まれてて若干の消化不良が残りました。

さて次回はプライベートエンドポイント & サービスエンドポイントでお送りする予定です、ボリューム出ちゃったら 2 回に分かれるかもしれません。
本稿を読んでいただきありがとうございました！