wg-quick psuje DNS przy połączeniu: przeczytaj błąd konfiguracji

Tunel wstaje, uzgadnianie się kończy, a rozwiązywanie nazw zatrzymuje się. Nic w konfiguracji peera się nie zmieniło, ponieważ linia DNS nigdy nie była jej częścią. Należy do pomocnika konfiguracji, co oznacza, że awaria mieszka w narzędziach resolvera hosta, a nie w kluczach WireGuard.

Przeczytaj pierwszy komunikat wypisany przez pomocnika, a nie ostatni, a różnica między brakującym narzędziem a nieosiągalnym serwerem stanie się oczywista.

Linia DNS jest funkcją pomocnika

Podstawowe pola konfiguracji opisują peerów, klucze i dozwolone adresy. Rozwiązywanie nazw dokłada się na wierzchu przez skrypt, który podnosi interfejs, i każda implementacja robi to inaczej. Klient desktopowy może zarządzać DNS przez własną usługę, skrypt dystrybucji może wywołać jedno z kilku narzędzi resolvera, a kontener może nie robić żadnego z nich. Plik konfiguracji nie może powiedzieć, która z tych ścieżek jest w grze.

Dlatego plik konfiguracji może być poprawny dla protokołu i mimo to zawieść podczas konfiguracji: awaria należy do haka, którego protokół nigdy nie widzi.

Zapisanie rozszerzonego pola w konfiguracji podstawowej i oczekiwanie, że narzędzie protokołu je przyjmie, tworzy to samo zamieszanie z przeciwnej strony. Oba parsery czytają różne pliki.

Wiedza, który działa, to pierwszy krok diagnostyczny, i zwykle widać to w wpisanej komendzie, a nie w pliku konfiguracji.

Przeczytaj pierwszy błąd, który wypisuje pomocnik

Podnieś interfejs na pierwszym planie i czytaj wyjście po kolei. Brakujące narzędzie resolvera, nieudany hak i nieosiągalny serwer zatrzymują tę samą komendę w różnych miejscach, a każde ma inną naprawę.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

Pierwsze polecenie raportuje postęp konfiguracji, drugie pokazuje, jakich serwerów interfejs teraz wymaga, a trzecie pokazuje, czy adres resolvera jest naprawdę osiągalny przez tunel. Resolver skonfigurowany, ale bez trasy, daje przekroczenia czasu zamiast błędów konfiguracji, dlatego oba sprawdzenia idą razem. Czytanie samego wyjścia stanu daje pewny i błędny wniosek.

Jeśli konfiguracja się zakończyła, a rozwiązywanie nazw nadal zawodzi, porównaj resolver zainstalowany przez pomocnika z tym, którego sieć używała wcześniej. Prywatny resolver potrzebuje trasy przez tunel, a konfiguracja, która wymienia go bez pokrycia jego prefiksu, zostawia każde zapytanie w oczekiwaniu.

Jaki resolver host naprawdę ma

Nowoczesne hosty Linux często uruchamiają lokalny stub resolver, więc adres instalowany przez pomocnika jest zużywany przez ten stub, a nie bezpośrednio przez aplikacje. Ręczna edycja wygenerowanego pliku może wyglądać na działającą do następnego połączenia, gdy pomocnik zapisuje go od nowa.

Użyj wspieranej integracji dla dystrybucji i pozwól jednemu komponentowi posiadać stan resolvera. Dwóch właścicieli tworzy ten sam wyścig co dwóch właścicieli adresu interfejsu, a objawem jest host, który po każdej zmianie przez kilka minut rozwiązuje poprawnie.

Nazwy wewnętrzne zasługują na własne sprawdzenie. Publiczny resolver może przywrócić zwykłe przeglądanie, a jednocześnie sprawić, że każda nazwa firmowa zawiedzie, co jest przeciwieństwem celu tunelu. Zapytaj zamierzony serwer o nazwę wewnętrzną, zanim uznasz, że DNS jest naprawiony.

Sprzątanie jest równie ważne jak konfiguracja

Opuść interfejs i jeszcze raz sprawdź stan resolvera. Pomocnik, który przywraca poprzednią konfigurację, zostawia host użyteczny; ten, który zostawia własne serwery, tworzy następną awarię, często godziny później, gdy tunel dawno zniknął.

Nieaktualny stan łatwo zauważyć, gdy zacznie się go szukać. Lista resolverów może wskazywać adres na interfejsie, którego już nie ma, a domena wyszukiwania może przetrwać sieć, którą opuściłeś dziś rano. Każda z nich czyni następne połączenie nieprzewidywalnym, i żadna nie pojawia się we własnym wyjściu stanu tunelu. Sprawdzenie zajmuje dziesięć sekund i oszczędza następnej osobie godzinę.

Trzymaj diagnostykę osobno od naprawy. Jeśli zawodzi każdy cel, a nie tylko wyszukiwanie nazw, podejrzane są trasy i przekazywanie, a linia DNS to rozproszenie uwagi. podręcznik wg-quick dokumentuje, którymi polami się zajmuje i które należą do protokołu, i ta granica jest całą odpowiedzią na większość takich zgłoszeń.