Uzgadnianie WireGuard działa, ale nie ma internetu: prześledź pakiet

Tunel działa, wg show zgłasza świeże uzgadnianie, możesz pingować adres tunelu serwera, a nic dalej nie odpowiada. Pierwszy odruch to ponowne wygenerowanie kluczy albo ponowne udostępnienie konfiguracji. To zmienia dokładnie tę część ścieżki, która jest już udowodniona jako działająca.

Zakończone uzgadnianie mówi, że obie strony zgadzają się co do kluczy, że UDP dociera do punktu końcowego i że routing kryptograficzny przyjmuje pakiet. Nie mówi nic o tym, czy pakiet może potem opuścić serwer.

Dlatego prześledź jeden pakiet zamiast zgadywać. Są cztery miejsca, w których może zginąć, i każde zostawia inny ślad.

Co naprawdę dowodzi uzgadnianie

WireGuard to protokół UDP, który nawiązuje sesję uzgadnianiem Noise, a następnie szyfruje pakiety dla drugiej strony. Gdy wg show pokazuje uzgadnianie sprzed kilku sekund i rosnący licznik transmisji, punkt końcowy, klucze i klucz publiczny drugiej strony są wszystkie poprawne.

Nie dowodzi natomiast, że klient w ogóle wysyła ruch kierowany do internetu do interfejsu, że serwer chce go przekazywać dalej, ani że odpowiedź znajdzie drogę powrotną. To decyzje routingu jądra i zapory, i zapadają poza tunelem.

Właśnie dlatego ping na adres tunelu serwera jest tak mylącym testem. Ten pakiet jest zaadresowany do samego serwera, więc kończy się lokalnie. Nigdy nie potrzebuje przekazywania, nigdy tłumaczenia i nigdy trasy powrotnej z internetu.

AllowedIPs to decyzja routingu

Na kliencie AllowedIPs pełni dwie funkcje. To tablica routingu klucza kryptograficznego, która decyduje, które adresy docelowe trafiają do tunelu tej drugiej strony, i to lista adresów źródłowych, które druga strona przyjmie od ciebie. Jeśli konfiguracja klienta wymienia tylko 10.8.0.0/24, cele publiczne nigdy nie wchodzą do interfejsu, a zwykła trasa domyślna wynosi je poza tunel. Wtedy tunel działa idealnie i nie robi nic z tego, czego chciałeś.

Spójrz na to, co klient faktycznie zainstalował, a nie na to, co mówi plik konfiguracji:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Decydujące jest drugie polecenie. Jeśli odpowiedź wskazuje interfejs fizyczny i zwykłą bramę, pakiet nie jest tunelowany i żadna zmiana po stronie serwera tego nie naprawi. Dodaj 0.0.0.0/0 dla IPv4 i ::/0 dla IPv6 osobno; reguła łapiąca wszystko dla jednej rodziny zostawia drugą na jej pierwotnej ścieżce, a to częsta przyczyna działającego tunelu IPv4 i zablokowanego wyszukiwania IPv6.

Gdzie pakiet ginie na bramie

Jeśli trasa jest poprawna, a pakiet nadal nigdzie nie dociera, to znaczy, że dotarł do serwera i tam się zatrzymał. Cztery kontrole obejmują większość bram.

Przekazywanie. sysctl net.ipv4.ip_forward zwracające 0 to klasyczna odpowiedź, a wiele dystrybucji nadal ma 0 domyślnie. Musi być 1 i musi być ustawione trwale w pliku sysctl, a nie poleceniem, które znika przy ponownym uruchomieniu. Przekazywanie IPv6 to osobny przełącznik.

Polityka filtra. Łańcuch FORWARD z domyślną polityką odrzucania będzie wyrzucał ruch tunelu, a jednocześnie przepuszczał ruch do samego hosta, co dokładnie pasuje do objawu. Czytaj żywy zbiór reguł, a nie zapisany plik: nft list ruleset lub iptables -S.

Tłumaczenie albo routing. Klienci z prywatnymi adresami tunelu potrzebują albo NAT źródłowego na interfejsie wyjściowym serwera, albo trasowanego prefiksu, który sieć nadrzędna umie zwrócić. Wybór między nimi wynika z planu adresacji. Dodanie MASQUERADE do sieci, która już trasuje twój prefiks z powrotem, jest nieszkodliwe, ale bezcelowe, a pominięcie go tam, gdzie nie ma trasy, zostawia odpowiedzi zaadresowane do nieosiągalnego zakresu prywatnego.

Droga powrotna. W rozwiązaniach trasowanych router nadrzędny potrzebuje trasy wskazującej na twój serwer. Sieć dostawcy też może to blokować: kilka chmur włącza kontrolę źródła i celu na instancji, która po cichu odrzuca pakiety, których źródłem nie jest własny adres instancji, dopóki ta kontrola nie zostanie wyłączona.

DNS zawodzi inaczej niż routing

Pakiet do znanego adresu i wyszukanie nazwy to dwie różne awarie, a komunikaty o błędach mylą w przeciwnych kierunkach. Jeśli ping 1.1.1.1 działa, a przeglądarka nic nie ładuje, trasa jest dobra, a rozwiązywanie nazw nie. Jeśli sam ping zawodzi, DNS jest nieistotny i wracasz do poprzedniej sekcji.

wg-quick potrafi ustawić resolver z linii DNS = w konfiguracji, a systemd-resolved ma własne zachowanie dla każdego łącza. VPN, który nadpisuje resolver adresem osiągalnym tylko wewnątrz tunelu, będzie zawodził przy każdym wyszukiwaniu w chwili, gdy tunel padnie, co wygląda tak, jakby tunel psuł internet.

Kolejność, która daje dowody

Najpierw wykonaj kontrolę po stronie klienta, bo to jedno polecenie i eliminuje połowę możliwości. Potem potwierdź, czy serwer jest w ogóle pomyślany jako wyjście do internetu; brama zbudowana dla dostępu prywatnego nie jest zepsuta, gdy cele publiczne nie działają.

Na serwerze obserwuj interfejs, wysyłając ping z klienta: tcpdump -ni wg0 icmp powinien pokazać żądanie, a tcpdump -ni eth0 icmp powinien pokazać, że wychodzi, przetłumaczone lub nie. Jeśli pojawia się na pierwszym i nigdy na drugim, zatrzymanie jest lokalne na serwerze. Jeśli wychodzi i odpowiedź nie wraca, problem jest wyżej, a to inna rozmowa.

Na koniec spraw, aby poprawka przetrwała restart. Przekazywanie należy do pliku sysctl, reguły zapory do usługi, która je ładuje, a trasy klienta do konfiguracji, która podnosi interfejs, a nie do powłoki, którą zapomnisz. Połącz się ponownie, powtórz te same dwa testy i potwierdź, że liczniki się zmieniają.