VPN コンテナ内のウェブ管理画面に到達する：ポートの所有者を選ぶ

アプリは VPN の名前空間を共有するため、ポートは VPN コンテナに属します。リスナーを正しくバインドし、所有者側で公開し、経路は狭く保ちます。

アプリにもトンネルにも問題はないのに、ダッシュボードは読み込まれません。network_mode: service:vpn でサービスを動かすと、VPN コンテナのネットワーク名前空間を共有するため、そのリスナーと公開ポートはサービスではなくその名前空間に属します。そこから三つの判断が導かれます：アプリがどこでバインドするか、どのコンテナがポートを公開するか、管理経路をどれだけ狭くするかです。順序を間違えると、個々の設定はどれも正しく見えるのに、組み合わせは機能しません。

ポートの名前空間は誰のものか

共有名前空間では、依存するサービスに ports: の項目を追加しても意味がなく、いくつかのネットワーク設定は設計上サポートされません。代わりに、名前空間を所有するコンテナ側で公開します。そのコンテナはホスト上にアドレスが現れるコンテナでもあるため、マッピングはサービスごとに一つではなく、一つの項目として読めます。

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

マッピングの左側のアドレスに注目してください。127.0.0.1 にバインドすると、公開ポートはホストのループバックに留まり、これは通常、管理インターフェースが望む形です。0.0.0.0 にバインドするとホストのすべてのインターフェースに公開され、これは便利さではなく別のセキュリティ判断です。

アプリを名前空間が期待する場所で待ち受けさせる

名前空間の内側で 127.0.0.1 にバインドしたリスナーは、その名前空間の内側からしか到達できません。公開されたホストポートは外から届くため、マッピングを機能させるにはアプリがより広いアドレスにバインドする必要があります。これはほとんどのサーバーでは一行の変更であり、コンテナを使わない構成向けに書かれた堅牢化ガイドをコピーした後で、まさにこの手順が飛ばされます。

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

アプリ内のリスナー一覧はバインドアドレスについて真実を語り、docker port は所有者が実際に何を公開したかを示します。前者が 127.0.0.1 を示し、後者がホスト側のマッピングを示すなら、VPN の設定に触れずに不整合を突き止めたことになります。

管理経路の入り方を選ぶ

合理的な構成は三つあります。VPN コンテナで公開し、ホストまたは LAN から到達します。名前空間の手前にリバースプロキシを置き、プロキシに唯一の公開ポートを与えます。あるいは、exec セッションや SSH トンネル経由で名前空間の内側からのみダッシュボードに到達できるようにし、これは露出が最小で利便性も最小です。

どれが合うかは、誰がどこからインターフェースを必要とするかによります。同じホスト上の単独の管理者なら、ループバックへのバインドで足ります。VPN 越しに到達するチームには、意図的に設計した経路と、名前の付いた所有者が必要です。プロキシの選択肢を取ると TLS とアクセスログが得られますが、更新し続ける構成要素がもう一つ増えます。

すべてを開かずに管理ポートを開く

VPN クライアント自体のローカルアクセスやロックダウンのポリシーは、外向きのトンネルが完璧に動いていても、内向きの管理リクエストを落とすことがあります。想定した送信元とポートに対して文書化された例外を一つ許可し、その後でトンネルの通常の保護が変わっていないことを確認します。ダッシュボードを読み込ませるためにキルスイッチを無効にすることは、実際の制御をブラウザのタブと引き換えることです。

アプリ自体の認証は有効なままにしてください。VPN に接続されたスタックの内側にいることは、ローカルのすべてのユーザーやホストに到達できるすべての端末を承認することではなく、トンネルの背後にある認証なしの管理画面は、やはり認証なしの管理画面です。

管理端末から検証し、後でもう一度検証する

実際にサービスを管理するマシンから試し、ホストからは試さず、その後でアプリが必要とするインターネット経路を別に検証します。管理の成功は一方向を証明するだけで、外向きについては何も語りません。

スタックを作り直した後にもう一度試します。ネットワークの所有者が入れ替わると、アプリが接続する名前空間が変わるため、更新前に動いていた URL が更新後には何も指さないことがあります。公開したマッピングとバインドアドレスを書き留めておけば、次の再構築は調査のやり直しではなく二分間の確認で済みます。

関連記事