ポイント対サイト VPN でプライベートな Container Apps アプリに接続する

内部 Container Apps 環境には、プライベートな入口、一致するホスト名、VPN から到達できるリゾルバーが必要です。各手順を実行し、その後で拒否を検証します。

このランブックは、ワークロード プロファイルを持つ Container Apps 環境とその内部仮想ネットワークの入口を扱い、承認済みのポイント対サイト VPN を介してノートパソコンから到達し、アプリの直接の FQDN を使用し、環境レベルの HTTP ルートは使いません。 環境の入口がクライアントから到達可能であること、アプリのイングレス スコープが呼び出し元を許可していること、ホスト名がプライベートな入口に解決されることです。以下の各手順は検証可能な結果と、変更していないものに触れないロールバックを残します。手順 1 で誤ったスコープ判断は後のどの手順でも補えないため、示された順序で進めてください。

DNS に触れる前に、内部という言葉を確定してください。この製品では二つの異なるスコープに使われており、取り違えることが、機能する名前が依然として有用なものを返さない最も一般的な理由です。

手順 1: 環境とアプリのスコープを確定する

レコードを変更する前に、アプリのイングレス構成を確認します:

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately
App with external ingress in an internal environmentThe app accepts outside traffic through the environment's private entry

内部イングレスは環境の VNet 内にある環境の内部ロード バランサーで公開されるため、問いはノートパソコン が別のコンテナー アプリかどうかではなく、その VNet に到達できるかどうかです。VNet へのルートがあり、環境の既定ドメインがプライベート ゾーン経由で解決される VPN クライアントが適格な呼び出し元であり、残りの手順はまさにそれを作ります。パブリックな入口のない内部環境は、内部イングレスを持つアプリとは別の事実であり、アプリ レベルの外部イングレスは環境に公開の扉を与えません。次のエンジニアはまずチケットを読むため、スコープはポータルだけでなくチケットにも書いてください。

続行する前に、そのスコープを構成の所有者と確認し、ゲートは狭く保ってください: 環境の VNet へのルートがない場合、または環境の既定ドメインがプライベート ゾーン経由で解決されない場合は、いったん止めてその経路を先に修正します。VNet に到達できない、または名前を解決できない呼び出し元を、後のどの手順でも代替できません。

手順 2: 実際のホスト名と入口アドレスを収集する

環境の既定ドメイン、その静的プライベート入口アドレス、アプリに構成された FQDN を、古いスクリーンショットや ウィキ ページではなくリソースから取得して記録してください:

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Container Apps の プライベート入口のガイダンス では、アプリケーションのホスト名をそのまま保ちながら、環境のドメインを内部アドレスに一致させる方法が説明されています。ここで手作業で作っている形はまさにそれなので、新しい命名規則を考案するのではなく、ゾーンの内容をそれに合わせてください。

読み取ったドメインがアプリの報告する FQDN と一致しない場合は、いったん止めて今すぐ突き合わせてください。誤ったサフィックスでゾーンを作ると、完全に解決されるのに誤った仮想ホストに着地するホスト名ができます。

手順 3: プライベート ゾーンを VPN のリゾルバー経路に置く

環境の実際の既定ドメインに対して、文書化されたワイルドカード レコードとアドレス レコードが静的入口を指す、サポートされているプライベート DNS ゾーンを作成または再利用します。そのゾーンを適切な仮想ネットワークにリンクし、リンクだけで十分だと仮定せず、VPN の承認済みリゾルバー経路を通じてプライベート権限に到達できるようにします。

ポイント対サイト クライアントがそのゾーンに到達するには、通常、プライベート リゾルバーの受信エンドポイントか、サポートされている DNS フォワーダーが必要です。ゾーンをリンクしても、Azure がリンクされたネットワークに対して解決する内容が変わるだけで、外部ノートパソコン のパブリック リゾルバーをすべてリダイレクトするわけではありません。別の Container Apps ネットワーク モデルから借りたレコード名とゾーンのサフィックスが一致しないため、別の Container Apps ネットワーク モデルから借りたプライベート エンドポイントの DNS ゾーンで置き換えないでください。

この手順のロールバックは、追加したゾーン リンクまたはレコードを削除することです。一つのリンクを取り消すために共有ゾーンを削除するのは二つ目の環境を壊すよく知られた方法なので、どちらだったかを記録してください。

手順 4: 名前をテストし、次に拒否される対象をテストする

アドレスだけでなく、ホスト名と TLS 識別情報 を一緒にテストします。制御された名前マッピングの診断では、ホスト名を保ったままアドレスを固定できます:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

ホスト名を実際のアプリ FQDN に、アドレスを実際の内部入口に置き換えます。これはその一つの要求にだけ影響し、DNS のプロビジョニングではありません。証明書の不一致は間違ったリスナーに当たっているという信号なので、識別情報の失敗を見かけの合格に変えるために -k を追加しないでください。

数値アドレスを直接要求すると、TCP 443 が応答していても誤った仮想ホストが選ばれたり検証が失敗したりするため、IP テストの成功はネットワークに関する証拠として扱い、それ以上とはみなしません。想定されたノートパソコン から見た通常のリゾルバー経路は、クライアントの DNS フォワーダーか、ゾーンをホストするプライベート リゾルバーの受信エンドポイントであり、そこでの失敗はレコードの欠落ではなくリゾルバーへの到達性の問題です。同じ要求がその経路で成功することを確認し、次に拒否される対象が依然として拒否されることを確認します。

記録するものとロールバックするもの

コンテナーのターゲット ポートとクライアントの HTTPS ポートは別個の設定です。コンテナーがそこで待ち受けているからといって、そのターゲット ポートを VPN 経由で公開せず、ポート テストを通すためにネットワーク規則も広げないでください。どちらの変更もインシデント後も残り、後から帰属させるのが難しくなります。

想定されたノートパソコン から、その承認済みの識別情報 と通常の DNS を使って新しいアプリケーション操作で終え、その後、未承認の呼び出し元が依然として失敗することを確認します。そのルートはイングレス スコープが説明しない二つ目の扉なので、アプリ構成にいる間に、環境レベルの HTTP ルートがこのアプリをターゲットとして公開していないかも確認してください。

五つの値をまとめて記録します: 環境のスコープ、アプリのイングレス スコープ、FQDN、プライベート入口アドレス、リゾルバーの所有者です。この五つがアクセス契約の全体を表し、次にデバッグする人はまさにそれを求めます。

関連記事