Dlaczego nazwa hosta NAS jest rozpoznawana na niektórych urządzeniach domowych, a na innych nie?

Nazwa hosta NAS rozwiązuje się niespójnie, gdy urządzenia nie używają tej samej metody nazewnictwa, resolvera, sufiksu lub pamięci podręcznej odpowiedzi.

W sieci domowej jeden laptop może znaleźć nas przez DNS routera, Mac może znaleźć nas.local przez multicast DNS, komputer z Windows może użyć LLMNR lub NetBIOS, a telefon może wysłać to samo zapytanie do Prywatnego DNS, VPN lub filtrowanego resolvera. Przydatną diagnozą jest więc porównanie dokładnej nazwy i ścieżki IP na jednym działającym urządzeniu i jednym niedziałającym, zanim zmienimy ustawienia NAS, routera lub SMB.

Sprawdź, czy problem dotyczy rozwiązywania nazw czy dostępu do NAS

Przetestuj NAS po jego aktualnym adresie IP zarówno na działającym, jak i niedziałającym urządzeniu. Następnie przetestuj krótką nazwę hosta, w pełni kwalifikowaną nazwę lokalną oraz dowolną formę .local osobno, zamiast traktować je jako wymienne.

Test nazwy hosta dodaje krok resolvera przed połączeniem SMB, HTTP lub inną usługą. Przewodnik ZimaSpace dotyczący sprawdzania serwera domowego po nazwie wyjaśnia, dlaczego dostęp do nazwy hosta dodaje rozwiązywanie DNS do ścieżki, której bezpośredni dostęp po IP nie wymaga.

Jeśli IP działa na obu urządzeniach, ale tylko jedno rozwiązuje nazwę, kontynuuj badanie na warstwie resolvera. Jeśli IP również nie działa, najpierw napraw VLAN, izolację Wi-Fi, zaporę, routing lub dostępność usługi, ponieważ zmiana DNS nie naprawi zablokowanej ścieżki sieciowej.

Porównaj serwer DNS używany przez każde urządzenie

Zanotuj serwery DNS, typ połączenia, bramę i aktywny profil sieciowy na działającym i niedziałającym urządzeniu. Dwa klienty w tej samej sieci Wi-Fi mogą używać różnych resolverów z powodu ustawień ręcznych, konfiguracji węzłów mesh, oprogramowania VPN, bezpiecznego DNS w przeglądarce lub mobilnego Prywatnego DNS.

Lokalne rozwiązywanie nazw podąża za specyficzną dla systemu operacyjnego kolejnością, która może łączyć mDNS, LLMNR i unicast DNS. Klient pytający router może otrzymać lokalny rekord NAS, podczas gdy klient pytający publiczny resolver otrzyma NXDOMAIN, ponieważ ta prywatna nazwa hosta nie istnieje w publicznym internecie.

Zapytaj dokładnie skonfigurowany serwer DNS bezpośrednio z obu urządzeń i porównaj odpowiedź, kod odpowiedzi i zwrócony adres. Jeśli router odpowiada poprawnie, ale niedziałający klient nigdy go nie pyta, napraw dystrybucję DNS DHCP, nadpisanie klienta, politykę DNS VPN lub ustawienie szyfrowanego DNS zamiast edytować nazwę hosta NAS.

Oddziel krótkie nazwy hostów od mDNS i innych lokalnych mechanizmów zapasowych

Przetestuj nas, pełną lokalną nazwę routera, taką jak nas.home.arpa lub nas.lan, oraz nas.local jako trzy różne wejścia. Sukces jednej formy nie dowodzi, że pozostałe są skonfigurowane.

Lokalne protokoły zapasowe nie zachowują się identycznie na różnych systemach operacyjnych. Praktyczna dyskusja o Windows pokazuje, że wyłączenie NetBIOS, mDNS lub LLMNR nie powoduje automatycznie, że krótkie nazwy LAN używają DNS; klient nadal potrzebuje ważnego rekordu DNS i ścieżki sufiksu.

Jeśli działa tylko nas.local, NAS prawdopodobnie reklamuje mDNS, ale router nie serwuje konwencjonalnego lokalnego rekordu DNS. Jeśli działa tylko pełna nazwa domeny routera, dodaj lub rozprowadź poprawny sufiks wyszukiwania zamiast polegać na zapasowej krótkiej nazwie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź, czy urządzenie obsługuje metodę wykrywania, której używasz

Zachowaj NAS i router bez zmian, a następnie przetestuj tę samą nazwę z innego urządzenia z tym samym systemem operacyjnym co niedziałający klient. To oddziela różnicę implementacji urządzenia od problemu DNS w całej sieci.

Prawdziwe sieci mieszane mogą pokazać dokładnie taki podział: urządzenie z Androidem może nie rozwiązywać adresu .local, podczas gdy Windows, iPhone i macOS w tej samej sieci LAN radzą sobie dobrze. Udokumentowany przypadek opisuje błąd rozwiązywania mDNS na Androidzie mimo że inni klienci rozwiązywali tę samą nazwę.

Jeśli objaw dotyczy jednego systemu operacyjnego lub aplikacji, użyj konwencjonalnego rekordu DNS routera lub w pełni kwalifikowanej lokalnej domeny, którą wszyscy wymagani klienci mogą zapytać. Nie projektuj krytycznych montowań SMB, ścieżek kopii zapasowych ani wywołań zwrotnych wokół metody wykrywania, którą obsługuje tylko część gospodarstwa domowego.

Przetestuj sufiks wyszukiwania i dokładne zapytanie wysłane przez niedziałający klient

Nazwa jednoelementowa, taka jak nas, może wymagać specyficznego dla połączenia sufiksu, zanim stanie się pełnym zapytaniem DNS. Porównaj listę sufiksów niedziałającego urządzenia z działającym i przetestuj pełną nazwę bezpośrednio.

Użytkownicy OpenWrt zgłaszali przypadki, gdzie rozwiązywanie krótkich nazw hostów działało, podczas gdy krótkie nazwy nie działały na innych klientach. Różnica często wynika z sufiksu dodawanego przez system operacyjny, a nie z samego rekordu NAS.

Jeśli nas.example.lan działa, ale nas nie, rozprowadź tę samą domenę wyszukiwania przez DHCP lub zapisz pełną nazwę w montowaniach SMB i zakładkach. Unikaj tworzenia wielu nieoficjalnych sufiksów, które rozwiązywane są różnie przez DNS routera, Pi-hole, AdGuard Home i pliki hosts klientów.

Wyczyść stan klienta dopiero po poprawieniu ścieżki resolvera

Gdy oba urządzenia używają tego samego resolvera i formy nazwy, wyczyść pamięć podręczną DNS niedziałającego klienta, rozłącz i ponownie połącz jego profil sieciowy, a następnie przetestuj ponownie w świeżej przeglądarce lub powłoce. Buforowane odpowiedzi NXDOMAIN mogą przetrwać poprawkę po stronie routera.

Wybór resolvera może też dryfować, gdy system operacyjny wysyła zapytanie do multicastu lub lokalnego stubu zamiast oczekiwanego serwera DNS. Raport rozwiązywania problemów Fedora zarejestrował klienta używającego niespójnego lokalnego rozwiązywania, mimo że konfiguracja DNS sieci wydawała się poprawna.

Na koniec spraw, by każde wymagane urządzenie rozwiązywało wybraną nazwę na zarezerwowany adres NAS, a następnie potwierdź, że SMB, panel sterowania i aplikacje self-hosted łączą się ponownie przez tę nazwę. Zachowaj test IP jako diagnostyczną rezerwę, ale używaj jednego udokumentowanego systemu nazewnictwa zamiast polegać na przypadkowych protokołach zapasowych.