DNS nie działa w maszynie wirtualnej

DNS nie działa w maszynie wirtualnej wskazuje na tryb sieci wirtualnej (np. NAT bez przekazania DNS) niepoprawnie skonfigurowany w ustawieniach hypervisora.

Czym oznacza brak działania DNS w maszynie wirtualnej

Komunikat lub objaw „DNS nie działa w maszynie wirtualnej” oznacza, że uruchomiony system gościa nie potrafi zamienić nazwy domenowej, takiej jak example.org, na odpowiadający jej adres IP. W takiej sytuacji połączenie sieciowe może wyglądać na aktywne, a mimo to przeglądarka, menedżer pakietów, klient poczty albo narzędzia administracyjne nie otwierają stron i usług wskazywanych nazwą. Sam dostęp do sieci nie zawsze jest całkowicie przerwany. Często można połączyć się z adresem IP, wykonać polecenie ping do znanego hosta liczbowego lub sprawdzić interfejs sieciowy, lecz zapytania o nazwy pozostają bez odpowiedzi.

DNS, czyli Domain Name System, działa jak rozproszony mechanizm wyszukiwania nazw. System operacyjny maszyny wirtualnej otrzymuje adres jednego lub kilku serwerów DNS, wysyła do nich zapytania i korzysta z otrzymanych rekordów. Jeżeli konfiguracja interfejsu sieciowego, pliku resolvera albo wirtualnej karty sieciowej jest nieprawidłowa, nazwy nie zostaną rozpoznane. Problem może dotyczyć wyłącznie maszyny wirtualnej, podczas gdy system gospodarza i inne urządzenia w tej samej sieci działają poprawnie.

Warto rozdzielić trzy elementy diagnozy: stan wirtualnego interfejsu, możliwość dotarcia do bramy sieciowej oraz działanie samego resolvera DNS. Brak adresu IP lub bramy wskazuje na problem z przydzielaniem parametrów sieciowych. Odpowiedź bramy przy jednoczesnym braku odpowiedzi serwera DNS kieruje uwagę na ustawienia resolvera, zaporę albo reguły przekazywania zapytań. Z kolei poprawna odpowiedź DNS przy niedostępnych stronach może oznaczać kłopot z trasowaniem, filtrowaniem ruchu lub konfiguracją konkretnej aplikacji.

Kontekst techniczny i porównanie trybów sieci

Najczęstszą przyczyną jest niedopasowanie trybu sieci w oprogramowaniu obsługującym maszynę wirtualną do oczekiwanego sposobu dostępu. W trybie NAT maszyna korzysta z pośrednictwa systemu gospodarza. Wirtualna warstwa zwykle przydziela własny adres, bramę i serwer DNS, a następnie przekazuje ruch do sieci zewnętrznej. Jeśli usługa odpowiedzialna za to przekazywanie nie działa, została ograniczona przez zaporę albo nie otrzymała poprawnych parametrów, dostęp do nazw może zostać utracony.

Tryb mostkowany pozwala maszynie wirtualnej zachowywać się bardziej podobnie do osobnego urządzenia w sieci lokalnej. Adres IP i pozostałe dane mogą być wtedy pobierane bezpośrednio z lokalnego serwera DHCP. Nieprawidłowe filtrowanie ruchu, ograniczenia punktu dostępowego lub brak obsługi dodatkowego adresu w sieci mogą jednak sprawić, że system gościa nie otrzyma konfiguracji. W takim przypadku DNS nie jest pierwotną przyczyną, lecz jednym z objawów nieudanego połączenia.

Wirtualny przełącznik prywatny lub wewnętrzny umożliwia komunikację między wybranymi maszynami, lecz może nie zapewniać wyjścia do Internetu. Przy takim ustawieniu zapytania DNS zostaną obsłużone tylko wtedy, gdy w sieci istnieje dostępny resolver albo skonfigurowano odpowiednie przekazywanie. Odmiennie działa sieć host-only, przeznaczona przede wszystkim do komunikacji z systemem gospodarza. Próba używania jej jako pełnego połączenia internetowego może prowadzić do błędnego wniosku, że awaria dotyczy wyłącznie DNS.

W systemach Linux należy sprawdzić między innymi zawartość konfiguracji resolvera, status usługi zarządzającej siecią oraz wyniki poleceń ip addr, ip route i resolvectl status, o ile są dostępne. W systemach Windows pomocne bywają polecenia ipconfig /all, nslookup i ipconfig /flushdns. Narzędzia te nie naprawiają konfiguracji wirtualnej, lecz pozwalają ustalić, czy system otrzymał adres DNS, czy zna bramę i czy potrafi wysłać zapytanie do wskazanego serwera.

Typowe problemy i błędy konfiguracyjne - DNS nie działa w maszynie wirtualnej

Jednym z częstych błędów jest ręczne wpisanie adresu DNS bez sprawdzenia, czy maszyna ma prawidłową trasę do tego adresu. Sam wpis w ustawieniach nie wystarczy, gdy interfejs nie ma aktywnej bramy albo ruch UDP i TCP na porcie 53 jest blokowany. Podobny skutek daje pozostawienie starej konfiguracji po zmianie trybu NAT na mostkowany lub po przeniesieniu maszyny na inną sieć.

Problemy mogą powodować również nieuruchomione usługi sieciowe w systemie gościa. Dotyczy to zwłaszcza konfiguracji, w której interfejs otrzymuje adres, ale nie aktualizuje danych resolvera. W Linuxie winna bywa kolizja kilku mechanizmów zarządzania siecią, na przykład jednoczesne sterowanie ustawieniami przez różne usługi. W Windows przyczyną może być uszkodzony stos sieciowy, nieaktualny sterownik wirtualnej karty albo reguła zapory przypisana do niewłaściwego profilu sieciowego.

Nie należy pomijać konfliktu adresów. Jeśli dwie maszyny otrzymają ten sam adres IP albo w sieci pojawi się nieprawidłowa odpowiedź ARP, zapytania DNS mogą docierać do niewłaściwego urządzenia. W środowiskach testowych zdarzają się także niezgodne zakresy adresów, na przykład brama znajduje się poza podsiecią przypisaną interfejsowi. Objawem bywa częściowa łączność: pojedyncze adresy są osiągalne, ale większość nazw nie działa.

Warto sprawdzić, czy problem występuje dla wszystkich nazw, czy tylko dla jednej domeny. Brak odpowiedzi dla każdej nazwy sugeruje awarię resolvera, trasowania lub zapory. Błąd dotyczący jednej domeny może wynikać z nieaktualnego rekordu, lokalnego cache, niewłaściwego serwera autorytatywnego albo ograniczeń DNSSEC. Pomocne jest porównanie zapytania przez nazwę z połączeniem do znanego adresu IP oraz wykonanie testu z systemu gospodarza i z innego urządzenia w tej samej sieci.

Przywracanie ustawień bez zapisania stanu wyjściowego często utrudnia późniejszą diagnozę. Przed zmianami dobrze zachować informacje o adresie IP, masce, bramie, serwerach DNS, wybranym trybie sieci i statusie wirtualnego interfejsu. Jeżeli maszyna jest używana do pracy testowej, należy również uwzględnić lokalne reguły zapory, tunel VPN, filtr antywirusowy oraz ustawienia proxy. Każdy z tych elementów może sprawiać wrażenie awarii DNS, mimo że właściwy resolver działa poprawnie.

Kiedy najlepiej przekazać urządzenie do naprawy - DNS nie działa w maszynie wirtualnej

Zgłoszenie do serwisu jest uzasadnione, gdy podstawowe testy nie wskazują jednoznacznie, czy źródłem problemu jest system gościa, komputer gospodarza, konfiguracja wirtualnej sieci czy urządzenie sieciowe. Szczególnej uwagi wymaga sytuacja, w której DNS przestaje działać po aktualizacji systemu, zmianie sterownika, migracji maszyny wirtualnej albo przełączeniu połączenia między siecią domową i firmową. Samodzielne zmiany wykonywane bez rozpoznania zależności mogą doprowadzić do utraty dostępu nie tylko w maszynie wirtualnej, lecz także w systemie gospodarza.

W ramach przygotowania zgłoszenia warto przekazać informację o systemie gospodarza i systemie gościa, wybranym trybie sieci, sposobie uzyskiwania adresu IP oraz dokładnym komunikacie błędu. Przydatne są także wyniki ipconfig /all lub ip addr, informacje o bramie i DNS oraz odpowiedź na pytanie, czy połączenie z adresem IP działa. Takie dane pozwalają szybciej odróżnić awarię wirtualnego interfejsu od problemu po stronie routera, zapory albo operatora.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie konfiguracji komputera, systemu operacyjnego i środowiska wirtualnego, wraz z analizą zależności między kartą fizyczną a interfejsem widocznym w maszynie. W praktyce naprawy są zazwyczaj wykonywane w ciągu trzech dni roboczych, zależnie od zakresu usterki i dostępności urządzenia. Po ustaleniu przyczyny można uporządkować tryb sieci, odtworzyć prawidłowe parametry DHCP lub DNS, zweryfikować reguły zapory i sprawdzić działanie nazw zarówno w systemie gospodarza, jak i w maszynie wirtualnej.

Do serwisu warto zgłosić się także wtedy, gdy DNS działa niestabilnie, a problem pojawia się tylko po uruchomieniu kilku maszyn, po wznowieniu systemu z uśpienia albo po zmianie sieci bezprzewodowej. Takie objawy mogą wskazywać na konflikt usług, błędnie działający wirtualny przełącznik, nieprawidłową obsługę DHCP lub problem z trasą domyślną. Rzetelna diagnostyka powinna obejmować cały tor komunikacji, ponieważ wymiana pojedynczego ustawienia DNS nie rozwiąże problemu, jeśli uszkodzenie znajduje się w innej warstwie.