Czy klient WireGuard nie dociera do klienta OpenVPN?

Oba tunele się łączą, każdy klient dociera do bramy, a w chwili, gdy jeden próbuje adresu drugiego, pakiety znikają. Z żadnym z uścisków dłoni nie jest nic nie tak, a ponowne wydanie kluczy tego nie zmienia. Brama przenosi zwykłe niezaszyfrowane pakiety IP między dwoma własnymi interfejsami, więc protokoły nigdy nie muszą się rozumieć; potrzebują trzech rzeczy, których nie daje żaden uścisk dłoni. Pokrycie celu na kliencie źródłowym, własność źródła na bramie i ścieżka powrotna po drugiej stronie. Objaw jest taki sam dla wszystkich trzech, dlatego diagnozuje się je razem.

Objawowi brakuje za każdym razem jednego elementu

Ten projekt używa puli WireGuard 10.71.0.0/24 na wg1 i puli OpenVPN 10.72.0.0/24 na tun1, obie kończą się na jednej bramie. Testowane żądanie idzie z 10.71.0.5 do HTTPS na 10.72.0.30. Każdy krok poniżej dotyczy tego jednego przepływu. Każde sprawdzenie ma inny podpis awarii, choć użytkownik przeżywa je tak samo, i zwykle brakuje naraz tylko jednego z trzech.

Zacznij od potwierdzenia, że obie pule naprawdę są na tej bramie i że przekazywanie jest włączone w przestrzeni nazw, w której żyją tunele. Brama, która kończy oba protokoły w różnych przestrzeniach nazw, nic między nimi nie przekazuje, i warto to wykluczyć, zanim przeczytasz jakąkolwiek konfigurację peera.

Rozszerz pokrycie celu po stronie szprychy

Na kliencie WireGuard istniejący wpis peera musi wybrać bramę dla celu OpenVPN, co oznacza, że prefiks celu musi się znaleźć na liście dozwolonych tego peera. Dodanie go nie tworzy drugiego tunelu; zmienia to, którego peera klient wybiera, szukając tego adresu, a przy wg-quick trasa zwykle automatycznie podąża za listą.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Zostaw prawdziwe wiersze klucza i punktu końcowego nietknięte i pamiętaj, że menedżer używający Table = off w ogóle nie bierze żadnej trasy z tej listy. W takim przypadku ten sam prefiks musi zostać zainstalowany w tabeli routingu systemu przez tego, kto go posiada, a brakująca tam trasa wygląda dokładnie jak brakujący dozwolony prefiks.

Zachowaj własność źródła na bramie

Wpis peera tego klienta na bramie powinien nadal posiadać dokładnie adres źródłowy tego klienta. Dozwolone adresy są sprawdzane w obu kierunkach: wybierają peera dla ruchu wychodzącego i sprawdzają, że źródło pakietu przychodzącego należy do peera, który go wysłał. Umieszczenie puli OpenVPN we wpisie szprychy dlatego, że szprycha chce do niej dotrzeć, jest błędem, który kieruje ruch do niewłaściwego uczestnika.

AllowedIPs = 10.71.0.5/32

Czytaj ten wpis jako deklarację własności, a nie jako wygodę routingu. Wszystko inne, do czego klient musi dotrzeć, należy do listy celów klienta, a nie do wyobrażenia bramy o tym, co temu peerowi wolno wysyłać.

Daj stronie OpenVPN trasę powrotną

Cel potrzebuje teraz trasy z powrotem do źródła WireGuard, a dla klientów z puli zwykle przychodzi ona jako trasa wypchnięta z serwera OpenVPN. Wypychaj ją tylko do klientów, którzy powinni ją mieć, i potwierdź na kliencie, że została przyjęta, zamiast zakładać, że dyrektywa została zastosowana.

push "route 10.71.0.0 255.255.255.0"

Dystrybucja tras to nie autoryzacja. Gdy cel stoi za innym klientem OpenVPN, a nie w puli, własność własnej sieci LAN tego klienta i jego wymagania dotyczące przekazywania dołączają do projektu, a wypchnięta trasa to tylko pierwsza połowa. Przeformułuj wymaganie jako graf, zanim dodasz dyrektywy: który węzeł posiada który prefiks i który węzeł przekazuje w jego stronę.

Zezwól tylko na tę jedną usługę, na którą chciałeś zezwolić

Przy włączonym przekazywaniu i obu routowalnych pulach pozostaje pytanie o politykę. Napisz regułę dla konkretnego przepływu, a nie dla pary interfejsów ogólnie, podejrzyj ją przed zastosowaniem i zachowaj ścieżkę powrotną ze stanem, aby odpowiedzi nie były blokowane jako nowe połączenia. Próba na sucho nic nie kosztuje i pokazuje dokładnie, co zostałoby dodane.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

To reguły ruchu przekazywanego, odrębne od reguł nasłuchu bramy dla obu usług VPN. Otwarcie zewnętrznych portów UDP nie autoryzuje żądania wewnętrznego, a autoryzacja żądania wewnętrznego nie wymaga nieograniczonego SSH do bramy ani domyślnego zezwolenia na przekazywanie. Własna zapora celu i jego adres nasłuchu też muszą się zgadzać, ponieważ usługa przypisana do loopback odrzuca nawet najstaranniej zarutowany pakiet. Polityka obejmująca tylko jeden kierunek rozmowy zwykle zawodzi przy udanym żądaniu i cichej odpowiedzi, co jest najbardziej mylącym z trzech wyników.

Trasy wzajemne zwykle oznaczają, że tłumaczenie źródła nie jest potrzebne, co zachowuje adres WireGuard na celu i czyni logi czytelnymi. Nie dodawaj ogólnego masquerading tylko dlatego, że uczestniczą dwa protokoły, i nie usuwaj istniejącej reguły tłumaczenia bez wiedzy, co od niej zależy. Następnie zweryfikuj ten jeden przepływ od początku do końca i przetestuj także jedno zabronione źródło lub port: działający uścisk dłoni po każdej stronie nie dowodzi ani trasy krzyżowej, ani izolacji.