Pełny tunel WireGuard: AllowedIPs 0.0.0.0/0 to za mało

Wpisanie 0.0.0.0/0, ::/0 w AllowedIPs peera to krok, który wszyscy pamiętają, i decyduje on tylko o tym, jaki ruch peer może przenosić. Te prefiksy nie tworzą tras, niczego nie przekazują po drugiej stronie i zostawiają resolver każdej aplikacji dokładnie tam, gdzie był. Cztery osobne rzeczy muszą zachodzić jednocześnie, aby pełny tunel był naprawdę pełny, i najlepiej sprawdzać je w kolejności poniżej, bo późniejsze sprawdzenie nie może uratować wcześniejszego. Każde sprawdzenie poniżej to fakt, który można odczytać z maszyny, a nie ustawienie, o którym masz nadzieję, że zostało zastosowane.

Co wybiera prefiks peera, a czego nie

AllowedIPs jest jednocześnie selektorem i autoryzacją. Mówi stronie lokalnej, które cele można wysyłać do tego peera, a stronie odbierającej, jakie adresy źródłowe ten peer może przedstawiać. To cała praca. Nic w tym opisie nie tworzy trasy na hoście, nie włącza przekazywania po stronie zdalnej ani nie dotyka rozwiązywania nazw.

Dlatego konfiguracja może wyglądać na kompletną i zachowywać się jak tunel dzielony. Prefiks mówi, że peer przyjąłby wszystko; tablica routingu hosta decyduje, co faktycznie tam dotrze, a brama decyduje, czy coś wychodzi. Żadna z tych trzech decyzji nie mieszka w sekcji peera.

Routować klienta, nie tylko listę peerów

Menedżery takie jak wg-quick programują tablicę routingu hosta za ciebie, dlatego dwa identyczne pliki konfiguracji zachowują się różnie w zależności od tego, jak interfejs się podniósł. Minimalny profil jest wystarczająco krótki, by przeczytać go za jednym razem:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Pracę niosą dwa szczegóły. Pole Address to pojedynczy prefiks hosta, a nie podsieć, o której klient sądzi, że ją posiada, i to menedżer zamienia domyślne AllowedIPs w prawdziwą trasę domyślną. Podnieś ten sam plik za pomocą ip link i wg setconf i nie pojawi się żadna trasa, co wygląda jak zepsuty tunel, a w rzeczywistości jest zdrowym tunelem z pominiętym krokiem routingu. Podręcznik wg-quick dokumentuje routing i Table zachowanie, które dodają ci menedżerowie.

Czytaj wynik, a nie plik: ip route get 1.1.1.1 powinno wskazać interfejs tunelu, a wg show powinno zgłosić niedawne uzgadnianie z licznikiem transferu, który się porusza. Uzgadnianie bez trasy oznacza, że menedżer nigdy nie wystartował, i ponowne edytowanie profilu tego nie naprawi. Uruchamiaj interfejs tak, jak zrobi to użytkownik, inaczej test mierzy twoją powłokę zamiast wdrożenia.

Trzymać punkt końcowy poza tunelem

Pełny tunel przechwytuje każdy cel, w tym ten, z którym musi rozmawiać, aby istnieć. Menedżery radzą sobie z tym, dodając trasę hosta do punktu końcowego przez pierwotną bramę, dlatego poprawna konfiguracja prawie zawsze zawiera jeden celowy wyjątek. Zastosowanie połowy konfiguracji menedżerem, a drugiej połowy ręcznie, to zwykły sposób, w jaki ten wyjątek ginie.

Jeśli punkt końcowy to nazwa hosta, która rozwiązuje się na kilka adresów lub na rodzinę, której nie przenosisz, wyjątek starzeje się źle i tunel może zawieść po ponownym połączeniu, które wyglądało rutynowo. Przypnij punkt końcowy do adresu, który kontrolujesz, albo potwierdź, że menedżer ocenia go ponownie, i po każdej zmianie sieci ponownie odczytaj trasę hosta.

Ten sam mechanizm wyjaśnia, dlaczego pełny tunel i portal przechwytujący się kłócą. Portal oczekuje przechwycenia ruchu, który twój tunel teraz przechwytuje, więc w sieciach hotelowych i lotniskowych podnosisz tunel po zalogowaniu do portalu, nigdy przedtem.

Przekazywanie i droga powrotna na bramie

Na bramie włącz przekazywanie dla rodziny, którą przenosisz, zezwól na łańcuch forward w obu kierunkach, gdy tłumaczysz, i potwierdź drogę powrotną wyszukiwaniem właściwym dla źródła. Nic z tego nie wynika z udanego uzgadniania, bo uzgadnianie dowodzi tylko, że dwa peery mogą wymieniać UDP. Nie mówi nic o tym, co dzieje się później ze zdekapsulowanym pakietem.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Wyszukiwanie działa na bramie, a nie na kliencie, inaczej odczytasz inną tablicę routingu. Jeśli wskaże zły interfejs albo zgłosi brak trasy, to żadna zmiana po stronie klienta nie da wyjścia do internetu. Gdy brama tłumaczy adresy klientów na wyjściu, odpowiedź zależy od tego stanu tłumaczenia, więc reguła musi istnieć dla obu kierunków przepływu, a nie tylko dla wychodzącego.

DNS i stan awarii, testowane osobno

Sam protokół nie konfiguruje resolvera żadnej aplikacji. wg-quick stosuje wiersz DNS przez integrację resolvera dystrybucji, kontenery i przeglądarki z własnymi stosami mogą go ignorować, i dlatego nazwa może zawieść, podczas gdy tunel przenosi pakiety bezbłędnie. Testuj nazwą hosta, a nie adresem, i zapisz, który serwer odpowiedział, zamiast zakładać, że zrobił to ten z profilu.

Rodziny adresów to osobny test z osobną odpowiedzią. Domyślna trasa v4 nie mówi nic o tym, co zrobi połączenie v6 jakiejś aplikacji, a tunel, który po cichu przecieka drugą rodzinę, jest gorszy od tego, który głośno zawodzi. Pytaj o nazwę przez każdą rodzinę, czytaj interfejs użyty przez każde żądanie i sprawdzaj liczniki tłumaczenia przed i po, bo reguła, która do niczego nie pasuje, wygląda identycznie jak reguła brakująca.

Na koniec przetestuj stan, którego chcesz, gdy tunel się zatrzyma. Pełny tunel powinien zawieść zamknięty dla ruchu, który deklaruje: jeśli interfejs padnie, a aplikacje po cichu kontynuują przez łącze fizyczne, projekt jest tunelem dzielonym z dodatkowymi krokami. Zapisz zamierzone zachowanie przy awarii, sprawdź je celowo i zakończ zapisaniem czterech odpowiedzi — który menedżer podnosi interfejs, która trasa niesie domyślną, kto przekazuje i tłumaczy na bramie oraz który resolver odpowiada.