DNSがImmichへの接続障害を引き起こしているか確認する方法

エヴァ・ウォン

IceWhale author

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

How to Test Whether DNS Is Causing Immich Connection Failures - Zima Store Online

DNSがImmichの原因である可能性が高いのは、障害が発生しているクライアントが、使用すべきアドレスに正確なImmichホスト名を解決できない場合、またはその応答がリゾルバー、ネットワーク、時間によって変化する場合だけです。

名前解決とアプリケーションへの到達性を分けてテストします。IPレベルの接続に成功しても、経路とポートが存在することは示せますが、ホスト名なしでHTTPS、リバースプロキシのルーティング、証明書、ホストベースのルールが機能することまでは証明できません。最も安全な手順は、正確に失敗している名前を記録し、影響を受けたクライアントから問い合わせ、リゾルバーを比較してから、DNS層を1つ変更した後に元のImmich操作を再実行することです。

正確なホスト名と障害経路を定義する

障害が発生しているImmichクライアントが実際に使用しているホスト名、接続しているネットワーク、障害が発生した時刻、そして障害がWebアプリ、モバイルアプリ、またはその両方に影響しているかを記録します。無関係な公開ドメインを解決するような一般的なテストから始めないでください。それでは、一部のDNS経路が機能していることしか確認できません。

同じホスト名を、正常に動作するクライアントと障害が発生しているクライアントから比較します。すべてのAおよびAAAA応答、応答したリゾルバー、クライアントがホームネットワーク内、モバイルデータ通信中、またはVPN経由のどこにあるかを記録します。スプリットDNSでは異なる応答が意図的な場合もありますが、それでも各クライアントが到達可能なエンドポイントに接続できなければなりません。

切り分けのため、通常のDNS検索に依存せず、想定されるサーバーアドレスとポートに到達できるかをテストします。これはネットワーク経路を切り分けるためだけのテストと考えてください。サービスが正常でも、HTTPS証明書、SNI、リバースプロキシ、バーチャルホストによって、IPアドレス宛てのリクエストが拒否されることがあります。

サーバーだけでなく障害が発生しているクライアントからDNSを問い合わせる

実際に障害が発生しているデバイスまたは環境上でDNSクエリを実行します。ImmichクライアントがVPN、プライベートDNSプロファイル、コンテナのスタブリゾルバー、またはルーターが提供するリゾルバーの背後にある場合、サーバー自体からの問い合わせでは異なるリゾルバー経路が使われ、問題が隠れる可能性があります。

まずクライアントのデフォルトリゾルバーを通して障害が発生しているホスト名を問い合わせ、次に既知の比較用リゾルバーまたは意図した内部リゾルバーを明示的に指定して問い合わせます。対象を絞ったdigクエリでは、返された応答、応答したサーバー、ステータス、クエリ時間を確認できるため、障害が特定のリゾルバーに追随するかどうかを確認できます。

1回の成功だけを信用せず、クエリを複数回繰り返します。NXDOMAIN、SERVFAIL、タイムアウト、古いアドレス、一貫しないA/AAAA応答を記録します。正しく安定した応答が返るなら、基本的なDNS名前解決の疑いは薄れ、ルーティング、プロキシ、TLS、ファイアウォール、またはアプリケーション設定に焦点を移します。

リゾルバーの結果とエラーの種類を比較する

設定を変更する前に、応答コードを解釈します。NXDOMAINは、そのリゾルバーから見て問い合わせた名前が存在しないことを意味します。SERVFAILは名前解決を完了できなかったことを意味します。タイムアウトは、リゾルバーが時間内に応答しなかったことを意味します。構文上は有効な応答でも、古いルーターアドレスや到達不能なエンドポイントを指していれば誤りです。

名前が見つからない障害と、一時的なリゾルバー障害は別の分岐です。名前解決エラーの違いを使って、欠落しているレコード、到達不能なリゾルバー、不安定なDNS経路のどれを修正すべきか判断します。すべての名前解決失敗を同じ問題として扱わないでください。

ホームネットワークのリゾルバーだけが古いアドレスや誤ったアドレスを返し、別のリゾルバーが意図した公開アドレスを返す場合は、ローカルの上書き設定、スプリットDNSレコード、DHCPから提供されたDNS、フィルタリングサービス、キャッシュを調べます。すべてのリゾルバーが同じ正しいアドレスを返す場合は、DNSの変更をやめてサービス経路の調査に進みます。

Featured

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

ZimaCube2

制御されたバイパスを使ってDNSの関与を確認または否定する

障害が発生しているクライアントの名前解決だけを変更する、一時的で元に戻せる制御を1つ作成します。たとえば、別のリゾルバーに直接問い合わせるか、一時的なhostsファイルのエントリを使って、正確なImmichホスト名を既知の意図したエンドポイントに割り当てます。テストをすぐ元に戻せるよう、元の設定を保存しておきます。

ホスト名は同じままで、解決経路だけを変更した際に元のImmichワークフローが動作し始めるなら、DNSが強く疑われます。同じホスト名が確認済みのエンドポイントに解決された後も失敗するなら、障害はDNSより下流にあり、プロキシのルーティング、証明書、NAT、ファイアウォールルール、またはImmichサービス自体を調査する必要があります。

1回の正常なクエリで家庭内の障害発生時間帯を再現できない場合は、ホスト、コンテナ、ローカルリゾルバー、上流リゾルバー、DHCP、VPN、キャッシュの状態を時間の経過に沿って比較します。多層DNS障害チェックを使うと、1回限りのテスト中には消えてしまう断続的な問題を検出しやすくなります。

適切なキャッシュを消去して、元のImmichワークフローを再テストする

DNSレコード、リゾルバー、DHCPオプション、スプリットDNSルール、またはローカルの上書き設定を修正した後、可能であれば関係するクライアントまたはリゾルバーのキャッシュだけを消去します。変更内容を記録せずにすべての層を何度もフラッシュしないでください。一時的な成功の理由を説明できなくなる可能性があります。

影響を受けたクライアントからホスト名を再度解決し、意図したA/AAAA応答、リゾルバー、応答時間を確認します。その後、通常のホスト名でImmichを開き、古いアセットを読み込み、検索し、安全なアップロードを1回行うか、その他の書き込み操作を実行して、ログインページだけでなく複数の機能をテストします。

モバイルデータ通信、ホームWi-Fi、VPN接続中のWi-Fi、またはルーターやDHCPを更新した後など、最初に障害が発生したネットワーク状態でチェックを繰り返します。以前障害を引き起こした条件下でも通常のホスト名が正しい状態を維持して初めて、DNSを根本原因から除外できます。それ以外の場合は新たな証拠を保存し、次のネットワーク層の調査を続けます。