Uścisk dłoni WireGuard działa, ale podsieć biurowa nie odpowiada

Uścisk dłoni kończy się, wg show zgłasza niedawny transfer, a adres tunelu serwera odpowiada na ping. Host w sieci LAN serwera już nie. Trzy warunki muszą być spełnione jednocześnie: klient musi kierować prefiks sieci LAN do tunelu, serwer musi przekazywać pakiety, a odpowiedź potrzebuje drogi powrotnej. Gdy brakuje jednego z trzech, objaw jest identyczny.

AllowedIPs to zarówno lista dostępu, jak i tabela routingu

Na kliencie lista AllowedIPs decyduje zarówno o tym, co wolno wysłać do tego peera, jak i o tym, jakie trasy instaluje WireGuard. Wpis peera wymieniający tylko adres tunelu serwera instaluje jedną trasę do hosta, więc cele w sieci LAN nigdy nie trafiają do tunelu. Dodanie prefiksu sieci LAN to pierwsza rzecz do sprawdzenia, a zarazem zmiana, której najczęściej brakuje po skopiowaniu konfiguracji. Peer rozszerzony do trasy domyślnej to inny projekt i przeniesie także ruch internetowy klienta.

Trzymaj trasę do hosta i prefiks sieci LAN jako osobne wpisy. Jeśli biuro ma dwie podsieci, obie należą do listy, a brakujący drugi prefiks daje awarię, która wygląda na wybiórczą, a nie całkowitą.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Przekazywanie i tłumaczenie należą do serwera

Serwer potrzebuje włączonego przekazywania IP, reguły przekazywania, która akceptuje ruch przychodzący z tunelu, oraz reguły tłumaczenia w stronę jego interfejsu LAN. To tłumaczenie sprawia, że projekt działa bez dotykania każdego hosta w sieci biurowej. Odpowiedzi wracają wtedy do serwera, a nie na adres, o którym sieć LAN nigdy nie słyszała. Bez tego każdy host potrzebuje trasy do podsieci tunelu i reguły zapory, która ją dopuszcza, co rzadko jest akceptowalne w sieci zarządzanej przez kogoś innego.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Reguły dodane ręcznie znikają przy ponownym uruchomieniu, więc powiąż je z interfejsem za pomocą poleceń hook w konfiguracji serwera. Zbiór reguł, który przeżywa swój interfejs, to sposób, w jaki maszyna kończy tłumaczenie ruchu dla tunelu, który już nie istnieje.

Gdy sieć LAN się przeniosła, a reguła nie

Wymiana routera, która przenumerowuje podsieć biurową, to klasyczna wersja tej awarii. Tunel pozostaje włączony, uścisk dłoni pozostaje świeży, a nic za serwerem nie odpowiada, bo reguła tłumaczenia nadal wskazuje stary adres. Skrypty instalacyjne często wpisują adres LAN serwera do reguły POSTROUTING, a po przenumerowaniu ten adres nie istnieje na żadnym interfejsie. Pakiety są wtedy przepisywane na cel, który nie może odpowiedzieć.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Porównaj oba wyjścia. Cel tłumaczenia, którego nie ma na liście interfejsów, jest błędem, a jego naprawa to zmiana jednej linii, gdy już go zobaczysz. Reguła może mieszkać w wygenerowanym unicie, a nie w konfiguracji WireGuard, więc przeładuj ten unit po edycji i upewnij się, że następny start nie nadpisze twojej zmiany.

Dwie lokalizacje za NAT potrzebują miejsca spotkania

Gdy żadna strona nie akceptuje połączeń przychodzących, praktyczną odpowiedzią jest mały host z publicznym adresem i dwoma interfejsami WireGuard. Każda lokalizacja łączy się na zewnątrz, środkowy host wymienia sieć LAN każdego peera we własnym AllowedIPs, a przekazywanie przenosi pakiety między dwoma tunelami. Nic w zaporze żadnej z lokalizacji nie musi się zmieniać, dlatego ten projekt łatwo się rozprzestrzenia.

Routing między lokalizacjami zachowuje oryginalne adresy źródłowe i dzięki temu utrzymuje sensowne logowanie na host. Tłumaczenie na środkowym hoście jest prostsze, gdy obie sieci LAN się nakładają, ale kosztem utraty tożsamości źródła w logach. Zdecyduj, która właściwość jest ważna, zanim wybierzesz.

Oddziel warstwy czterema kontrolami

Wykonuj jedną kontrolę na warstwę, zamiast zmieniać trzy rzeczy i mieć nadzieję. Pierwsza pokazuje wiek uścisku dłoni i liczniki dla każdego peera. Druga pokazuje, czy klient naprawdę kieruje ten cel do tunelu. Trzecia i czwarta mówią, czy żądanie dotarło i czy jakaś polityka je odrzuciła po dotarciu.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Żądanie, które dociera i nie wywołuje odpowiedzi, wskazuje na ścieżkę odpowiedzi lub na host w sieci LAN. Żądanie, które nigdy nie dociera, wskazuje na AllowedIPs lub na trasę klienta. Te dwa wyniki wymagają różnych poprawek, a zrzut jest tym, co je rozróżnia.