Jak sprawdzić, czy DNS powoduje problemy z połączeniem z Immich

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

DNS jest prawdopodobną przyczyną problemów z Immich tylko wtedy, gdy klient, na którym występuje błąd, nie potrafi zamienić dokładnej nazwy hosta Immich na adres, który powinien ją obsługiwać, albo gdy ta odpowiedź zmienia się w zależności od resolvera, sieci lub czasu.

Testuj rozpoznawanie nazw oddzielnie od dostępności aplikacji. Pomyślne połączenie na poziomie IP może wykazać, że istnieje trasa i port, ale nie dowodzi, że HTTPS, routing odwrotnego proxy, certyfikaty ani reguły oparte na hoście zadziałają bez nazwy hosta. Najbezpieczniejszy schemat postępowania polega na zapisaniu dokładnej nazwy, której dotyczy błąd, odpytaniu jej z urządzenia, na którym występuje problem, porównaniu resolverów, a następnie powtórzeniu pierwotnej czynności w Immich po jednej zmianie na warstwie DNS.

Określ dokładną nazwę hosta i ścieżkę błędu

Zapisz nazwę hosta, której faktycznie używa klient Immich powodujący błąd, sieć, w której się znajduje, czas wystąpienia błędu oraz informację, czy problem dotyczy aplikacji internetowej, aplikacji mobilnej, czy obu. Nie zaczynaj od ogólnego testu, takiego jak rozpoznanie niezwiązanej z problemem domeny publicznej, ponieważ dowodzi on jedynie, że jakaś ścieżka DNS działa.

Porównaj tę samą nazwę hosta na działającym i niesprawnym kliencie. Zapisz każdą odpowiedź A i AAAA, resolver, który odpowiedział, oraz informację, czy klient znajduje się w sieci domowej, korzysta z danych komórkowych czy działa za pośrednictwem VPN. Różne odpowiedzi mogą być zamierzone w przypadku rozdzielonego DNS, ale nadal muszą kierować każdego klienta do dostępnego punktu końcowego.

Testowo sprawdź, czy oczekiwany adres serwera i port są dostępne bez polegania na standardowym wyszukiwaniu DNS. Traktuj to wyłącznie jako sposób rozróżnienia ścieżki sieciowej: certyfikaty HTTPS, SNI, odwrotne proxy i hosty wirtualne nadal mogą odrzucać żądanie oparte na adresie IP, nawet gdy usługa działa prawidłowo.

Odpytuj DNS z niesprawnego klienta, a nie tylko z serwera

Wykonaj zapytanie DNS na urządzeniu lub w środowisku, w którym faktycznie występuje problem. Jeśli klient Immich działa za pośrednictwem VPN, prywatnego profilu DNS, lokalnego resolvera kontenera lub resolvera udostępnianego przez router, zapytanie z samego serwera może korzystać z innej ścieżki resolvera i ukryć problem.

Najpierw odpytaj problematyczną nazwę hosta za pośrednictwem domyślnego resolvera klienta, a następnie jawnie użyj znanego resolvera porównawczego lub zamierzonego resolvera wewnętrznego. Ukierunkowane zapytanie dig pokazuje zwróconą odpowiedź, serwer odpowiadający, status i czas zapytania, dzięki czemu można sprawdzić, czy błąd występuje tylko przy jednym resolverze.

Powtórz zapytanie kilka razy zamiast ufać pojedynczemu udanemu wynikowi. Zapisz odpowiedzi NXDOMAIN, SERVFAIL, przekroczenia czasu, nieaktualne adresy lub niespójne odpowiedzi A/AAAA. Stabilna i prawidłowa odpowiedź kieruje podejrzenia z dala od podstawowego rozpoznawania DNS, w stronę routingu, proxy, TLS, zapory sieciowej lub konfiguracji aplikacji.

Porównaj wyniki resolverów i typy błędów

Przed zmianą ustawień zinterpretuj kod odpowiedzi. NXDOMAIN oznacza, że z perspektywy tego resolvera żądana nazwa nie istnieje; SERVFAIL oznacza, że nie udało się ukończyć rozpoznawania; przekroczenie czasu oznacza, że resolver nie odpowiedział w wymaganym czasie. Odpowiedź poprawna składniowo nadal może być błędna, jeśli wskazuje stary adres routera lub niedostępny punkt końcowy.

Błędy informujące o nieznalezieniu nazwy i tymczasowe awarie resolvera to różne ścieżki diagnostyczne. Skorzystaj z różnic między błędami rozpoznawania nazw, aby ustalić, czy należy naprawić brakujący rekord, niedostępny resolver czy niestabilną ścieżkę DNS, zamiast traktować każde nieudane wyszukiwanie jako ten sam problem.

Jeśli tylko domowy resolver zwraca stary lub błędny adres, podczas gdy inny resolver zwraca zamierzoną wartość publiczną, sprawdź lokalne nadpisania, rekordy rozdzielonego DNS, DNS dostarczany przez DHCP, usługi filtrujące i pamięci podręczne. Jeśli każdy resolver zwraca ten sam prawidłowy adres, przestań zmieniać DNS i przejdź do ścieżki usługi.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Użyj kontrolowanego obejścia, aby potwierdzić lub wykluczyć DNS

Utwórz jedno tymczasowe, odwracalne obejście, które zmieni wyłącznie sposób rozpoznawania nazw na niesprawnym kliencie. Możesz na przykład bezpośrednio odpytąć inny resolver albo tymczasowo dodać do pliku hosts wpis mapujący dokładną nazwę hosta Immich na znany, zamierzony punkt końcowy. Zachowaj oryginalne ustawienia, aby natychmiast cofnąć test.

Jeśli pierwotny przepływ pracy w Immich zacznie działać, podczas gdy nazwa hosta pozostanie identyczna, a zmieni się wyłącznie ścieżka jej rozpoznawania, DNS jest bardzo prawdopodobną przyczyną. Jeśli ta sama nazwa hosta nadal będzie powodować błąd po rozpoznaniu jej na zweryfikowany punkt końcowy, problem występuje za warstwą DNS i należy sprawdzić routing proxy, certyfikaty, reguły NAT, zaporę sieciową lub samą usługę Immich.

Jeśli pojedyncze poprawne zapytanie nie odtwarza problemu występującego w gospodarstwie domowym, porównuj w czasie stan hosta, kontenera, lokalnego resolvera, resolvera nadrzędnego, DHCP, VPN i pamięci podręcznej. Wielowarstwowa kontrola awarii DNS pomaga wykryć sporadyczne przypadki, które znikają podczas jednorazowego testu.

Wyczyść właściwą pamięć podręczną i ponownie przetestuj pierwotny przepływ pracy Immich

Po poprawieniu rekordu DNS, resolvera, opcji DHCP, reguły rozdzielonego DNS lub lokalnego nadpisania wyczyść, jeśli to możliwe, tylko pamięć podręczną odpowiedniego klienta lub resolvera. Nie opróżniaj wielokrotnie pamięci podręcznej na każdej warstwie bez zapisywania wprowadzonych zmian, ponieważ może to uniemożliwić wyjaśnienie chwilowego powodzenia.

Ponownie rozpoznaj nazwę hosta z niesprawnego klienta i sprawdź zamierzoną odpowiedź A/AAAA, resolver oraz czas odpowiedzi. Następnie otwórz Immich za pomocą standardowej nazwy hosta, wczytaj starsze zasoby, wykonaj wyszukiwanie i bezpieczne przesłanie jednego pliku lub inną operację zapisu, aby test obejmował więcej niż sam ekran logowania.

Powtórz kontrolę w stanie sieci, w którym pierwotnie występował problem, na przykład przy korzystaniu z danych komórkowych, domowej sieci Wi-Fi, sieci Wi-Fi z aktywnym VPN-em lub po odnowieniu dzierżawy routera/DHCP. DNS można wykluczyć jako główną przyczynę dopiero wtedy, gdy standardowa nazwa hosta pozostaje prawidłowa w sytuacji, która wcześniej powodowała awarię; w przeciwnym razie zachowaj nowe dowody i kontynuuj diagnostykę na kolejnej warstwie sieci.