ルーター変更後、Home Assistantはローカルでは開くがリモートでは接続できない

ルーターを変更した後もローカルネットワーク上でHome Assistantが開く場合、Coreと基本的なLAN経路はおそらく正常です。問題は、新しいルーターのアドレス割り当て、NATルール、パブリックIP、DNSレコード、VPNまたはトンネル経路、あるいはリバースプロキシの経路にある可能性が高くなります。

リモートアクセスだけの障害を解決するために、Home Assistantを再インストールしないでください。まずローカルアドレスを確認し、その後は境界を一つずつ外側へ確認して、新しいネットワークが以前のリモートアクセス設計と最初に一致しなくなる箇所を見つけます。

新しいルーターによってHome AssistantのLANアドレスが変わっていないか確認する

新しいルーターではサブネットが異なる場合や、Home Assistantに別のDHCPリースが割り当てられる場合があります。そのため、以前のルーターからコピーしたポート転送ルールが、現在はHome Assistantホストに割り当てられていないアドレスを指している可能性があります。

新しいルーターのクライアント一覧またはHome Assistantのネットワーク設定で現在のアドレスを確認し、LAN上のデバイスからその正確なアドレスを開きます。ローカルアクセスが機能する場合、NATやリバースプロキシのルーティングで固定の内部宛先を使用しているなら、DHCP予約を作成してください。

ZimaSpaceのLAN IPの変更とパブリックIP・DNSの変更を切り分けるガイドは、ルーター交換後に最初に確認すべき境界を説明しています。

新しいルーター用にリモート接続経路を再構築する

直接ポート転送を使用している場合は、新しいルーターでルールを作り直し、転送先が現在のHome AssistantのLANアドレスと待ち受けポートになっていることを確認します。VPNまたはアウトバウンドトンネルを使用している場合は、コネクターがオンラインであり、新しいルーターが必要な送信経路や戻りの経路をブロックしていないことを確認してください。

Home Assistantのリモートアクセスガイドでは、Home Assistant Cloud、VPN、リバースプロキシ、ポート転送の経路を区別しています。ルーター交換による影響は方式ごとに異なるため、実際に使用している方式をトラブルシューティングし、古いNATルールをVPNベースの構成にそのままコピーしないでください。

モバイルデータ通信または別の完全に外部のネットワークからテストします。同じLAN内からパブリックホスト名をテストすると、NATループバックやスプリットDNSの動作によって判断を誤る可能性があります。

パブリックIPまたはCGNATの状況が変わっていないか確認する

新しいルーターの設置は、新しいWANリース、モデムの再起動、ISPの設定変更と同時に起きることがよくあります。パブリックIPv4アドレスが変わり、ダイナミックDNSが更新されていない場合、ホスト名が古い接続先を指し続ける可能性があります。

ルーターに表示されるWANアドレスと、インターネット側から確認できるパブリックアドレスを比較します。ルーターがパブリックIPv4ではなくプライベートアドレスや共有キャリアアドレスを受け取っている場合、ISP側のCGNATが上流にあるため、直接の受信ポート転送が機能しなくなっている可能性があります。

新しいルーターがパブリックNATの境界を保持していない場合は、Home Assistantの設定を編集し続けないでください。Home Assistant Cloud、メッシュVPN、リバーストンネルを使用するか、ISPにパブリックIPを依頼してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

DNSとHome Assistantの外部URLを別々に確認する

リモートアクセスで使用している正確なホスト名を解決し、現在意図しているパブリックアドレスまたはトンネルアドレスが返されることを確認します。次に、可能であれば宛先へ直接アクセスしてテストします。DNSが正常でも、プロキシやポートが正しいとは限りません。また、ポートが機能していても、ホスト名が正しく解決されているとは限りません。

Companionアプリでは、内部経路と外部経路が異なる場合があります。現在のネットワーク関連ドキュメントでは、内部URL、外部URL、DNS、IPv4/IPv6、リバースプロキシの動作について説明しています。古いネットワークでは設定と実際の構成がたまたま一致していたため、新しいルーターへの変更によって古い設定が表面化することがあります。

アプリは失敗するものの、モバイルデータ通信でブラウザーを使うとアクセスできる場合は、サーバーに手を加える前に、アプリが使用しているURLとネットワークプロファイルを比較してください。

プロキシ経路が変わった場合に限り、リバースプロキシの信頼設定を再確認する

新しいルーターによってDockerのサブネット、プロキシのアドレス、またはTLSを終端するマシンが変わる場合もあります。現在、別のリバースプロキシを経由してリクエストが届いているなら、新しいプロキシを信頼するまでHome Assistantが転送ヘッダーを拒否する可能性があります。

HTTP統合では、X-Forwardedヘッダーを送信する従来型のリバースプロキシに対する信頼済みプロキシ設定が必要です。エラーを消すためだけに信頼するネットワークをLAN全体へ広げないでください。実際のプロキシの送信元だけを信頼します。

ここまで確認すれば、問題は次のいずれか一つの層に絞られているはずです。誤ったLAN宛先、NATまたはトンネル経路の欠落、パブリックアドレスの変更、CGNAT、古いDNS、またはプロキシの信頼設定です。

よくある質問

ルーターを変更しただけで、新しいTLS証明書が必要ですか？

通常は必要ありません。同じホスト名を使用している限り、ルーターの変更だけで証明書が無効になることはありません。証明書の問題は、ホスト名、チャレンジの経路、プロキシ、DNS、またはTLSの終端が変わった場合に発生します。

リモートURLがモバイルデータ通信では機能するのに、自宅のWi-Fiでは失敗するのはなぜですか？

これは一般的なリモートアクセス障害ではなく、ヘアピンNATやスプリットDNSなど、内部限定のルーティングまたはDNSの問題を示しています。内部DNSの応答とプロキシ経路を個別にテストしてください。