Azure Web アプリが VPN 経由でオンプレミスに到達する方法

Web アプリのアウトバウンド リクエストは、選択していないソースから見たこともないワーカーを残すため、オフィスのファイアウォールはそれを受け入れる必要があります。これが問題のすべてを一文で表したものです。リージョン VNet 統合により、要求に仮想ネットワークへのパスが与えられ、サイト間 VPN がそこから要求を伝送します。その後問題が発生するのは、パケットが実際に使用した送信元範囲とルートに関するものです。

ワーカーが実際に送信するもの

App Service は、サブスクリプションのネットワーク ビューの外側にあるワーカー上でコードを実行します。リージョン統合を有効にすると、送信トラフィックは同じリージョン内の VNet の委任されたサブネットに渡され、パケットはそこに表示されてから続行されます。統合によってアプリは VNet に移動されず、受信アドレスも変更されません。送信フローに異なる最初のホップを与えるだけです。

デフォルトでは、プライベート アドレス空間のみがそのパスを通るため、通常のインターネットの宛先は引き続きワーカーから直接送信されます。 VNet 経由ですべてをルーティングすることは、パブリックの依存関係もトンネル経由で送信されるため、別の設定と別の決定になります。

起動時のコンテナ イメージのプルなどの構成トラフィックは独自のルーティング ルールに従い、API 呼び出しが成功しても失敗する可能性があります。

統合サブネットは許可する必要があるソースです

オフィスには、アプリのパブリック送信アドレスではなく、統合サブネットのアドレス範囲、またはアプライアンスが変換するアドレスが表示されます。その範囲をサイト VPN のトラフィック セレクターとオンプレミスのファイアウォール ルールに入力します。トンネルがポリシーベースの場合、ルートが存在する場合でも、トンネルを省略したセレクターはパケットをドロップします。

たまたま観察した単一のワーカー アドレスを許可しないでください。インスタンスはスケーリングやプラットフォームのメンテナンスによって変化し、一つのアドレスに固定されたルールは最悪の瞬間に壊れます。

宛先側は狭くしてください：一つのサービス、一つのポート、一方向であり、リターン パスは明示的に許可されています。

ピアリングとゲートウェイ トランジットは明示的です

VPN ゲートウェイがハブ VNet にあり、統合サブネットがスポークにある場合、パスにはハブ ピアリングでゲートウェイ トランジットが許可され、スポーク ピアリングでリモート ゲートウェイの使用が有効になっている必要があります。ピアリング自体は 二つの VNet 間のトラフィックを伝送するだけで、それ以上のことは行いません。統合サブネット上の有効なルートは、ゲートウェイのネクストホップが実際に存在することを確認する場所です。

ルート テーブルが 0.0.0.0/0 をファイアウォールに送信するハブアンドスポーク設計は一般的なバリアントであり、そのファイアウォールにはオンプレミス プレフィックスに対する独自のルールが必要です。

ネットワーク チームにチケットをオープンする前に、紙にパスを描いてください。これにより、推測する時間を 一日節約でき、戻り方向を図面に含めます、これは人々の半分が忘れてしまう部分であるためです。

受信プライベート エンドポイントは逆方向です

プライベート エンドポイントにより、VNet 内からアプリにアクセスできるようになります。これはアプリのオフィスへの発信には何も作用せず、実際の要件は逆であっても、チームは定期的に設定を行います。

古いドキュメントでは、ポイント対サイト VPN 上に構築されたゲートウェイが必要な統合について説明していますが、これは独自の要件を持つ別の機能です。 Microsoft は、この機能の廃止を 2027 年 三月 31 日に予定しており、代わりに地域統合を推奨しています。

古い例で使用されていたという理由だけで、従来のポイント対サイト構成をコピーしないでください。

アプリ独自のコンテキストで検証する

ラップトップや同じ VNet 内の VM からではなく、デプロイされたアプリからテストします。 DNS 障害、TCP タイムアウト、認証拒否は 三つの異なる所有者を指すため、解決されたアドレス、接続結果、およびアプリケーション レベルの応答を個別に記録します。名前解決が失敗した場合は、トンネルに接続する前に VNet のプライベート DNS を修正します。

緑色のトンネル ステータスは、ゲートウェイが稼働していることを証明するだけです。セレクター、ファイアウォール ルール、DNS については何も記載されていません。

リクエストが最終的に機能したら、送信元範囲、宛先ポート、および DNS ゾーンをアプリの Runbook に書き込みます。次にこれをデバッグする人は、ゲートウェイのステータス ページではなく、メモから開始します。