ZimaOSユーザーはGluetunをNordVPNに接続し、DelugeでそのVPNネットワークスタックを共有したいと考えていました。Gluetunは稼働していましたが、DelugeのWeb UIを開けませんでした。最終的にユーザーはDelugeのCompose定義をエクスポートし、Deluge独自のポートマッピングを削除してコンテナ間でネットワークを共有する設定を追加し、そのスタックを再インポートしました。
これはコミュニティで確認された構成であり、IceWhale App Storeのテンプレートではありません。後のユーザーはDelugeで再現できず、代わりにTransmissionを使用しました。
GluetunとDelugeのネットワーク経路の仕組み
ブラウザー → Gluetunが公開するポート → Deluge Web UI
Delugeの通信 → Gluetunのネットワーク名前空間 → VPNトンネル → インターネットDelugeがGluetunのネットワーク名前空間を使用すると、Delugeは独立したネットワークスタックを持たなくなります。そのため、Web UIとピア用ポートはDelugeで重複して公開するのではなく、Gluetunで公開する必要があります。
コミュニティで動作確認された手順
- 設定とダウンロードデータを保持したうえで、最初にインストールしたDelugeアプリを削除します。
- カスタムインストールを使用し、Deluge独自の公開ポートを削除します。
- 作成したCompose定義をエクスポートします。
- Delugeに
network_mode: container:gluetunを追加します。 - DelugeのWeb UIと必要なピア用ポートがGluetunで公開されていることを確認します。
- 編集したComposeスタックをインポートし、Gluetunが公開するホストポートからDelugeを開きます。
公式Gluetunプロジェクトでは、別のComposeプロジェクトにあるコンテナにはnetwork_mode: "container:gluetun"を、同じプロジェクト内のサービスにはnetwork_mode: "service:gluetun"を使用する方法が説明されています。どちらを選ぶか決める前に、Gluetunのコンテナ接続ガイドを確認してください。
到達性と外部通信の両方を確認する
元のユーザーはDeluge環境内で外部IPアドレスを確認し、ISPのアドレスではなくVPNのアドレスが表示されることを確認しました。Web UIがLANから引き続きアクセス可能であること、ダウンロードが意図した経路を使用すること、Gluetunが異常状態になった場合に通信が停止することもテストしてください。
VPN認証情報とComposeエクスポートを保護する
スクリーンショットやエクスポートしたYAMLには、プロバイダーのユーザー名、パスワード、秘密鍵、サーバー所在地、ローカルパスが含まれる場合があります。共有する前に必ず伏せ字にしてください。対応している場合は環境ファイルやシークレットを優先し、公開された認証情報はローテーションしてください。
App Storeとの境界を理解する
Composeをエクスポートして再インポートすると、新しいスタックが元のApp Storeのライフサイクルから切り離される可能性があります。イメージタグと設定を記録し、アップグレードは手動でテストしてください。再インストール後も設定が保持されているからといって、広範な「Dockerキャッシュのクリーンアップ」コマンドを実行しないでください。永続化されたAppDataは、コンテナの置き換え後も保持されるように設計されています。
GluetunとDelugeに関するFAQ
DelugeのWeb UIが表示されなくなったのはなぜですか？
DelugeがGluetunのネットワーク名前空間を共有すると、アクセス用ポートはGluetunで公開する必要があります。
Delugeに独自のポートマッピングを残すべきですか？
この共有ネットワーク構成では不要です。必要なポートはGluetunで公開してください。
この結果はすべての環境で再現できましたか？
いいえ。元の投稿者は動作を確認しましたが、後の参加者はDelugeの構成を再現できず、Transmissionを使用しました。
