Peer WireGuard wychodzi przez niewłaściwy WAN: pięć kontroli w kolejności

Dwa uplinki, jedna brama i peer WireGuard, którego ruch wciąż pojawia się na linii zapasowej. Uścisk dłoni pozostaje zdrowy przez cały czas. Dlatego objaw łatwo błędnie odczytać jako usterkę WireGuard, a nie jako błąd routingu.

Wykonaj poniższe kontrole po kolei. Każda ma warunek zatrzymania, a przeskoczenie naprzód zwykle daje pewną siebie błędną odpowiedź.

Oddziel uścisk dłoni od przekazywanego strumienia

Zaszyfrowana wymiana z peerem ma trasę do punktu końcowego publicznego adresu serwera. Przekazywany ruch klienta ma inny cel i może być wybierany przez oznaczenia lub reguły polityki. To dwie decyzje routingu, które dzielą jeden interfejs. Traktowanie jednej jako dowodu o drugiej to pierwszy błąd.

Zatrzymaj się, gdy tylko przyłapiesz się na wnioskowaniu z uścisku dłoni. To dowód wyłącznie o ścieżce do punktu końcowego.

Czytaj regułę polityki, a nie tabelę domyślną

Tabela domyślna pokazuje, co się dzieje, gdy żadna reguła polityki nie pasuje. Na bramie, która routuje według źródła, oznaczenia lub celu, decydująca reguła mieszka gdzie indziej. Zwykła tabela może wyglądać całkowicie rozsądnie, podczas gdy prawdziwy wybór dokonuje się nad nią.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Przeczytaj reguły polityki i tabele, na które wskazują. Następnie potwierdź, która reguła pasuje do twojego strumienia testowego. Reguła odwołująca się do interfejsu, który nie niesie już zamierzonego uplinku, jest ustaleniem, nie detalem. Wyszukanie trasy na końcu pokazuje odpowiedź znacznie szybciej niż czytanie tabeli i zgadywanie.

Sprawdź oznaczenie i translację razem

Routing polityki opiera się na oznaczeniu pakietu ustawionym wcześniej w łańcuchu. Jeśli reguła oznaczania pominie twój ruch, strumień wpada do tabeli głównej i wychodzi przez to, co tam jest domyślne. Przekazywane pakiety często omijają łańcuchy pisane dla ruchu generowanego lokalnie.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Translacja musi zgadzać się z uplinkiem, który niesie strumień. Reguła tłumacząca na adres podstawowy, gdy pakiet wychodzi linią zapasową, tworzy odpowiedzi adresowane do interfejsu, którego strumień nigdy nie użył. Sprawdź własny warunek interfejsu reguły translacji. Reguła bezwarunkowa działa, dopóki nie zostanie użyty drugi uplink, a potem zawodzi w sposób, który wygląda na przerywany.

Obserwuj, który interfejs niesie odpowiedź

Przechwytuj na obu uplinkach, gdy trwa jedno żądanie. Zanotuj, który interfejs niesie żądanie, a który odpowiedź. Ścieżki asymetryczne znacznie łatwiej zobaczyć niż przewidzieć.

Jeśli odpowiedź przyjdzie niewłaściwym uplinkiem, problem przeniósł się z WireGuard na śledzenie połączeń lub translację. Żadna zmiana konfiguracji peera tego nie naprawi.

Zmień jedną rzecz z drogą powrotną

Zachowaj dostęp przez konsolę lub poza pasmem, zanim zaczniesz edytować reguły polityki na bramie. Wprowadź jedną zmianę, przetestuj ten sam autoryzowany cel, następnie połącz się ponownie i potwierdź, że uścisk dłoni nadal używa zamierzonej ścieżki do punktu końcowego. Dodaj test liczbowy dla drugiej rodziny adresów, ponieważ polityka dotycząca tylko v4 pozostawia ten sam błąd dostępnym.

Zanotuj, którego uplinku użył każdy strumień. Ten zapis zamienia następny raport w dwuminutową kontrolę zamiast całego popołudnia. uwagi WireGuard o przestrzeniach nazw i routingu opisują, jak świadomie oddzielić ścieżkę do punktu końcowego od ruchu tunelowanego, co zwykle jest czystsze niż kopiowanie obejścia z trasą domyślną.