LLMNR nie działa – brak rozgłoszeń nazw

LLMNR (Link-Local Multicast Name Resolution) niedziałające oznacza brak rozgłoszeń nazw w sieci lokalnej — usługa bywa celowo wyłączana ze względów bezpieczeństwa (podatność na spoofing).

LLMNR nie działa – czym oznacza brak rozgłoszeń nazw

LLMNR, czyli Link-Local Multicast Name Resolution, jest mechanizmem pomocniczym stosowanym w lokalnej sieci komputerowej. Umożliwia odnalezienie urządzenia na podstawie jego nazwy wtedy, gdy zapytanie nie zostanie rozstrzygnięte przez DNS. Komputer wysyła wówczas komunikat multicast do urządzeń znajdujących się w tym samym segmencie sieci, a sprzęt rozpoznający podaną nazwę może odpowiedzieć własnym adresem IP. Dzięki temu możliwe bywa odwołanie do zasobu za pomocą nazwy urządzenia zamiast wpisywania adresu liczbowego.

Komunikat „LLMNR nie działa” albo brak rozgłoszeń nazw nie musi oznaczać awarii karty sieciowej. Najczęściej wskazuje na to, że system nie wysyła zapytań LLMNR, nie nasłuchuje odpowiedzi lub przechodzi do innego sposobu rozwiązywania nazw. Funkcja może zostać wyłączona przez zasady bezpieczeństwa, konfigurację systemu, ustawienia zapory albo reguły obowiązujące w danej sieci. W nowoczesnych środowiskach ograniczenie LLMNR bywa zamierzone, ponieważ protokół nie zapewnia takiej ochrony jak poprawnie skonfigurowany DNS.

Sam brak odpowiedzi LLMNR nie przesądza jeszcze o uszkodzeniu sprzętu. Istotne jest ustalenie, czy problem dotyczy wyłącznie nazw lokalnych, czy również dostępu do adresów IP, bramy sieciowej i usług internetowych. Jeżeli połączenie z siecią działa po wpisaniu adresu IP, lecz odwołanie do nazwy urządzenia kończy się błędem, podejrzenie kieruje się przede wszystkim na rozwiązywanie nazw, ustawienia protokołów i reguły zapory.

LLMNR na tle DNS, NetBIOS i innych metod rozpoznawania urządzeń

DNS jest podstawowym mechanizmem tłumaczenia nazw na adresy IP i powinien stanowić główne źródło informacji w uporządkowanej sieci. LLMNR działa lokalnie i awaryjnie, bez konieczności korzystania z centralnego serwera DNS. Z tego powodu może być przydatny w małych sieciach, podczas testów lub przy tymczasowym łączeniu urządzeń, lecz nie powinien zastępować prawidłowej konfiguracji DNS. Jeżeli nazwa ma być dostępna stale i przewidywalnie, lepiej zapewnić jej obsługę w odpowiedniej strefie DNS lub w lokalnym pliku hosts, zależnie od skali i sposobu zarządzania środowiskiem.

Podobną funkcję historycznie spełniało NetBIOS Name Service, wykorzystywane między innymi do odnajdywania komputerów w starszych konfiguracjach systemu Windows. Oba mechanizmy mogą działać niezależnie, dlatego wyłączenie LLMNR nie zawsze powoduje całkowity zanik wszystkich nazw lokalnych. Jednocześnie korzystanie z kilku metod naraz utrudnia diagnozę: urządzenie może być widoczne dzięki jednej usłudze, a niedostępne po wyłączeniu innej. Warto więc ustalić, z jakiego mechanizmu korzysta konkretna aplikacja lub polecenie.

Weryfikacja powinna obejmować między innymi stan interfejsu sieciowego, przydzielony adres IP, maskę, bramę i adresy DNS. Pomocne jest porównanie wyników odwołania do nazwy oraz bezpośredniego połączenia z adresem IP. Należy także sprawdzić, czy urządzenia znajdują się w tej samej podsieci, czy sieć nie jest oznaczona jako publiczna oraz czy izolacja klientów bezprzewodowych nie blokuje komunikacji między nimi. W sieciach podzielonych na VLAN-y brak lokalnych rozgłoszeń może być naturalnym skutkiem projektu, a nie błędem konfiguracji.

Włączenie LLMNR bez oceny ryzyka nie zawsze jest właściwym rozwiązaniem. Protokół może ułatwiać podszywanie się pod urządzenie odpowiadające na zapytanie, przechwytywanie nazw oraz nakłanianie użytkownika do połączenia z niewłaściwym adresem. Dlatego w środowisku, w którym wymagana jest kontrola i przewidywalność, korzystniejsze może być pozostawienie LLMNR wyłączonego i naprawienie konfiguracji DNS.

Typowe przyczyny braku rozgłoszeń nazw

Jedną z częstych przyczyn jest ustawienie zasad systemowych, które wyłącza LLMNR dla wszystkich profili sieciowych albo tylko dla określonego typu połączenia. Taka zmiana może pochodzić z lokalnej konfiguracji zabezpieczeń, skryptu administracyjnego, programu ochronnego lub centralnie narzuconej polityki. W efekcie opcja może wyglądać na niedostępną w interfejsie użytkownika, mimo że wcześniej działała bez dodatkowych działań.

Drugim źródłem problemów bywa zapora sieciowa. Reguły blokujące ruch multicast, komunikację lokalną lub odpowiednie składniki systemu mogą uniemożliwić wysłanie zapytania albo odebranie odpowiedzi. Nie należy jednak wyłączać całej zapory w celu szybkiego testu. Bezpieczniejsza jest kontrola konkretnych reguł, profilu sieciowego i dzienników zdarzeń, a następnie wykonanie ograniczonej próby w kontrolowanych warunkach.

Znaczenie ma również topologia sieci. LLMNR jest mechanizmem lokalnym, więc rozgłoszenia nie muszą przechodzić przez router, tunel VPN, punkt dostępu z izolacją urządzeń ani granicę innej podsieci. W sieci bezprzewodowej urządzenia mogą mieć dostęp do internetu, lecz nie mogą komunikować się bezpośrednio ze sobą. Podobny efekt wystąpi po podłączeniu jednego komputera do sieci gościnnej, a drugiego do sieci prywatnej.

Nieprawidłowy profil sieci, uszkodzony stos TCP/IP, błędny wpis DNS lub pozostałości po dawnym oprogramowaniu sieciowym również mogą powodować mylące objawy. Czasami nazwa jest poprawnie rozpoznawana, lecz aplikacja odrzuca połączenie z powodu wyłączonego udostępniania, niezgodnych uprawnień albo blokady portu. Z tego względu samo przywrócenie LLMNR nie rozwiąże problemu, jeżeli właściwa przyczyna znajduje się w innej warstwie.

W diagnostyce warto rozdzielić kilka pytań: czy komputer ma prawidłowy adres, czy widzi bramę, czy rozwiązuje nazwy DNS, czy odpowiada na zapytania lokalne i czy usługa docelowa rzeczywiście działa. Przydatne są testy wykonywane z więcej niż jednego urządzenia, porównanie połączenia przewodowego i bezprzewodowego oraz obserwacja, czy błąd występuje po ponownym uruchomieniu. Zapisanie dokładnego komunikatu i momentu pojawienia się usterki ogranicza ryzyko przypadkowej zmiany ustawień.

W jakich sytuacjach warto oddać urządzenie do diagnozy - LLMNR nie działa – brak rozgłoszeń nazw

Zgłoszenie do serwisu jest uzasadnione, gdy problem z nazwami pojawia się razem z przerywaniem połączenia, znikaniem interfejsu sieciowego, nieprawidłowym działaniem sterownika lub brakiem dostępu do urządzeń, które wcześniej były widoczne. Warto skorzystać z pomocy także wtedy, gdy nie wiadomo, czy wyłączenie LLMNR wynika z polityki bezpieczeństwa, błędu systemu czy zmian w routerze. Szczególnie ostrożnie należy postępować w sytuacji, gdy po modyfikacji ustawień zaczynają występować kolejne problemy z udostępnianiem plików lub połączeniami lokalnymi.

W serwisie Warszawskie Pogotowie Komputerowe 24/7 można rozpocząć od oceny komputera przenośnego, przy czym stosowana jest darmowa diagnoza LAPTOPA. Sprawdzane są objawy związane z konfiguracją sieci, działaniem systemu, sterownikami oraz komunikacją między urządzeniami, a dalsze czynności dobiera się do ustalonej przyczyny. Do zgłoszenia warto przygotować nazwę urządzenia, informację o rodzaju połączenia, opis sytuacji, wyniki podstawowych testów oraz dane o ostatnich zmianach w konfiguracji.

Przed przekazaniem sprzętu można zanotować, czy nazwy lokalne nie działają na jednym komputerze, czy na wszystkich urządzeniach, oraz czy połączenie przez adres IP nadal jest możliwe. Pomocne będzie także wskazanie, czy problem dotyczy sieci domowej, biurowej, bezprzewodowej lub uruchomionej przez VPN. Takie informacje ułatwiają odróżnienie awarii komputera od ograniczenia zastosowanego w infrastrukturze sieciowej.

Nie zaleca się trwałego włączania LLMNR wyłącznie po to, aby ukryć objaw. Jeżeli mechanizm został wyłączony z powodów bezpieczeństwa, właściwym kierunkiem może być uporządkowanie DNS, sprawdzenie profili sieciowych albo usunięcie konfliktu w zaporze. Dopiero po ustaleniu zależności między ustawieniami a objawem można zdecydować, czy przywrócenie rozgłoszeń nazw jest potrzebne i bezpieczne w danym środowisku.