Immichのネットワーク：ディスカバリー、DNS、ルーティングによって到達性が実現される仕組み

エヴァ・ウォン

IceWhale author

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

Immich Networking: How Discovery, DNS, and Routing Produce Reachability

Immichへの到達性は、エンドポイントの選択、DNS解決、パケットルーティング、プロキシまたはNAT転送、アプリケーションの応答という、順序付けられた一連の流れによって決まります。

スマートフォンからローカルIP経由ではImmichに接続できるのに、同じホスト名ではWi-Fi接続時に失敗したり、自宅ではより長い経路を通ることでリモート接続は機能したりすることがあります。これらは「ネットワークが起動しているか」という単一の状態ではなく、異なる名前解決と経路の選択によって生じます。

到達性はクライアントが選択するエンドポイントから始まる

クライアントは抽象的なサービスとしての「Immich」にルーティングすることはできません。スキーム、ホスト名またはアドレス、ポート、場合によってはパスを使用します。ネイティブアプリ、ブラウザー、ブックマーク、共有リンクには、それぞれ異なるエンドポイントが保存されていることがあります。サーバーにパケットが到達する前から、接続の可否が分かれる可能性があります。

Immichをローカルおよびリモートで公開する方法についてのコミュニティスレッドでは、ルーターがスプリットホライズン動作を提供できず、クライアントにもローカルエンドポイントへの自動切り替え機能がない場合の問題が説明されています。この事例は、エンドポイントの選択とローカルDNSの機能が、自宅のクライアントが試みる経路を共同で決めることを示しています。

各クライアントで使用する正確なURLを書き出し、それが入力されたものか、リンクから取得されたものか、以前に保存されたものかを記録してください。スキーム、ホスト、ポート、パスを比較します。機能するローカルIPと失敗するパブリックホスト名を一つの結果にまとめないでください。これらは異なる宛先契約です。

DNSはアドレスを選択するが、サービスの動作までは保証しない

DNSは、選択されたホスト名をアドレスに変換します。パブリックリゾルバーとローカルリゾルバーは意図的に異なる応答を返すことがあり、古いキャッシュによって以前のルーターやサーバーのアドレスが保持される場合もあります。正しい応答が示すのは宛先だけであり、その宛先でポート、プロキシ、証明書、アプリケーションが利用可能であることまでは証明しません。

Caddyコミュニティの事例では、ローカルIP経由ではImmichが動作する一方、DuckDNSベースのローカル経路は失敗し、ヘアピンNATの問題が提起されています。詳細は環境によって異なりますが、同じホームネットワーク上でも名前解決とルーターの戻り経路が異なる可能性を示しています。

問題が発生しているスマートフォンまたはブラウザーのネットワークからホスト名を問い合わせ、期待されるローカルまたはパブリックアドレスと比較してください。モバイルデータ通信でも繰り返します。応答が意図的に異なる場合は、スプリットDNSとして記録します。予期せず異なる場合は、Immichコンテナを変更する前に、権威DNSレコードまたはキャッシュを修正してください。

ルーティング、NAT、プロキシが配信経路を完成させる

DNSの後、クライアントには経路が必要です。リモート通信はISP、ルーター、ポートフォワーディング、トンネル、リバースプロキシを経由することがあり、ローカル通信は直接接続されるか、パブリック側の入口を経由することがあります。各層は正しいポートに届け、アプリケーションが想定するリクエストコンテキストを維持しなければなりません。

ZimaSpaceのImmichのデータパスに関する記事では、クライアント、ネットワーク、アプリケーション、データベース、メディアの依存関係が分けて説明されています。この階層モデルにより、よくある誤りを防げます。つまり、アプリケーションがすでにローカルで応答しており、最初に壊れている依存関係がコンテナの外部にあるのに、Immichを再起動してしまうことです。

アドレス、経路、待ち受けポート、プロキシの転送先、TLS名、アプリケーションの応答という順に経路を確認してください。pingに成功しても十分ではありません。WebポートやAPIポートがブロックされている可能性があるためです。同様に、プロキシのランディングページが表示されても、リクエストがImmichサービスに到達している証拠にはなりません。

Featured

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

ZimaCube2

階層化した到達性トレースを使用する

自宅のWi-Fiとモバイルデータ通信用に2列を作成します。それぞれに、選択されたURL、DNSの応答、経路またはゲートウェイ、TCP接続、TLSの結果、HTTPステータス、認証済みImmich APIの応答を1件記録します。ネットワーク比較でユーザーや権限が変わらないよう、同じアカウントとアセットを使用してください。

ホームサーバー向けのImmichガイドでは、証明書やアプリケーションアクセスの手順に先立つ前提条件としてDNSルーティングが示されています。この順序は、診断上の原則を裏付けています。つまり、後段のレイヤーで誤った名前とアドレスの対応を補うことはできず、DNSが正しくても転送やアプリケーションの健全性までは検証できません。

観測値が期待される経路と最初に異なるレイヤーで確認を止めます。そのレイヤーだけを修正し、両方の列を再確認してください。リモート側の修正によってローカルのヘアピン動作が壊れる可能性があるためです。到達性が確立したと判断できるのは、ホスト名が解決したときではなく、意図した両方の経路で同じアプリケーションリクエストが完了したときです。