Azure のポイント対サイトは接続するが、プライベート リソースが応答しない
接続済みはトンネルが上がったというだけです。ゲートウェイが何を運べるかを確認し、アドレス空間を比較し、その後で名前を解決してサービス自体を試します。
接続済みとはトンネルの状態であり、到達可能性の表明ではありません。ポイント対サイトのクライアントは IKE を終え、アドレスを受け取っても、何にも届かないことがあります。ゲートウェイは VNet がすでに知っているネットワークのトラフィックしか転送しないからです。次の五つの確認を順番に行い、最初の失敗で止めてください。先へ飛ばすと、DNS の問題が一時間にわたってファイアウォールの問題として扱われることになります。
順序は一覧よりも重要です。
確認 1: トンネルが何を運ぶべきかを決める
Azure VPN Gateway はトンネルを終端し、VNet に属するトラフィックを転送します。これは一般的なインターネット出口ではありません。ユーザーが閲覧を Azure 経由で出したいと期待しているなら、クライアント設定が登場する前の時点で設計が誤っています。スプリット トンネリングを有効にしてローカルのインターネットがローカルの経路を使い続けるようにし、固定の出口アドレスが本当に必要なときは NAT インスタンスかサイト間トンネルを使ってください。
何かを試す前に、クライアントがどこへ届くべきかを書き出してください。その一覧がないと、部分的な結果のすべてが進捗に見えます。
確認 2: 証明書より先にアドレス空間を比較する
重複はより広い範囲で判断されるため、サブネット単位で違って見える二つのネットワークも、親ブロックが重なっていれば衝突します。ゲートウェイ サブネットは専用で SKU に足る大きさでなければならず、クライアントのアドレス プールは VNet やピアリング経由で届くものと衝突してはいけません。計画を変えて再デプロイしてください。補うためにルートを足すと、一部の宛先では動き、他の宛先では説明のつかない形で動かないトンネルができます。ここではプロビジョニングが大きな音を立てて失敗しますが、それが良いケースです。
認証が次の関門です。証明書、RADIUS、Entra ID のプロファイルは互換ではなく、クライアント パッケージもそれぞれ異なります。
確認 3: 内側からプライベート名を解決する
クライアントは、ダウンロードしたプロファイルが VNet の DNS サーバーを持たない限り、自分のリゾルバーを使い続けます。その一覧はダウンロード時に埋め込まれます。VNet の内側にフォワーダーを追加し、VNet の DNS サーバーとして設定し、それからクライアント パッケージをダウンロードして再びインポートしてください。古いパッケージの再利用は、古いリゾルバー一覧を試すだけです。
まずアドレスを試してください。これでルーティングと名前解決を一つの手順で切り分けられます: Test-NetConnection 10.20.1.4 -Port 3389。
アドレスが応答して名前が応答しないなら、リゾルバーに直接問い合わせます: Resolve-DnsName files.corp.example -Server 10.20.0.4。両方とも失敗するなら、障害は DNS ではなく、DNS 設定の編集をやめるべきです。168.63.129.16 の Azure プラットフォーム DNS は VNet の内側からしか応答しないため、外側のクライアントはそのアドレスをリゾルバーとして使えません。
確認 4: トンネルの背後のサービスを試す
健全なトンネルと閉じたポートは、クライアントから見ると同じに見えます。ゲストのファイアウォールを確認し、次にサブネットまたは NIC のネットワーク セキュリティ グループを、次にサービスがループバックだけでなくプライベート アドレスで待ち受けているかを確認してください。インターネットへの規則を開くのではなく、クライアント プールを送信元として許可し、Azure Files への SMB はプライベート エンドポイントの経路をトンネル経由で通す必要があることを覚えておいてください。リソースが IP では応答するが名前では応答しないときは、ゲートウェイに触れずに確認 3 に戻ります。
作業中は一つの表が層を分けてくれます:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
確認 5: エスカレーションの前にプロファイルを記録する
チケットにゲートウェイの種類、トンネルの種類、認証方法、クライアントの OS を書いてください。証明書の IKEv2 プロファイルと RADIUS プロファイルは別の理由で失敗し、別のトンネルの種類向けに作られたクライアントは、ゲートウェイが互換のプロトコルを提供するときだけ接続します。
小さなチームにとって耐久性のある設計は、一つの VNet、一つの DNS フォワーダー、文書化されたスプリット トンネル クライアントです。要件が固定のパブリック出口なら、自分で管理するファイアウォールでサイト間トンネルを終端し、インターネット トラフィックをそこへ流してください。ポイント対サイトのゲートウェイに、もともと作られていないことを頼むのではなく。