Dlaczego wpis w /etc/hosts nie dociera do DNS VPN

Dodałeś nazwę do /etc/hosts, połączyłeś się z VPN i oczekiwałeś, że rekord pojawi się u wszystkich. Tak się nie dzieje, a zaskoczenie zwykle przychodzi z drugim objawem: nazwa rozwiązuje się na twoim komputerze i zawodzi u kolegi, co wygląda na zepsutą usługę DNS VPN, a w rzeczywistości plik hosts robi dokładnie to, do czego został zaprojektowany. Plik hosts to lokalna konfiguracja rozwiązywania nazw, a nie aktualizacja strefy, i nic w normalnym połączeniu VPN go nie wysyła.

Hosts to lokalne nadpisanie, a nie aktualizacja strefy

Plik jest listą odwzorowań, do których biblioteki usług nazw zaglądają przed zapytaniem do serwera DNS lub zamiast niego. Wiersz taki jak 10.40.0.20 build.corp.example zmienia to, co wnioskują aplikacje na tej jednej maszynie. Nie tworzy rekordu, nie podróżuje przez tunel, a serwer DNS, na który wskazuje tunel, nie ma pojęcia, że istnieje.

Dlatego awaria jest asymetryczna. Twój klient dostaje odpowiedź z pliku. Inny klient pyta serwer DNS VPN, który nic nie zwraca, a aplikacja zgłasza, że nazwa nie istnieje. Obie maszyny zachowują się poprawnie; tylko jedna ma nadpisanie, którego druga nigdy nie widziała.

Dwie komendy, dwa różne komponenty

Najszybszym sposobem zakończenia sporu jest pokazanie różnicy w dwóch komendach, obu uruchomionych na kliencie, który ma wpis w hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Pierwsza pyta własną ścieżkę wyszukiwania systemu, która w typowym systemie glibc czyta pliki lokalne przed DNS. Druga wysyła zapytanie DNS bezpośrednio do serwera pod tym adresem i w ogóle nie zagląda do plików lokalnych. Gdy pierwsza zwróci twój wpis, a druga zwróci NXDOMAIN, udowodniłeś, że rekord nie istnieje w DNS i że twoja maszyna odpowiada z lokalnego nadpisania.

Kolejność jest konfigurowalna i warto ją sprawdzić, zanim wyciągniesz jakiekolwiek wnioski o konkretnej dystrybucji. Spójrz na wiersz hosts: w /etc/nsswitch.conf; hosts: files dns najpierw sprawdza pliki. Nie kopiuj tego przykładu na działającą konfigurację tylko po to, by zmienić kolejność, bo prawdziwe systemy często wymieniają dodatkowe źródła i warunkowe wpisy usług, których przykład nie zawiera.

systemd-resolved zaciera test

W systemie z systemd-resolved lokalny stub obsługuje też nazwy z bazy hosts. Dlatego zapytanie do 127.0.0.53 nie jest niezależnym testem zdalnego serwera, choć wygląda jak zapytanie DNS i zachowuje się jak ono. Możesz potwierdzić, co wie resolver i o jakie serwery by pytał, za pomocą:

resolvectl query build.corp.example
resolvectl status

Dane wyjściowe status wymieniają serwery DNS dla każdego łącza i w ten sposób dowiesz się, czy łącze VPN w ogóle otrzymało resolver. To pytanie jest oddzielone od wpisu hosts i to ono jest warte postawienia, gdy prywatna nazwa zawodzi u wszystkich użytkowników, a nie u jednego.

Aplikacje mogą dodać kolejną warstwę. Przeglądarka z własnym ustawieniem DNS-over-HTTPS, kontener z własną konfiguracją resolvera albo środowisko uruchomieniowe, które buforuje wyszukiwania przez cały czas życia procesu, mogą odpowiadać inaczej niż system. Testuj aplikację, na której ci zależy, zamiast zakładać, że jedna komenda opisuje każdy program na maszynie.

Co naprawdę udostępnia nazwę przez VPN

Jeśli prywatna nazwa ma działać dla wszystkich, potrzebuje właściciela, do którego dotrze resolver każdego. Czysta odpowiedź to opublikowanie rekordu w zarządzanej strefie i uczynienie tej strefy rozwiązywalną przez zamierzoną ścieżkę DNS VPN. Wtedy rekord ma jedno źródło prawdy, ślad audytowy i cykl życia, a nikt nie musi pamiętać, który laptop nosi lokalne nadpisanie.

Rozprowadzanie plików hosts to legalna alternatywa i jest to zarządzanie punktami końcowymi, a nie usługa nazw. Jeśli ją wybierzesz, plik musi być wdrożony, wersjonowany i usunięty przez to, co zarządza flotą, i tak powinno to być opisane w projekcie. „VPN się tym zajmuje” nie jest opisem tego procesu.

Dynamiczna rejestracja DNS to trzeci mechanizm, z własnymi uprawnieniami, uwierzytelnianiem aktualizacji i czasem życia rekordu. Nie wynika z wpisu hosts i nie wynika też z samego połączenia klienta, chyba że serwer i klient zostali obaj skonfigurowani do tego. Rekord, który pojawia się sam, jest sygnałem, że ktoś włączył bezpieczne aktualizacje i klienta, który sam się rejestruje, a ta konfiguracja należy do zapisu projektu, a nie do wątku rozwiązywania problemów. Jeśli nikt nie potrafi wskazać właściciela tego ustawienia, traktuj automatyczny rekord jako niezweryfikowany i utrzymuj zarządzaną strefę jako źródło prawdy.

Rozwiązana nazwa nie jest trasą

Rozwiązywanie nazw i osiągalność to odrębne rzeczy, a nieaktualne lokalne odwzorowanie to klasyczny sposób ich pomylenia. Wpis hosts wskazujący adres, który się przeniósł, będzie nadal wybierał nieaktualnego hosta długo po poprawieniu DNS, a objaw wygląda jak awaria routingu przy nazwie, która rozwiązuje się poprawnie.

Więc gdy raport brzmi „nazwa się rozwiązuje, ale usługa jest nieosiągalna”, porównaj wyszukiwanie systemowe z jawnym zapytaniem do serwera DNS VPN, a następnie sprawdź uzyskany adres z tym, którego usługa faktycznie używa. Dokumentacja systemd-resolved opisuje lokalne źródła, do których zagląda, i to jest mapa potrzebna do tego porównania.

Potem napraw nadpisanie przez jego właściciela. Usunięcie wiersza z własnego pliku hosts nic nie daje dwunastu laptopom, które otrzymały ten sam wiersz ze skryptu wdrożeniowego, i to jest wersja tego problemu, z którą ludzie naprawdę mają do czynienia.