Brak rozwiązywania nazw hostów przez VPN

Brak rozwiązywania nazw hostów przez aktywne połączenie VPN wskazuje na niepoprawnie skonfigurowany serwer DNS w tunelu VPN — wymaga jego dostosowania po stronie klienta lub serwera VPN.

Na czym polega brak rozwiązywania nazw hostów przez VPN

Brak rozwiązywania nazw hostów przez VPN oznacza sytuację, w której aktywny tunel szyfrujący działa, lecz urządzenie nie potrafi zamienić nazwy używanej przez człowieka, takiej jak plikownia.firma.lan albo intranet, na właściwy adres IP. W efekcie połączenie z siecią zdalną może być formalnie ustanowione, a mimo to nie da się otworzyć zasobu po jego nazwie. Często możliwy jest dostęp do tego samego miejsca po bezpośrednim adresie IP, co wskazuje, że problem dotyczy przede wszystkim mechanizmu DNS, a nie całego tunelu VPN.

W typowej komunikacji komputer najpierw sprawdza lokalną pamięć DNS, następnie korzysta z konfiguracji otrzymanej z systemu operacyjnego lub klienta VPN, a dopiero później wysyła zapytanie do skonfigurowanego resolvera. Jeżeli po połączeniu z VPN nie zostaną zastosowane właściwe adresy DNS, sufiksy wyszukiwania albo reguły kierujące zapytania do odpowiedniej sieci, nazwy wewnętrzne pozostają nierozpoznane. Podobny objaw może wystąpić wtedy, gdy dostęp do DNS jest blokowany przez zaporę, trasę tunelową lub błędnie ustawioną politykę dostępu.

Znaczenie DNS w tunelu VPN i porównanie sposobów dostępu

Adres IP oraz nazwa hosta pełnią w tej sytuacji różne funkcje. Wpisanie adresu IP omija etap wyszukiwania DNS, dlatego może zadziałać nawet wtedy, gdy nazwa urządzenia nie jest rozpoznawana. Korzystanie z nazw jest jednak wygodniejsze i zwykle konieczne przy zasobach, które zmieniają adresy, wykorzystują wiele usług albo wymagają prawidłowego wskazania hosta w protokole aplikacyjnym.

W zależności od rodzaju wdrożenia VPN zapytania DNS mogą być obsługiwane przez resolver znajdujący się w sieci lokalnej, przez publiczną usługę DNS albo przez mechanizm dostarczany bezpośrednio przez klienta VPN. Publiczny resolver zazwyczaj nie zna nazw prywatnych używanych wewnątrz organizacji, natomiast resolver wewnętrzny może nie być osiągalny bez odpowiedniej trasy w tunelu. Dlatego istotne jest rozdzielenie zapytań: nazwy publiczne mogą być kierowane do zewnętrznej usługi, a nazwy wewnętrzne do właściwego DNS dostępnego przez VPN.

W bardziej rozbudowanych konfiguracjach stosuje się DNS split-horizon, warunkowe przekazywanie zapytań lub reguły przypisujące konkretne domeny do określonych resolverów. Znaczenie ma również kolejność interfejsów sieciowych. System może nadal preferować kartę Wi-Fi lub Ethernet i wysyłać zapytania poza tunelem, mimo że połączenie VPN jest aktywne. Weryfikacji wymagają też ustawienia IPv4 i IPv6, ponieważ ruch nazw może być kierowany inną ścieżką niż ruch do samego zasobu.

Typowe przyczyny i objawy błędnego działania - Brak rozwiązywania nazw hostów przez VPN

Jedną z częstszych przyczyn jest brak przekazania przez profil VPN adresów właściwych serwerów DNS. W innych przypadkach adresy są przekazane poprawnie, ale system nie przypisuje ich do odpowiednich nazw domenowych. Problem może pojawić się po aktualizacji klienta VPN, zmianie hasła lub certyfikatu, przełączeniu z sieci firmowej na domową, przy zmianie punktu dostępowego albo po powrocie komputera ze stanu uśpienia.

Do charakterystycznych symptomów należą:

• działające połączenie VPN przy jednoczesnym braku dostępu do zasobów wywoływanych nazwą;
• poprawne otwieranie witryny lub udziału sieciowego po adresie IP, lecz nie po nazwie;
• komunikaty o nieodnalezieniu hosta, przekroczeniu czasu oczekiwania albo braku odpowiedzi DNS;
• działanie jednych nazw wewnętrznych i niedziałanie innych, zależnie od domeny lub sufiksu;
• różne rezultaty poleceń diagnostycznych przed zestawieniem VPN i po jego zestawieniu;
• chwilowa poprawa po opróżnieniu pamięci podręcznej DNS, która nie usuwa przyczyny konfiguracji.

Diagnostykę można rozpocząć od sprawdzenia parametrów interfejsów, tablicy tras i aktywnych resolverów. Przydatne jest porównanie odpowiedzi dla nazwy wewnętrznej i publicznej, sprawdzenie, czy zapytanie dociera do właściwego DNS, oraz zweryfikowanie, czy nazwa jest rozpoznawana wyłącznie przy aktywnym VPN. Należy także ocenić reguły zapory na komputerze i urządzeniu brzegowym, ustawienia automatycznego uzyskiwania DNS, lokalny plik hosts oraz ewentualne konflikty między kilkoma klientami VPN. Samo czyszczenie pamięci podręcznej nie powinno być traktowane jako pełna naprawa, jeżeli po ponownym połączeniu problem wraca.

W jakich sytuacjach warto zlecić diagnozę specjalistom - Brak rozwiązywania nazw hostów przez VPN

Do serwisu warto zgłosić się wtedy, gdy rozwiązywanie nazw przestało działać po zmianie konfiguracji, po aktualizacji systemu lub klienta VPN, gdy problem występuje tylko na jednym komputerze albo gdy nie można jednoznacznie ustalić, czy przyczyną jest DNS, trasa, zapora czy profil połączenia. Szczególnie uzasadniona jest konsultacja, gdy dostęp po adresie IP działa, lecz aplikacje wymagające nazw hostów nadal zgłaszają błędy, ponieważ pozornie sprawny tunel może mieć niepełną konfigurację parametrów sieciowych.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie ustawień systemu, klienta VPN, interfejsów sieciowych, tras oraz komunikacji z właściwymi usługami DNS. Analiza powinna obejmować odtworzenie problemu, porównanie działania przed połączeniem i po połączeniu z VPN oraz przygotowanie ustawień w sposób umożliwiający późniejsze samodzielne korzystanie z sieci. Naprawy są zazwyczaj realizowane w ciągu najwyżej trzech dni roboczych, zależnie od zakresu diagnostyki i dostępności informacji potrzebnych do odtworzenia konfiguracji.

Przed przekazaniem urządzenia warto zanotować dokładny komunikat błędu, nazwę hosta, której nie można odnaleźć, informację o tym, czy dostęp po adresie IP działa, oraz moment, od którego występuje usterka. Przydatne będzie także wskazanie używanego systemu, rodzaju połączenia internetowego i tego, czy problem dotyczy wszystkich zasobów, czy tylko wybranej domeny wewnętrznej. Tak przygotowane dane ułatwiają rozróżnienie usterki lokalnej od problemu po stronie zdalnej konfiguracji VPN.