WireGuard tunel dzielony: konfiguracja bez trasy domyślnej

Tunel dzielony definiuje to, co pomijasz, a WireGuard podejmuje tę decyzję w jednym polu. AllowedIPs po stronie klienta jednocześnie wybiera, które cele idą przez tunel, i filtruje, które wewnętrzne adresy źródłowe są akceptowane, a wg-quick zamienia tę samą listę w trasy hosta. Jeśli lista jest błędna, tunel albo połyka wszystko, albo nic nie przenosi.

Najpierw ustal listę prefiksów

Zapisz cele, które muszą korzystać z tunelu, zanim dotkniesz pliku konfiguracyjnego. Podsieci biurowe, zakres bazy danych, sieć zarządzania: każdy jest prefiksem z powodem. Wszystko, czego nie ma na liście, zostaje na ścieżce fizycznej, i to jest cały sens projektu.

Jeśli lista zawiera 0.0.0.0/0 lub ::/0, zbudowałeś pełny tunel i powinieneś to powiedzieć, bo tryby awarii i oczekiwania DNS są inne.

Utrzymuj listę na tyle krótką, by recenzent mógł ją później porównać z tabelą routingu.

Konfiguracja klienta: peer, AllowedIPs, DNS

Blok interfejsu klienta zawiera jego własny adres tunelu i klucz prywatny. Blok peera zawiera klucz publiczny serwera, punkt końcowy i prefiksy z pierwszego kroku:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs po stronie klienta to zbiór celów zdalnych, a nie własny adres klienta. Wiersz DNS działa tylko przez integrację resolvera w wg-quick, więc host bez obsługi resolvconf lub systemd-resolved zignoruje go. PersistentKeepalive utrzymuje mapowanie NAT przy życiu i jest zbędny na ścieżce bezpośredniej.

Skomentuj każdy prefiks usługą, której służy, inaczej następna zmiana będzie zgadywaniem.

Konfiguracja serwera: przeciwny punkt widzenia

Na serwerze wpis peera reprezentuje klienta, więc jego AllowedIPs to adres tunelu klienta, zwykle /32. To nie jest podsieć biurowa. Kopiowanie listy klienta do wpisu serwera to najczęstszy błąd tunelu dzielonego, i albo poszerza dostęp, albo psuje wewnętrzną kontrolę źródła podczas uzgadniania.

Własny adres interfejsu serwera i trasy, których potrzebuje w stronę biura, są oddzielone od każdego wpisu peera.

Dwa pliki, dwa punkty widzenia, jeden zestaw prefiksów podzielony między nie.

Podnieś go i odczytaj trasy

Uruchom interfejs obsługiwanym menedżerem, a potem patrz na to, co zainstalował, a nie na to, co zamierzałeś. wg-quick wyprowadza trasy z AllowedIPs; jeśli profil ustawia Table = off, nic nie jest instalowane i routing należy do ciebie. Odczytaj trasę każdego prefiksu i potwierdź, że wskazuje interfejs WireGuard. Pusta lista tras zwykle oznacza, że zastosowany profil nie jest tym, który edytowałeś.

Sprawdź też liczniki uzgadniania, bo peer bez uzgadniania ma problem z kluczem, punktem końcowym lub osiągalnością, a nie z routingiem.

Zapisz dokładne polecenie, którego użyłeś, bo następna osoba uruchomi je pod presją.

Sprawdź obie strony, a potem zapisz wycofanie

Przetestuj adres prywatny, jego nazwę wewnętrzną i cel, który musi pozostać bezpośredni. Jeśli adres prywatny działa, a cel bezpośredni wychodzi teraz przez tunel, lista prefiksów jest zbyt szeroka. Jeśli nazwa zawodzi, gdy adres działa, wiersz DNS nie wszedł w życie. Wycofanie to jedno polecenie i należy do tej samej notatki.

Po ponownym połączeniu potwierdź, że trasy nadal są, bo menedżer, który ponownie stosuje profil, może zastąpić trasy ręczne.

Trzymaj jednego właściciela konfiguracji, bo dwaj menedżerowie tworzący ten sam interfejs w końcu się pokłócą. Podręcznik wg-quick dokumentuje obsługę tras i DNS, którą zapewnia.