Dwa peery WireGuard dzielą zakres: który dostaje pakiet
Nakładające się zakresy rozstrzyga najbardziej szczegółowy prefiks, a nie kolejność. Najpierw sprawdź trasę, potem listę peerów, zanim cokolwiek poszerzysz.
Dwa peery wymieniają zakresy, które się stykają, a ruch trafia do niewłaściwego. Nic nie jest uszkodzone: WireGuard wybiera peera, dopasowując cel do skonfigurowanych zakresów, i wygrywa najbardziej szczegółowe dopasowanie. Zanim cokolwiek poszerzysz, zdecyduj, który peer ma posiadać który prefiks.
Najdłuższy prefiks wygrywa wewnątrz WireGuard
Każdy wpis peera niesie zestaw prefiksów docelowych. Gdy pakiet jest routowany do interfejsu, implementacja szuka wpisu z najbardziej szczegółowym pasującym prefiksem — tej samej reguły, którą stosuje tablica routingu. Dlatego /24 bije /16, który go zawiera, a węższy peer odbiera ruch.
Konfiguracje road-warrior używają tego celowo. Jeden peer posiada szeroki zakres dla witryny, a poszczególne hosty są wydzielane wpisami /32 należącymi do innych peerów. Wzorzec działa, bo wydzielenia są bardziej szczegółowe, a nie z powodu kolejności.
Zapisz własność jako tabelę prefiksu i peera. Jeśli dwa wpisy opisują ten sam prefiks, konfiguracja nie wyraża już intencji, lecz wyścig.
System operacyjny wybiera najpierw interfejs
WireGuard wybiera tylko spośród peerów na jednym interfejsie. Który interfejs otrzyma pakiet, rozstrzyga się wcześniej, w tablicy routingu hosta, a druga trasa domyślna lub nieaktualna trasa może wysłać ruch tam, gdzie lista peerów nigdy go nie widzi. Dlatego diagnoza na poziomie peera może być poprawna i mimo to nie tłumaczyć awarii. Sprawdź trasę do celu, zanim przeczytasz konfigurację peera, bo trasa wskazująca interfejs fizyczny omija całe pytanie.
Narzędzie zwykle instaluje te trasy z zakresów peerów, co oznacza, że zmiana na liście jednego peera może po cichu przekierować ruch, który wcześniej należał do innego. Edycja peera jest więc przebraną zmianą routingu. Przejrzyj oba naraz, inaczej naprawisz jedno i zepsujesz drugie.
Pakiety przychodzące są sprawdzane według źródła
Lista zakresów pełni podwójną rolę. Dla ruchu wychodzącego wybiera peera według celu, a dla ruchu przychodzącego autoryzuje adres źródłowy. Pakiet przychodzący z adresu spoza zakresów tego peera jest odrzucany, zanim zobaczy go jakikolwiek firewall.
Tę asymetrię łatwo przeoczyć, czytając jedną stronę konfiguracji. Peer, który może osiągnąć podsieć, nie jest przez to uprawniony do wysyłania z tej podsieci, a oba kierunki są wymuszane przez różne kontrole.
Wąska własność źródła zamienia to w zaletę. Daj każdemu peerowi /32 dla jego własnego adresu, a firewall poniżej ma wiarygodne źródło do dopasowania, zamiast zakresu całej grupy, którego mógłby żądać dowolny członek.
Zduplikowane zakresy to nie failover
Przypisanie tego samego prefiksu dwóm peerom nie tworzy load balancera ani ścieżki zapasowej. Nie ma kontroli stanu ani powinowactwa sesji: zwycięski wpis jest ustalany przez wewnętrzną kolejność implementacji, a to nie jest kontrakt, na którym należy projektować. Jeśli potrzebujesz alternatywnych wyjść, wyraź je tam, gdzie zdefiniowano wybór. Polityka routingu, metryka albo para różnych prefiksów z udokumentowanym właścicielem każdego dają zachowanie, które możesz przewidzieć i przetestować.
Poszerzanie zakresu, aby naprawić niepowiązaną awarię, to drugi częsty błąd. Odsuwa ruch od peera, który działał, a nowy objaw pojawia się, zanim stary zostanie zrozumiany.
Zweryfikuj wybór przed edycją
Trzy polecenia odpowiadają na trzy pytania po kolei. Pierwsze wymienia zakresy żądane przez każdego peera. Drugie pokazuje, którego interfejsu host użyłby dla celu. Trzecie pokazuje bieżący stan peerów po przepływie ruchu.
wg show wg0 allowed-ips ip route get 10.66.8.20 wg show wg0 ip rule show
Uruchom je przed zmianą i po niej, a potem porównaj. Jeśli wynik trasy się zmienił, ale ruch nadal dociera do niewłaściwego peera, listy prefiksów nakładają się w sposób, którego jeszcze nie opisałeś. Jeśli wynik trasy się nie zmienił, konfiguracja peera nigdy nie była tym, o co pytano.
Zapisz w zgłoszeniu cel, wybrany interfejs i wybranego peera. Właśnie ta trójka czyni nakładanie się sprawdzalnym później i jest znacznie użyteczniejsza niż zrzut ekranu konfiguracji.