Home Assistantではホストネットワークとブリッジネットワークのどちらを使うべきですか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

LAN検出が必須の場合、Home Assistantではホストネットワークを使用する必要があります。明示的なポート指定と分離を優先する場合は、ブリッジネットワークの方が適しています。

どちらのモードが常に高速または安全というわけではありません。選択によって、Home Assistantが認識するネットワーク名前空間、マルチキャストやブロードキャストによる検出の到達方法、公開するポート、他のコンテナとの接続方法が変わります。再起動後も動作させる必要がある統合機能を基準に選び、選択したモードで検出、直接制御、MQTTまたは無線ゲートウェイ、リモートからの入口をテストしてから、構成を安定版と判断してください。

まず、Home AssistantがLAN検出トラフィックを受信する必要があるか確認する

Home Assistantの多くの統合機能は、既知のIPアドレスやブローカー接続を使用できますが、mDNS、SSDP、UPnP、またはブロードキャスト検出に依存するものもあります。これらのプロトコルが、Containerインストールでホストネットワークが一般的に使われる主な理由です。Home AssistantがDockerブリッジを介したマルチキャスト転送を必要とせず、ホストのLAN名前空間に直接参加できるためです。

Dockerのネットワークガイドでは、ホストネットワークではブリッジ境界がなくなると説明されています。これによりブロードキャスト型サービスは扱いやすくなりますが、Dockerのポート公開機能とネットワーク名前空間の分離もなくなります。ほとんどのHome Assistant環境では、このトレードオフは生のスループットより重要です。

実際に検出を必要とする統合機能を一覧にしてください。重要なデバイスがすべて明示的なアドレス、MQTT、マッピングしたコーディネーター経由のZigbee、または別の明確なエンドポイントを使用しているなら、ブリッジモードでも問題なく動作する可能性があります。複数の統合機能がローカル検出に依存し、マルチキャストリレーを管理したくない場合は、通常、ホストモードの方が運用しやすい選択です。

検出の簡単さが名前空間の分離を上回る場合はホストネットワークを選ぶ

ホストモードでは、Home Assistantがホストのネットワークスタックに直接バインドされます。Dockerのポートマッピング層はなく、コンテナは通常、ローカル検出とより適切に連携する形でホストのインターフェースを認識します。その代わり、ネットワーク分離は弱くなり、ポートの競合をホストレベルで管理する必要があります。

Home AssistantのDocker設計に関する解説でも、同じ条件付きの結論に達しています。ホストモードではmDNSとUPnPの検出が簡単になる一方、ブリッジモードではネットワーク境界と公開ポートをより明確にできます。

検出の失敗が繰り返し発生し、それ以外の方法では解決しにくく、サーバーが信頼できる自宅ホストで管理対象のサービスも限定されている場合は、ホストモードを選んでください。原因不明の接続問題を隠すためだけにホストモードを使わないでください。ホストネットワークでもデバイスが動作しない場合、原因はVLANルール、Wi-Fiクライアント分離、ローカルDNS、デバイスの権限、または統合機能自体の問題であり、Dockerのブリッジではない可能性があります。

統合機能に明示的な到達性がある場合はブリッジネットワークを選ぶ

ブリッジモードでは、コンテナにプライベートなDockerアドレスが割り当てられ、到達可能にするHome Assistantのポートだけを公開できます。他のコンテナとは名前付きDockerネットワーク経由で通信でき、LANデバイスからは公開されたホストポートにアクセスできます。検出が必須でない場合や、マルチキャストを意図的にプロキシする場合は、より明確な境界を構築できます。

Home Assistantのユーザーがブリッジとmacvlanの構成を比較した報告では、通常のブリッジではmDNSが複雑になる一方、別のネットワーク設計によってLANへの直接的な可視性を取り戻せることが示されています。ブリッジネットワークでの検出動作から得られる有用な教訓は、公開したTCPポートがマルチキャスト検出も運ぶと決めつけず、必要なプロトコルを実際にテストすることです。

必要なデバイスに明示的なIP、ホスト名、ブローカー、またはマッピングしたハードウェアパスで到達でき、サービス間の境界をより厳密にしたい場合は、ブリッジモードを選んでください。LANデバイスを検出できないことだけが原因で統合機能が失敗する場合は、まずエンドポイントを明示的に設定してみてください。その統合機能が本当にその検出動作を必要とする場合にのみ、ホストモードまたはより高度なネットワーク構成へ移行します。

再起動後も同じ統合機能のテスト項目で選択を検証する

5項目のテストを作成してください。ローカルダッシュボードへのアクセス、mDNSまたはSSDPデバイス1台、明示的なIPを使う統合機能1つ、ブローカーまたは無線ゲートウェイ1つ、通常のリバースプロキシまたはVPN経路をテストします。Composeを変更した直後だけでなく、コンテナの再作成後とホストの再起動後にもテストしてください。キャッシュされた検出情報によって、後から失敗するネットワークモードが正常に見えることがあるためです。

ZimaSpaceによるDockerサブネットへの到達性のトラブルシューティングは、同じ境界を示しています。同じ物理サーバー上で動作していても、アプリケーションの利用可能性とコンテナネットワークへの到達性は別々に確認する必要があります。

必要な検出を一貫して維持でき、共有名前空間を受け入れられるなら、ホストモードを維持してください。必要なすべての統合機能に到達でき、明示的な境界によって運用上の不明確さが減るなら、ブリッジモードを維持してください。どちらも合格しない場合は、モードの切り替えをやめ、VLANルーティング、マルチキャスト転送、ファイアウォールルール、または統合機能で使われる通信方式そのものを調べてください。ネットワークモードは経路を構成する1つの層にすぎません。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.