リモートユーザーとローカルユーザー向けにHome Assistantのセットアップを調整する方法

エヴァ・ウォン

IceWhale author

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

How to Adapt a Home Assistant Setup for Remote and Local Users

Home Assistantのローカルユーザーとリモートユーザーに対応するには、まずローカルの制御経路を直接維持し、そのうえで、すでに自宅にいるユーザーにとって依存先とならない、認証済みの別のリモート経路を追加します。インターネットやリモートアクセスプロバイダーが利用できない場合でも、ローカルユーザーはHome Assistantにアクセスできるようにします。一方、リモートユーザーには、不要なサービスを公開せずに暗号化されたアクセスを提供します。

これを、同じHome AssistantのIDおよび認可モデルにつながる2つの接続経路として設計します。まず動作するローカルDNSと安定したLANアドレスを用意し、次にリモートエッジを選びます。その後、スマートフォン、ブラウザー、ダッシュボード、通知、家庭内のユーザーがWi-Fiと携帯回線の間を移動したときの挙動をテストします。

ローカル経路をリモートエッジから独立させる

ローカル制御では、クライアントがHome AssistantをLANから到達可能なアドレスに解決し、ホームネットワーク内にとどまるようにします。これにより、近隣のリクエストがいったんインターネットへ出て、トンネルやパブリックプロキシを経由して戻ってくる事態を避けられます。また、LAN、DNS、Home Assistantホスト、ローカルデバイスのプロトコルが正常である限り、ISP障害が発生しても基本的な制御を継続できます。

自宅の内外で同じパブリックホスト名を使用する場合、スプリットDNSによって、LAN内ではプライベートアドレスを返し、それ以外ではパブリックアドレスまたはトンネルアドレスを返せます。スプリットDNSによってローカルトラフィックをLAN内に保つ方法では、この仕組みによりヘアピンルーティングを回避し、覚えやすい1つの名前を使いながら、直接的なローカル経路を維持する方法を解説しています。

家庭の利用形態に合ったリモートエッジを選ぶ

リモートアクセスには、マネージドサービス、VPN／オーバーレイネットワーク、リバースプロキシ、トンネルなどを利用できます。適切な選択肢は、誰がアクセスする必要があるかによって異なります。VPNは技術に詳しい管理者1人には非常に適していますが、すべてのスマートフォンで追加の接続を維持する必要がある場合、家族にとっては使いにくくなることがあります。マネージド方式やトンネル方式は、技術に詳しくないユーザーにとって使いやすい一方、ローカル制御には不要な外部依存が増えます。

最近のCGNAT、セキュリティ、家庭での利用におけるリモートアクセス方式の違いは、すべてのリモートアクセスを同じ問題として扱わず、CGNAT、セキュリティ、家族にとっての使いやすさという観点から、VPN、トンネル、直接公開を比較しているため参考になります。認証済みの暗号化エッジを利用できる場合は、単純なパブリックポートフォワーディングを避けてください。

DNSと証明書でクライアントの切り替えを予測可能にする

リモートとローカルの障害は、スマートフォンがネットワークを切り替えたときに発生しやすくなります。パブリックホスト名がLAN上で誤って解決される、証明書が内部専用の名前と一致しない、プライベートDNSリゾルバーが使われない、または自宅の外でのみ使用する想定だった経路をVPNが使い続ける、といった問題が起こり得ます。各クライアントが両方の状態で使用すべきリゾルバーとホスト名を文書化してください。

より複雑な構成では、ローカル用とリモート用にホスト名を分けることで、経路を明確にできます。Home Assistantコミュニティの詳しい2経路によるリモートおよびローカルHome Assistant設計では、このパターンを実際に示しています。LANクライアントには直接的なローカルDNSを使用し、リモート用ホスト名を独立して保護し、モバイル環境でのバックグラウンド動作をテストします。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

ユーザー権限とネットワーク上の場所を分離する

「家の中にいること」と「管理者であること」を同一視しないでください。家庭内の各メンバーにそれぞれのHome Assistantユーザーを割り当て、統合、ユーザー、システム設定を変更する必要がある人にだけ管理者権限を与えます。リモートアクセスでは接続経路を認証し、Home Assistantでは引き続き利用者本人を認証する必要があります。

デバイスごとの挙動もテストしてください。壁掛けタブレットにはLANアクセスだけで十分な場合があります。家族のスマートフォンには、リモートダッシュボードと通知が必要になることがあります。管理者のノートパソコンでは、Home Assistantに加えて他のプライベートサービスにもアクセスするため、VPNが必要になる場合があります。こうした役割を明確にしておけば、セットアップ時に便利だったという理由だけで、すべてのデバイスに広範なリモートアクセス機構を与えずに済みます。

セットアップ完了と判断する前に4つの障害ケースを検証する

インターネット接続がある状態のローカルWi-Fi、インターネット接続を切断した状態のローカルWi-Fi、携帯回線によるリモートアクセス、そしてローカルネットワークが正常なままリモートエッジだけが停止した状態をテストします。それぞれのケースで、ログイン、1つのダッシュボード、1つのコマンド、1つの自動化結果、さらに重要な通知やメディアの経路を確認します。これにより、「ローカル」体験が実際にはパブリックDNSや外部プロキシに依存していないかを明らかにできます。

LAN経路とリモート経路の遅延を比較し、同じような体感になることを期待しないでください。ZimaSpaceのHome AssistantのLAN経路とリモート経路で遅延が異なる理由では、DNS、ルーティング、暗号化、プロキシ、クライアント側のネットワーク品質によって、自宅外では異なる遅延が発生する理由を説明しています。

シナリオ	想定される経路	引き続き動作すべきもの
自宅、インターネット接続あり	直接LAN	完全なローカル制御
自宅、インターネット接続なし	直接LAN	ローカルデバイスと自動化
自宅外	VPN／トンネル／マネージドリモートエッジ	認証済みのリモート制御
リモートエッジ停止	LANは引き続き直接接続	家庭内でのローカル利用

優れたリモート／ローカルHome Assistant設計では、すべてのユーザーを同じネットワーク経路に通す必要はありません。ローカル制御はローカルに保ち、別の安全な機能としてリモートアクセスを追加します。そして、一貫したDNS、証明書、ユーザーアカウント、障害テストを活用することで、ネットワークの切り替えがトラブルシューティングのきっかけにならないようにします。