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

エヴァ・ウォン

IceWhale author

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

Immich Opens Locally but Fails Remotely After a Router Change - Zima Store Online

ルーターを変更した後も自宅のWi-FiではImmichが開くのに、モバイルデータ通信では開けない場合、サーバーはおそらく正常で、変わったのはサーバー周辺の外部接続経路です。

ルーターを交換またはリセットすると、サーバーのLANアドレスが変わったり、ポート転送ルールが消えたり、異なるパブリックIPを取得したり、DNSの動作が変わったり、接続が別のNATモード配下に置かれたりすることがあります。まず完全に外部ネットワークからテストし、サーバーから外側へ向かって確認してください。一度に変更するレイヤーは1つにしてください。どの区間で失敗しているか分からないまま余分なポートを開くと、アクセスを復旧できないまま露出だけが増える可能性があります。

障害が外部接続だけで発生していることを確認する

まず、同じLAN上のデバイスから、サーバーの現在のローカルアドレスを使ってImmichにアクセスします。次に、スマートフォンのWi-Fiをオフにして、モバイルデータ通信で外部から同じテストを繰り返します。ローカルアクセスも失敗する場合は、ルーターの境界部分の問題として扱うのをやめ、まずサーバーまたはローカルネットワークを修復してください。

ローカルアクセスは機能するのに外部アクセスが失敗する場合は、使用している正確な外部ホスト名、プロトコル、エラー内容を記録します。タイムアウトは、証明書警告やプロキシのエラーページとは意味が異なります。また、直接ポート転送、リバースプロキシ、メッシュVPN、トンネルのどれを使っているかも確認してください。ルーターの交換による影響は、方式によって異なります。

リモートテストを自宅のWi-Fiだけで行わないでください。一部のルーターは、パブリックホスト名への内部リクエストをヘアピンNAT経由で処理しますが、対応していないルーターもあります。そのため、LANからのテストでは誤った失敗または成功が発生する可能性があります。この段階で目指すのは、ローカルのImmichは動作する一方、定義した外部経路の1つだけが失敗するという明確な症状です。

ルーターが同じLAN上の宛先にトラフィックを送信しているか確認する

新しいルーターでは、Immichホストに別のプライベートIPが割り当てられることがよくあります。サーバーの現在のLANアドレスと、ポート転送、リバースプロキシのアップストリーム、ファイアウォールオブジェクト、DHCP予約に保存されている宛先を比較してください。ルールが古いアドレスを指している場合は、Immichに手を加える前にそのマッピングを修正します。

選択したアクセス構成で実際に必要な受信ルールだけを再作成してください。外部ポート、内部の宛先、内部ポート、プロトコルを1つの組み合わせとして確認します。リバースプロキシを使用している場合、通常ルーターはImmichへ直接ではなくプロキシへ転送します。両方に転送すると、不要な2つ目の公開経路ができる可能性があります。

宛先を修正したら、再びモバイルデータ通信からテストし、プロキシまたはサーバーのログにリクエストが記録されるか確認します。ログが完全に静かなままなら、トラフィックはアプリケーションに到達する前に停止しています。リクエストがプロキシまたはホストに届くようになったものの、アプリケーションエラーが返る場合は、ルーター側の問題はおそらく解決しており、次のセクションではパブリックアドレスまたは名前解決に注目してください。

パブリックIP、DNSレコード、NATモードを比較する

ルーターの交換に伴って、WANのリースが更新されることがあります。Immichで使用しているホスト名を名前解決し、その結果と、自宅の接続に現在割り当てられているパブリックIPを比較してください。両者が異なる場合、ローカルサービスがすべて正常でも、ホスト名によってクライアントが古い接続先へ送られています。

ダイナミックDNSは、変動するパブリックアドレスとホスト名の対応を維持します。ホスト名がまだ古いWANアドレスに解決される場合、レコードと関連するキャッシュが更新されるまで、外部クライアントは誤った宛先に接続し続けます。ダイナミックDNSが変化するIPを追跡する仕組みを確認し、更新プログラムまたはレコードを修正してから、外部リゾルバーとモバイルデータ通信で再度テストしてください。

ルーターのWANアドレスがインターネット上から確認できるパブリックアドレスと一致しない場合、新しい接続はキャリアグレードNATまたは別の上位NATレイヤーの配下にある可能性があります。ピアとパブリックインターネットの間にNATがある場合、自宅ルーターのポート転送を変更しても、サービスを到達可能にできないことがあります。その場合は、パブリックアドレス、VPNまたはオーバーレイ経路、あるいは外部からの未承諾の受信転送に依存しない別のアクセス方法を使用してください。

-15% OFF

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

Single board computer zimaboard2

ネットワーク変更後のリバースプロキシ、TLS、ファイアウォールの状態を確認する

外部トラフィックがホストに到達しているのにImmichが開かない場合は、ルーターが管理しない認証・識別レイヤーを確認します。リバースプロキシが現在のImmichのアドレスとポートを指していること、ホスト名がプロキシのルートと一致していること、新しいLANサブネットから想定する経路がサーバーのファイアウォールで許可されていることを確認してください。

ドメインが誤ったプロキシサイトに到達する、リダイレクトを繰り返す、証明書名のエラーを表示する場合、それは単純なポート転送の問題ではありません。DNS、SNI、Hostルーティング、設定されたパブリックURLを調べる間は、正常に動作するIP経路と失敗するホスト名経路を分けて確認してください。ホスト名が誤ったパブリックアドレスに解決されている場合、やみくもに証明書を再生成しないでください。

より広い判断手順については、サーバー側の修正を繰り返す前に、ローカル到達性とパブリック経路の障害を切り分けてください。ローカルのImmichが正常であることを確認できれば、ルーター変更後の調査対象は、アドレス設定、NAT、DNS、ファイアウォール、プロキシ、TLSの状態に絞られます。

外部から再テストし、安全性を保ちながら最小限のアクセス経路を選ぶ

原因を1つ修正したら、同じホスト名とクライアントを使い、モバイルデータ通信から元のテストを繰り返します。その後、ルーターを1回再起動し、Immichホストも1回再起動します。サーバーが想定どおりのLAN宛先を維持し、DNSが正しく解決され、手動操作なしでリモートアクセスが復旧して初めて、修正が永続的だといえます。

直接の受信公開に依存している場合は、意図したHTTPS経路だけが公開され、以前の一時的なルールが削除されていることを確認してください。家族だけがアクセスする場合は、メッシュVPNまたは認証付きトンネルを使うことで、ポート転送や変動するパブリックアドレスへの依存を減らせます。特に、新しいルーターやISP側の経路を細かく制御できない場合に有効です。

リクエストが正しいプロキシまたはImmichのエンドポイントに確実に到達し、元のクライアントが再び動作するようになったら、ネットワーク変更をこれ以上エスカレートしないでください。ローカルアクセスは正常なのに、パブリックIPとDNSの経路が正しいにもかかわらず外部パケットがルーターに一度も到達しない場合は、ISPに相談するかアクセス方式を切り替えてください。それはネットワーク境界の問題であり、Immichを再構築する理由ではありません。