WireGuard AllowedIPs: trasa, której NetworkManager nigdy nie dodał

Licznik uzgodnień się aktualizuje, interfejs zachowuje swój adres, a ping na drugą stronę nigdzie nie dociera. Ta kombinacja myli ludzi, bo działające uzgadnianie wygląda jak dowód, że tunel jest gotowy. Nie jest: tunel może być w pełni wynegocjowany i nadal nie mieć żadnej trasy, która kierowałaby do niego ruch, a to dwa osobne zadania wykonywane przez dwa osobne fragmenty stanu. Poprawka zależy wyłącznie od tego, którego z tych dwóch brakuje, więc pierwszym krokiem jest to ustalić.

wg-quick robi oba bez proszenia. Wbudowana obsługa WireGuard w NetworkManagerze domyślnie instaluje też trasy do peerów, co zawęża podejrzanych do wyłączonej opcji, innej tabeli routingu albo konfiguracji zaimportowanej przez coś innego.

Potwierdź tunel, zanim ruszysz za trasą

wg show wypisuje interfejs, peera, punkt końcowy i wiek ostatniego uzgodnienia, a ip addr show potwierdza, że adres jest obecny. Niedawne uzgodnienie oznacza, że klucze, punkt końcowy i ścieżka UDP działają. Wszystko zepsute siedzi poniżej nich: routing, filtrowanie albo rozwiązywanie nazw.

Potem zapytaj jądro, co zrobiłoby z rzeczywistym celem zamiast hipotetycznym: ip route get 10.42.7.9. Odpowiedź wskazuje interfejs wyjściowy i adres źródłowy, który niósłby pakiet. Gdy wskazuje fizyczny adapter, pakiet nigdy nie wchodzi do tunelu, niezależnie od tego, jak zdrowy wygląda uzgodnienie.

AllowedIPs to filtr i lista tras

Prefiksy w AllowedIPs robią dwie rzeczy. Wybierają, który peer niesie cel wychodzący, i sprawdzają adres źródłowy pakietów przychodzących, co jest granicą routingu po kluczu kryptograficznym. W wg-quick sterują też automatyczną instalacją tras, i właśnie to dodatkowe zachowanie jest powodem, dla którego ta sama konfiguracja działa z terminala, a nie z klienta biurkowego.

W przypadku stojącym za tym artykułem profil został zaimportowany przez wtyczkę innej firmy, a nie przez wbudowaną obsługę, i interfejs podniósł się bez trasy prefiksu. Wypisanie tablicy pokazuje to od razu: ip route show zawiera tylko trasę połączoną dla adresu interfejsu i nic dla zakresu zdalnego.

Zapytaj, czy trasy do peerów są w ogóle włączone

Przeczytaj ustawienie, zanim cokolwiek zmienisz: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Gdy peer-routes pokazuje no, obsługiwaną naprawą jest nmcli connection modify work-wg wireguard.peer-routes yes, po czym następuje ponowne połączenie. Dodanie zamiast tego trasy statycznej działa do następnej aktywacji, a potem cicho znika. To znikanie jest wskazówką: trasy, która co rano wraca jako zagadka, nie instaluje profil.

Jeśli opcja jest już włączona, sprawdź, czy prefiks mieszka w innej tablicy, używając ip route show table all | grep 10. Trasa w tablicy innej niż główna nie brakuje, jest po prostu niewidoczna dla wyszukiwania, które zagląda tylko do tabeli głównej. Napraw routing polityki, zamiast piętrzyć na wierzchu zduplikowany wpis.

Dodaj prefiks do połączenia, a nie do działającego systemu

W edytorze połączeń strona WireGuard trzyma peera i jego AllowedIPs, a strona IPv4 trzyma dodatkowe trasy. Trasa dodana tam przetrwa ponowne połączenia, bo należy do profilu. W wierszu poleceń odpowiednikiem jest dołączenie trasy do połączenia w formie z pustą bramą, a następnie opuszczenie i podniesienie połączenia, aby zmiana została zastosowana.

Wybierz najwęższy prefiks, który obejmuje potrzebne hosty. Skopiowanie przykładu /8 od dostawcy może połknąć lokalne zakresy, które przypadkiem się w nim znajdują, a wynikające z tego awarie wyglądają jak zepsuty tunel, a nie zbyt szeroka trasa.

O tunelowaniu dzielonym decyduje lista prefiksów

Nie ma przełącznika tunelu dzielonego; listą prefiksów jest decyzją. Peer z jednym zakresem dla LAN biura i jednym dla sieci laboratoryjnej wysyła dokładnie te cele przez tunel i zostawia całą resztę w spokoju. Pojedynczy host potrzebuje /32, a zakresy nakładające się w dwóch miejscach potrzebują prefiksów hosta, dopóki ktoś nie przenumeruje podsieci.

Wybór, by nic nie wysyłać przez tunel, doprowadza tę samą decyzję do granicy: minimalna lista utrzymuje łącze, podczas gdy zwykły ruch trzyma się swojej zwykłej drogi. Zapisz intencję, bo inaczej następny czytelnik weźmie krótką listę za przeoczenie i pomocnie ją rozszerzy.

Jeden właściciel tabeli routingu

wg-quick i NetworkManager oba uważają, że posiadają trasy interfejsu. Zaimportuj konfigurację napisaną dla wg-quick, a potem uruchom także usługę wg-quick, i dostaniesz zduplikowane lub sprzeczne wpisy, których zachowanie zależy od tego, który zadziałał ostatni. Wybierz jednego właściciela i usuń drugiego: jeśli NetworkManager zarządza połączeniem, wyłącz jednostkę wg-quick dla tego interfejsu i nigdy nie dodawaj drugiego profilu dla tego samego urządzenia.

Kiedy podział musi podążać za fizycznym adapterem zamiast za celem, przeszedłeś na routing polityki, a routing polityki też wymaga jednego autora. Sprawdź, powtarzając ip route get, a następnie docierając do hosta wewnątrz zdalnego prefiksu czymś, co wypisuje wybrany adres źródłowy. Sprawdź IPv6 i DNS osobno, jeśli profil niesie którykolwiek z nich.