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

ローカルの操作経路を直接接続に保ち、すでに自宅にいる人にとって必須ではない、別個の認証済みリモート接続経路を追加することで、リモートユーザーとローカルユーザーの両方に対応できるようHome Assistantを整えます。インターネットやリモートアクセスプロバイダーが利用できない場合でも、ローカルユーザーはHome Assistantに接続できるようにし、リモートユーザーには不要なサービスを公開せず、暗号化されたアクセスを提供しましょう。

2つの接続経路を、同一のHome AssistantのIDと認可モデルにつなぐ設計にします。まず、正常に機能するローカルDNSと安定したLANアドレスを用意し、リモート接続の入口を選びます。そのうえで、スマートフォン、ブラウザー、ダッシュボード、通知、家族がWi-Fiとモバイル通信を切り替えた際の動作をテストしましょう。

ローカル経路をリモート接続の入口から独立させる

ローカル操作では、クライアントがHome AssistantをLANから到達できるアドレスに解決し、ホームネットワーク内にとどまるようにします。これにより、近くからのリクエストがインターネットに出て、トンネルやパブリックプロキシを経由して戻ってくるのを防げます。また、LAN、DNS、Home Assistantのホスト、ローカルデバイスのプロトコルが正常であれば、ISPの障害中も基本的な操作を続けられます。

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

家庭のニーズに合ったリモート接続の入口を選ぶ

リモートアクセスには、マネージドサービス、VPN／オーバーレイネットワーク、リバースプロキシ、トンネルを利用できます。適切な方法は、誰がアクセスする必要があるかによって異なります。VPNは技術に詳しい管理者には優れた選択肢ですが、家族全員のスマートフォンで追加の接続を維持する必要があると、使いづらくなることがあります。マネージド方式やトンネル方式は技術に詳しくないユーザーにも使いやすい一方、ローカルでの操作に必須ではない外部依存が加わります。

CGNAT、セキュリティ、家族での使いやすさにおけるリモートアクセス方法の違いを解説する最近の記事は参考になります。あらゆるリモートアクセスを同じものと見なさず、VPN、トンネル、直接公開をCGNAT、セキュリティ、家族での使いやすさの観点から比較しているためです。認証済みの暗号化されたエッジを使える場合は、単純なパブリックポートフォワーディングを避けましょう。

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

スマートフォンがネットワークを切り替えると、リモート接続とローカル接続の失敗が起こりがちです。LAN上でパブリックホスト名が正しく解決されない、証明書が内部専用の名前と一致しない、プライベートDNSリゾルバーが使われない、あるいはVPNが自宅外でのみ使う想定の経路を使い続ける、といったことがあります。どちらの状態で各クライアントがどのリゾルバーとホスト名を使うべきか、記録しておきましょう。

より複雑な構成では、ローカル用とリモート用でホスト名を分けると、経路を明確にできます。Home Assistantコミュニティの実例であるHome Assistantのローカル／リモート2経路設計では、LANクライアント向けの直接的なローカルDNS、独立して保護されたリモート用ホスト名、モバイルアプリのバックグラウンド動作のテストを組み合わせたパターンを紹介しています。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

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

「家の中にいること」を「管理者であること」と同じにしないでください。家族それぞれにHome Assistantのユーザーアカウントを用意し、インテグレーション、ユーザー、システム設定を変更する必要がある人に限って管理者権限を付与しましょう。リモートアクセスでは接続経路を認証し、Home Assistantでも引き続き利用者本人を認証する必要があります。

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

設定完了と判断する前に、4つの障害ケースを検証する

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

LAN経由とリモート経由の遅延を比較し、同じ使い心地を期待しないようにしましょう。ZimaSpaceのHome Assistantの遅延がLAN経由とリモート経由で異なる理由では、DNS、ルーティング、暗号化、プロキシ、クライアントのネットワーク品質によって、宅外では遅延がそれぞれ異なる理由を説明しています。

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