WireGuard w systemie Linux: sprawdzenie tunelu, tras i DNS

Klient WireGuard może wyświetlać aktywny interfejs wg0, podczas gdy Twoje pakiety nadal opuszczają połączenie zwykłe. Taki przypadek często występuje po imporcie pliku konfiguracyjnego na systemie Debian lub Ubuntu.

Przed modyfikacją klienta sprawdź interfejs, wymianę z parą i rzeczywiście wybraną trasę. Taka kontrola wskazuje, czy tunel transportuje cały ruch, czy tylko wewnętrzną sieć.

Rozróżnienie aktywnego tunelu od klienta do zaimportowania

Zachowaj lokalną konsolę lub drugą sesję SSH otwartą, jeśli plik WireGuard zawiera domyślną trasę. Linia AllowedIPs = 0.0.0.0/0 może przesyłać ruch IPv4 przez tunel, gdy uruchomisz wg-quick. Z ::/0 taki sam zasada dotyczy IPv6.

Rozpocznij od sprawdzenia, czy wg0 już istnieje. Jeśli interfejs jest obecny, nie zastępuj jego pliku i nie uruchamiaj wg-quick up. Przejdź bezpośrednio do poleceń wg show i ip route get poniżej.

ip link show wg0
sudo wg show wg0

Jeśli wg0 jest nieobecny, sprawdź nazwę interfejsu i uprawnienia pliku dostarczonego przez administratora lub dostawcę. Nigdy nie kopiuj klucza prywatnego w bilecie, repozytorium Git ani w zrzucie ekranu.

if sudo test -e /etc/wireguard/wg0.conf; then
  sudo cp -a /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak && sudo install -m 600 /ścieżka/client.conf /etc/wireguard/wg0.conf
else
  sudo install -m 600 /ścieżka/client.conf /etc/wireguard/wg0.conf
fi
sudo grep -E '^(Address|DNS|Endpoint|AllowedIPs)' /etc/wireguard/wg0.conf

Polecenie grep ponownie odczytuje parametry sieciowe, nie wyświetlając kluczy. Sprawdź szczególnie AllowedIPs. Zakres taki jak 10.44.0.0/24 zazwyczaj dotyczy sieci zdalnej. Trasa 0.0.0.0/0 wymaga ostrożniejszej kontroli, jeśli jesteś połączony z serwerem przez SSH.

Jeśli plik ma zastąpić istniejącą konfigurację, zachowaj starą pod nazwą spoza /etc/wireguard/ lub w swoim zarządzaniu kopii zapasowej. Proponowałbym najpierw przetestować z konsoli maszyny wirtualnej lub stacji roboczej, zamiast zmieniać domyślną trasę zdalnego serwera bez dostępu awaryjnego.

Uruchomienie WireGuard i odczytanie wymiany z parą

Jeśli wg0 było nieobecne, teraz aktywuj interfejs za pomocą wg-quick i trzymaj swoją konsolę lub drugą sesję otwartą do końca kontroli. Adres przypisany do wg0 nie potwierdza, że zdalna para odpowiada.

sudo wg-quick up wg0
ip -brief address show wg0
sudo wg show wg0

W wyjściu z wg show wg0 zwróć uwagę na najświeższe handshake i liczniki transfer. Ostatni znacznik czasu po zapytaniu do zdalnej sieci oraz odebrane bajty wskazują, że para odpowiada. Brak handshake sugeruje raczej problem z endpointem, portem UDP, firewallem lub kluczem, który nie zgadza się z oczekiwaną parą. Dokumentacja WireGuard Quick Start opisuje polecenia wg i wg-quick, które są używane tutaj.

Aby śledzić wymianę podczas próby, możesz ponownie uruchomić następujące polecenie. Unikaj zmiany konfiguracji podczas diagnozy.

watch -n 2 'sudo wg show wg0 latest-handshakes transfer'

Ping może pomóc, jeśli zdalny serwer zezwala na ICMP, ale brak odpowiedzi nie wystarcza do skazania tunelu. Wybierz zapytanie do usługi, do której Twoja konfiguracja ma zapewnić dostęp, na przykład wewnętrzny DNS lub aplikację zarządzającą.

Sprawdzenie wybranej trasy przed zakończeniem

Użyj ip route get, aby poznać urządzenie, które Linux wybierałby do wysłania pakietu do celu. Polecenie nie wysyła żadnego ruchu.

ip route get 10.44.0.10
ip route get 1.1.1.1

Dla zasobu wewnętrznego pierwsze wyjście powinno wspominać o dev wg0, jeśli 10.44.0.10 należy do sieci zadeklarowanych w AllowedIPs. Drugie wskazuje, czy wyjście z Internetu przechodzi również przez wg0, czy zachowuje zwykły interfejs. Zastąp te adresy dokumentacji prawdziwym celem przewidzianym w Twojej sieci.

Jeśli VPN zapewnia wewnętrzny resolver, przetestuj go bezpośrednio tylko wtedy, gdy jego adres jest wymieniony w dokumentacji Twojego tunelu i jeśli Linux rzeczywiście wybiera wg0, aby do niego dotrzeć. Zainstaluj dnsutils na Debianie lub Ubuntu, jeśli brak polecenia dig:

ip route get 10.44.0.53
sudo apt install dnsutils
dig @10.44.0.53 intranet.exemple.lan
sudo wg show wg0 latest-handshakes transfer

Pierwsze polecenie powinno wskazywać dev wg0. Zapytanie DNS powinno następnie zwrócić oczekiwaną odpowiedź i przetransportować otrzymany lub wysłany ruch. Jeśli trasa korzysta z wg0, ale handshake pozostaje nieobecny, klient rzeczywiście wysyła na lokalny interfejs, nie docierając do zdalnej pary.

Aby zakończyć test i przywrócić trasy dodane przez wg-quick, użyj sudo wg-quick down wg0. To polecenie nie naprawia trasy skonfigurowanej gdzie indziej w NetworkManagerze lub systemd-networkd. Usuwa jedynie interfejs i elementy, które wg-quick zainstalował dla tego tunelu.

Ważny tunel WireGuard można zidentyfikować poprzez trzy dowody: istniejący interfejs, niedawny handshake i trasę wskazującą na wg0 dla oczekiwanego celu. Artykuły na temat ip addr, trasowania IP oraz dig opisują te kontrole osobno, gdy problem wykracza poza sam tunel.