Jak zbudować test WireGuard z dwoma peerami, który dowodzi jednej ścieżki

Test WireGuard niosący domyślną trasę, prefiks LAN, DNS i wyjątek w zaporze nie potrafi powiedzieć, który z nich zawiódł. Zredukuj go do dwóch peerów, jednej pary adresów i jednej dozwolonej usługi, a awaria nie ma się gdzie ukryć. Nudna baza jest diagnozą. Zbuduj ją najpierw; zajmuje piętnaście minut i oszczędza popołudnie, które inaczej spędziłbyś na zgadywaniu.

To, co dowodzi baza, jest węższe, niż oczekuje większość. Dowodzi, że dwie tożsamości się zgadzają, że UDP dociera do portu nasłuchu i że jeden dozwolony cel niesie żądanie. Forwarding, NAT, trasy LAN i DNS to osobne funkcje dodawane później, jedna po drugiej.

Klucze, adresy i jedyny endpoint

Wygeneruj parę kluczy w każdym systemie i przenieś między nimi tylko publiczne połowy. wg genkey | tee privatekey | wg pubkey > publickey to udokumentowana jednolinijkowa komenda, a prywatny klucz zostawia w pliku, który możesz potem zabezpieczyć. Wybierz adresy tunelu z zakresu, który nie występuje w żadnej innej twojej konfiguracji, na przykład 10.99.0.1/24 i 10.99.0.2/24. Zapisz, który adres należy do której maszyny, bo każde późniejsze sprawdzenie zależy od tego mapowania.

Klucze prywatne nigdy nie podróżują. Jeśli test wymaga skopiowania jednego na drugą stronę, test już poszedł nie tak. Gdy oba systemy siedzą za NAT, co najmniej jeden potrzebuje osiągalnego portu UDP, podczas gdy drugi niesie Endpoint wskazujący na niego, a publiczny adres i port należą do twoich notatek, nie do twoich założeń o 51820.

Przekierowanie portu, które mapuje inny port zewnętrzny, działa dobrze, dopóki Endpoint mu odpowiada. Rozbieżności tutaj dają ciszę zamiast błędów, dlatego warto je sprawdzić na papierze, zanim zaczniesz debugować na kablu.

Pola, które należą do wg, i te, które nie

Zestaw pól rdzeniowych jest mały: PrivateKey i ListenPort pod Interface, PublicKey, AllowedIPs i Endpoint pod Peer. Address i DNS należą do wg-quick, a nie do samego wg, i ta różnica kąsa w momencie, gdy ta sama konfiguracja przenosi się do innego narzędzia.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs pełni dwie funkcje naraz. Wybiera, które cele wchodzą do tunelu, i upoważnia peera do używania tych adresów źródłowych przy przybyciu. Dlatego lustrzany wpis po drugiej stronie musi dokładnie nazwać adres twojego tunelu; /32 dla złego peera czyta się jak problem z routingiem i zachowuje się jak problem z autoryzacją. Szybki start WireGuard pokazuje ten sam kształt dwóch peerów z kanonicznym sformułowaniem, jeśli chcesz porównać nazwy pól.

Czytanie uzgadniania zamiast ikony

Podnieś interfejs przez to, co go posiada, potem czytaj stan, a nie lampkę statusu. wg show wypisuje ostatnie uzgadnianie dla każdego peera wraz z licznikami bajtów, a uzgadnianie w ciągu ostatnich kilku minut oznacza, że klucze, endpoint i ścieżka UDP działają. Licznik rosnący tylko w jedną stronę jest własną odpowiedzią i nie jest tym samym błędem co uzgadnianie, które nigdy nie następuje.

Dwa błędy sugerują różne dochodzenia. Całkowity brak uzgadniania wskazuje na niezgodność kluczy, zły Endpoint, zablokowany UDP lub zaporę, która zrzuca samo uzgadnianie. Uzgadnianie, które się udaje, gdy dane nigdzie nie docierają, wskazuje na AllowedIPs, usługę, która nie nasłuchuje na adresie tunelu, albo zaporę hosta, która przyjmuje port dla LAN, ale nie dla interfejsu tunelu. To różne połowy systemu, a baza je rozdziela, zanim zaczniesz zmieniać reguły.

Udowodnić jedną dozwoloną usługę, potem odwrotnie

Wyślij żądanie na adres tunelu drugiego peera do usługi, która ma odpowiadać, i wybierz coś lepszego niż ping. Brak odpowiedzi ICMP może być filtrowaniem hosta, a nie awarią tunelu, więc cichy ping nie dowodzi żadnego kierunku. Połączenie TCP do portu, o którym wiesz, że jest otwarty, albo żądanie zwracające dane daje odpowiedź, którą można zinterpretować.

Uruchom kierunek odwrotny jako osobny test z własnym wynikiem, bo oba kierunki mają osobne wpisy zapory i AllowedIPs i mogą zawieść niezależnie. Jeśli uzgadnianie działa, a żądanie nie, problem leży w ścieżce danych, nie w tunelu: AllowedIPs, usługa nasłuchująca albo zapora hosta. Napraw to, zanim dodasz forwarding, NAT lub DNS, inaczej spędzisz popołudnie na debugowaniu funkcji, która nigdy nie była winna.

Utrzymanie bazy jako odniesienia

Zapisz działającą topologię i źródło profilu w miejscu, z którego możesz przywrócić, i trzymaj je poza każdym katalogiem, który synchronizuje się z publiczną usługą. Potem dodawaj jedną funkcję naraz, powtarzając oryginalne żądanie po każdej: forwarding, NAT, trasę LAN i dopiero potem DNS. Każdy dodatek, który psuje test, jest teraz rozpoznawalny, bo nic innego się nie ruszyło.

Baza, która tylko zmienia ikonę na zieloną, nie powiedziała ci nic o tym, który dodatek spowodował następną awarię. Utrzymuj jedyną dozwoloną ścieżkę w działaniu jako odniesienie, a każdą późniejszą zmianę mierzy się względem niej.