WireGuard nadal używa starego punktu końcowego po zmianach DNS

Tunel przestał przepuszczać ruch po tym, jak rekord DNS serwera się przesunął, a nazwa rozwiązuje się poprawnie z tej samej maszyny. Te dwa fakty nie są sprzeczne. Konfiguracja WireGuard zawiera punkt końcowy, a narzędzie rozwiązuje nazwę w chwili zastosowania tej konfiguracji, więc działający interfejs może nadal używać adresu, który uzyskał kilka godzin temu. Sprawdź, czego używa interfejs, zanim wymienisz klucze lub dotkniesz zakresu tunelu.

Nazwa jest rozwiązywana raz, a nie ciągle

Podstawowa konfiguracja WireGuard przyjmuje punkt końcowy jako adres i port, a narzędzie, które podnosi interfejs, rozwiązuje nazwę hosta w tej chwili. Nic w protokole podstawowym nie odpytuje DNS według harmonogramu, a aplikacja klienta może dodać na wierzchu własne zachowanie odświeżania. Zapisanie rozwiązanego adresu, rodziny i portu obok nazwy czyni tę lukę widoczną. Bez takiego zapisu konfiguracja wygląda poprawnie, podczas gdy interfejs rozmawia z czymś innym.

Istnieje jedna prawdziwa automatyczna aktualizacja i warto ją znać, bo przypomina odświeżanie DNS, nie będąc nim. Punkt końcowy peera może się przesunąć, gdy poprawnie uwierzytelniony ruch przyjdzie z nowego adresu, co jest roamingiem, a nie rozwiązywaniem nazw. Podąża za peerem, więc nie może odkryć niepowiązanego nowego serwera, z którym stary punkt końcowy nigdy się nie kontaktował.

Porównaj rekord z używanym adresem

Odpytaj udokumentowaną nazwę przez resolver, którego używa klient, a następnie zapytaj interfejs, który punkt końcowy trzyma. Obie odpowiedzi to porównanie, które rozstrzyga resztę tej strony:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

Strona podręcznika wg(8) dokumentuje podpolecenia show używane przez te wiersze. Porównaj także rodzinę adresu, nie tylko adres, bo rekord, który zyskał wpis IPv6, to inne porównanie niż ten, którego adres IPv4 się zmienił. Jeśli punkt końcowy różni się od rekordu, interfejs działa na nieaktualnych informacjach i nazwa nigdy nie była problemem. Jeśli się zgadzają, a tunel nadal zawodzi, przejdź do nasłuchującego i reguł, a nie do profilu.

Znacznik czasu uścisku dłoni jest w tym bloku, ponieważ sam punkt końcowy nie mówi, czy peer jest osiągalny. Nieaktualny znacznik obok poprawnego punktu końcowego to problem ścieżki, a nie rozwiązywania, i ta różnica zmienia to, czego dotkniesz następnym razem.

Uruchom ponownie przez menedżera interfejsu

Gdy punkt końcowy zostanie potwierdzony jako nieaktualny, odśwież go mechanizmem, który posiada interfejs zamiast edytować działającą konfigurację. Dla interfejsu uruchomionego przez wg-quick to zejście i podniesienie, dla jednostki systemd restart, a dla interfejsu należącego do menedżera zmiana wykonana w tym menedżerze, ponieważ edycja w czasie działania jest nadpisywana przy następnym zastosowaniu:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Następnie potwierdź, że zastępczy nasłuchujący i jego tożsamość to usługa, którą miałeś na myśli. Przesunięcie DNS nie jest zmianą tożsamości, więc nigdy nie powinno być okazją do zaufania kluczowi, którego nie zweryfikowałeś. Jeśli interfejs teraz zgłasza nowy adres i nadal nie daje uścisku dłoni, usterka przeniosła się na nową ścieżkę sieci lub nasłuchującego, co jest postępem, a nie tą samą usterką dwa razy.

Najpierw uścisk dłoni, potem ścieżka danych

Rozdziel oba wyniki, zanim wybierzesz listę kontrolną. Uścisk dłoni, który udaje się przy aplikacji, która zawodzi, to problem ścieżki danych: trasy, dozwolone prefiksy lub DNS wewnątrz tunelu. Uścisk dłoni, który nigdy nie następuje, to problem osiągalności lub tożsamości w punkcie końcowym. Mieszanie obu daje raport, którego nikt nie potrafi odtworzyć, i dziennik zmian z trzema niepowiązanymi edycjami.

Zapisz nazwę, rozwiązany adres, używany punkt końcowy i to, czy uścisk dłoni się zakończył. Te cztery fakty odpowiadają na pytanie, które ta usterka stale zadaje, i zamieniają następne wystąpienie w dwuminutową kontrolę. Utrzymanie nazw i wdrożenie u klientów pozostają osobnymi zadaniami: poprawienie rekordu nie wykonuje wdrożenia, a ponowne uruchomienie interfejsu nie naprawia rekordu, który nadal jest błędny.