WireGuard: brak trasy do peera po zmianie podsieci — dwa wyjścia

Uścisk dłoni jest świeży w wg show, punkt końcowy poprawny, klucze nigdy się nie zmieniły — a ping nadal twierdzi, że nie ma trasy do peera. Godzinę temu zmieniłeś podsieć tunelu. Ten objaw to sygnatura niezgodności prefiksu, a nie problem z kluczami: WireGuard zakończył uścisk dłoni, a potem odrzucił dane, bo adres źródłowy nie pasuje już do tego, co przyjmie odbierający peer. Są dwa rozsądne sposoby przeprowadzenia zmiany podsieci i każdy zawodzi w innym miejscu.

Dwa sposoby przeprowadzenia zmiany i ile kosztuje każdy

Opcja A to przenumerowanie w miejscu: zmień adres interfejsu, zakresy peerów, trasy i każdą kopię konfiguracji, a potem wczytaj ponownie. Opcja B to zbudowanie drugiego interfejsu na nowym prefiksie obok starego, przeniesienie peerów i usunięcie starego interfejsu, gdy ruch naprawdę się przeniesie.

To stan połowicznego zastosowania czyni opcję A niebezpieczną, bo nie wygląda na zepsuty. Interfejs wstaje, uścisk dłoni się udaje, a zawodzi tylko ścieżka danych. Opcja B wymaga więcej pracy, ale utrzymuje działającą ścieżkę przy życiu, dopóki nie znajdziesz każdego odwołania.

Co musi poruszać się razem po twojej stronie

Cztery rzeczy na lokalnym hoście opisują tę samą podsieć, a zmiana jednej jest zmianą wszystkich: adres interfejsu, AllowedIPs każdego peera, trasa, której system używa dla tych celów, i wszystko, co menedżer instaluje w twoim imieniu. Z wg-quick dwie ostatnie są generowane z konfiguracji przy każdym podniesieniu interfejsu, więc nieaktualna kopia po cichu przywraca stary prefiks.

Porównaj to, co skonfigurowane, z tym, co żywe, zamiast ufać któremukolwiek z nich:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

Wyszukiwanie trasy to krok, który ludzie pomijają. Odpowiada, co jądro naprawdę zrobiłoby dla celu, łącznie z bardziej szczegółową trasą pozostawioną przez menedżera lub środowisko uruchomieniowe kontenerów. Jeśli wskazuje inny interfejs niż tunel, konfiguracja nie jest problemem.

Dla działającego interfejsu zastosuj zmieniony plik bez zrywania tunelu:

wg syncconf wg0 <(wg-quick strip wg0)

To aktualizuje peery i zakresy w miejscu. Nie aktualizuje adresu interfejsu ani tras, bo to nie są ustawienia WireGuard — przenumerowanie nadal wymaga więc odtworzenia interfejsu lub zmiany adresu przez ip, a potem ponownego sprawdzenia routingu.

Co musi poruszać się razem na drugim końcu

Tu zmiana podsieci zwykle umiera. AllowedIPs to nie tylko podpowiedź routingu; to także lista adresów źródłowych, które peer może przedstawić. Gdy przenumerowujesz klientów i zostawiasz AllowedIPs serwera na starym prefiksie, serwer przyjmuje uścisk dłoni, odbiera zaszyfrowane pakiety i je wyrzuca, bo wewnętrzne źródło nie pasuje do żadnego zakresu, który wiąże z tym peerem. Żaden błąd nie jest zapisywany, a klient widzi przekroczenie czasu.

Aktualizuj więc stronę odbierającą świadomie: wpis peera na serwerze musi wymieniać nowy prefiks klienta, własna trasa powrotna serwera musi wskazywać tunel dla tego prefiksu, a każda sieć niższego poziomu za serwerem musi nauczyć się nowej ścieżki. Zasady firewalla, które nazywały stary zakres, wymagają tego samego, podobnie jak wszystko, co robi wybór na podstawie źródła.

Diagnostyka rozdzielająca oba błędy jest tania. Świeży uścisk dłoni bez danych oznacza, że tunel stoi, a adresacja wewnętrzna się nie zgadza. Brak jakiegokolwiek uścisku dłoni oznacza, że patrzysz na osiągalność lub klucze. Nie zmieniaj kluczy z powodu problemu z prefiksem; to resetuje jedyną rzecz, która działała.

Nieaktualne kopie, które przeżywają twoją zmianę

Edytowanie pliku to nie to samo co zmiana działającego systemu, a kopii jest więcej, niż ludzie się spodziewają: jednostka lub menedżer, który posiada interfejs, drugi profil o tej samej nazwie w innym katalogu, kontener z konfiguracją wypieczoną w obrazie, interfejs routera z własną zmienioną wersją i aplikacja klienta, która przy starcie ponownie importuje zapisany tunel. Każda z nich może przywrócić stary prefiks po tym, jak twoja zmiana wygląda na ukończoną.

Nazwy też podróżują. Jeśli trasa numeryczna działa, ale nazwa hosta zawodzi, wewnętrzny rekord DNS lub konfiguracja usługi nadal wskazuje stary adres tunelu. Napraw odwołanie zamiast poszerzać każdy zakres peera, co zakryłoby prawdziwy problem i jednocześnie powiększyło ACL źródła.

Podczas pracy trzymaj otwartą jedną ścieżkę odzyskiwania: drugi sposób wejścia na host, konsolę szeregową lub zaplanowane wycofanie plików konfiguracyjnych. Zmiana tunelu, która zamyka cię poza maszyną, którą zmieniasz, to najczęstszy sposób, w jaki to zadanie zamienia się w wieczór.

Wybór między dwoma i weryfikacja przełączenia

Wybierz A, gdy posiadasz każdego peera, liczba jest mała, a krótka przerwa jest akceptowalna. Wybierz B, gdy peery to zdalne ręce, których nie kontrolujesz, gdy łącze między lokalizacjami musi pozostać, albo gdy nie możesz zagwarantować, że każda kopia zostanie zaktualizowana w jednym przebiegu. W takim przypadku dodaj nowy prefiks do obu interfejsów, przenoś peery po jednym, obserwuj ruch na nowym i dopiero potem usuń stary interfejs i jego trasy.

W obu wariantach zmiana jest gotowa, gdy przejdą cztery kontrole: uścisk dłoni jest świeży, wyszukiwanie trasy dla celu z nowym prefiksem nazywa tunel, ładunek kilkuset bajtów przechodzi w obu kierunkach i to samo obowiązuje po restarcie hosta lub menedżera. Oficjalny podręcznik wg(8) jest źródłem tego, co AllowedIPs znaczy w każdym kierunku, i warto go przeczytać ponownie, zanim poszerzysz zakres, żeby objaw zniknął.

• Świeży uścisk dłoni i brak danych: zajrzyj do AllowedIPs u odbiorcy, zanim dotkniesz kluczy.
• Wyszukiwanie trasy wskazuje zły interfejs: trasą zarządza menedżer lub kontener, nie twój plik.
• Adres numeryczny w porządku, a nazwa hosta zepsuta: stare odwołanie, nie pętla routingu.
• Zmiana jest kompletna dopiero wtedy, gdy po restarcie nadal używany jest nowy prefiks.