VPNクライアントからNASダッシュボードにはアクセスできるのにDockerサブネットへ到達できない場合があります。ホストに到達できても、コンテナネットワークへの転送ルートが自動的に作成されるわけではないためです。
ZimaSpaceホームサーバーでは、NAS管理ページがホストのアドレスで待ち受けている一方、セルフホストアプリは172.18.0.0/16などのDockerブリッジの背後で動作していることがあります。VPNはホスト上で正常に終端していても、これらのブリッジネットワークに対する広告ルート、転送ルール、戻り経路、または重複しないアドレス設計がないとアクセスできません。
VPNがホストへのルートしか認識していないか確認する
VPNクライアントのルートテーブルで、NASホストのアドレスと実際のDockerサブネットを比較します。
サブネットルーターによって1台のホストを超えてアクセスを拡張する方法を扱った、VPNのサブネットルーティングに焦点を当てたブログは、基礎となるプロトコルの定義だけでなく同じ具体的な問題を扱っているため、この切り分けに役立ちます。
ホストまたはLANサブネットだけが広告されている場合、プライベートなDockerブリッジに自動的に到達できるとは考えないでください。
DockerとVPNのサブネットが重複していないか確認する
VPNクライアントのアドレスプール、自宅のLAN、すべてのDockerブリッジ範囲を比較します。
DockerサブネットがVPNと重複するケースを扱った、実環境のルーティング事例に焦点を当てた記事は、基礎となるプロトコルの定義だけでなく同じ具体的な問題を扱っているため、この切り分けに役立ちます。
Dockerのアドレスプールを自宅のネットワークやVPNの範囲から離し、影響を受けたネットワークだけを再作成します。
ホストに予期しないDockerルートがないか確認する
VPNクライアントとコンテナサブネット宛ての通信に、Linuxがどのインターフェースを選択しているかを確認します。
Dockerが別のサブネットを隠すルートを設定するケースを扱った、Homelabネットワークに焦点を当てたブログは、基礎となるプロトコルの定義だけでなく同じ具体的な問題を扱っているため、この切り分けに役立ちます。
VPNへの返信を誤ったブリッジへ送るルートがあると、ダッシュボードは動作していても通信が非対称になります。
DockerとVPNのアドレス設計を1つのシステムとして扱う
Dockerの範囲を、VPN、VLAN、LANの範囲とは独立して割り当てないでください。
DockerとVPNのアドレス競合がルーティングの問題になるケースを扱った、Dockerネットワークに焦点を当てた解説は、基礎となるプロトコルの定義だけでなく同じ具体的な問題を扱っているため、この切り分けに役立ちます。
コンテナブリッジ用に文書化したプライベート範囲を確保し、リモートユーザー向けVPNプールの範囲外に維持します。
VPNホストでIPフォワーディングとNATを確認する
ホスト自身宛てのパケットは受け付けても、別のインターフェースやブリッジへ転送しないよう設定されている場合があります。
VPNクライアントが先のネットワークへルーティングする際に必要なフォワーディングとNATを扱った、VPNルーティングのトラブルシューティングガイドは、基礎となるプロトコルの定義だけでなく同じ具体的な問題を扱っているため、この切り分けに役立ちます。
VPNインターフェースとDockerブリッジインターフェースでパケットをキャプチャします。一方に到着しても他方から出ていない場合は、フォワーディングまたはファイアウォールポリシーを修正します。
コンテナ固有のWireGuardルーティングを確認する
一部のホームサーバースタックでは、選択したコンテナをWireGuard名前空間経由でルーティングするため、リモートクライアントへの戻り経路が変わります。
コンテナのルーティングで別のWireGuard経路を使用するケースを扱った、Homelabのコンテナルーティングに焦点を当てたブログは、基礎となるプロトコルの定義だけでなく同じ具体的な問題を扱っているため、この切り分けに役立ちます。
通常のブリッジコンテナとVPN経由でルーティングされたコンテナを1つずつ別々にテストし、ポリシールーティングをDocker全体の障害と取り違えないようにします。
ホームサーバーへの実際の経路を再テストする
1つの変数を変更した後は、別の経路を使う可能性のある異なるテストへ切り替えず、同じクライアントから同じNASまたはセルフホストの操作を繰り返します。
関連するホームサーバーのネットワーク経路を扱ったZimaSpaceのガイドは、最終確認を同じセルフホスト環境に結び付けるのに役立ちます。
再接続、サービスの再起動、さらに2回目の管理された転送またはリクエストの後も、元の症状が解消されたままであることを確認して初めて、修正は完了です。
よくある質問
NASダッシュボードにはアクセスできるのに、コンテナサブネットへアクセスできないのはなぜですか?
ダッシュボードへの通信はホスト上で終端します。Dockerブリッジには、別途ルーティング、フォワーディング、戻り経路の処理が必要です。
DockerブリッジのサブネットをVPN経由で広告すべきですか?
リモートクライアントがブリッジへ直接アクセスする必要がある場合に限ります。公開プロキシポートのほうが簡単で安全なことがよくあります。
DockerとVPNの範囲が重複すると、一部のアプリだけが使えなくなることはありますか?
はい。Linuxのルート選択によって、ある範囲への返信だけが誤ったブリッジへ送られ、他のホストサービスには引き続きアクセスできる場合があります。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

