Jak skonfigurować serwer VPN typu punkt-lokacja WireGuard w systemie Debian 12

Sieć VPN typu punkt-lokacja WireGuard w systemie Debian 12 (Bookworm) to praktyczny sposób na umożliwienie laptopom, telefonom lub zdalnym stacjom roboczym dostępu do serwera lub kierowania przez niego ruchu. Na początek należy wyjaśnić jedno ważne: WireGuard nie posiada specjalnego „trybu serwera”. Każdy uczestnik jest równorzędny. W architekturze punkt-lokacja jeden host Debian działa po prostu jako stabilny, publicznie dostępny hub, a każde zdalne urządzenie otrzymuje własną parę kluczy i adres tunelu.

W tym przewodniku wykorzystano narzędzia WireGuard pakietu Debian, wg-quickprzekierowanie IPv4 oraz bibliotekę nftables. Zakłada się, że serwer Debian ma dostęp do konta root lub sudo i że port UDP 51820jest do niego dostępny. Jeśli serwer znajduje się za routerem domowym lub biurowym, należy przekierować ten port UDP do hosta Debian. Jeśli dostawca usług internetowych korzysta z NAT klasy operatorskiej (CGNAT), zwykłe przekierowanie portów routera może nie wystarczyć; przed przystąpieniem do rozwiązywania problemów z samym WireGuardem należy upewnić się, że adres publiczny jest osiągalny.

Co będzie robić ta konfiguracja?

Przykładowa sieć VPN używa 10.8.0.0/24. Serwer to 10.8.0.1, a pierwszy klient to 10.8.0.2. Klienta można skonfigurować jako sieć VPN z pełnym tunelem, w której ruch internetowy IPv4 wychodzi przez serwer Debian, lub jako tunel rozdzielony, w którym tylko wybrane sieci prywatne korzystają z WireGuard.

Własna dokumentacja WireGuard Debiana potwierdza, że ​​WireGuard jest dostępny w pakietach dystrybucyjnych, natomiast oficjalna dokumentacja szybkiego startu WireGuard dotyczy generowania kluczy, wg-quickoraz opcjonalnego zachowania funkcji keepalive. Zapoznaj się z dokumentacją WireGuard Debiana , oficjalną dokumentacją szybkiego startu WireGuard oraz stroną podręcznika wg-quick Debiana .

Krok 1: Zainstaluj WireGuard i nftables

Zaktualizuj metadane pakietu, a następnie zainstaluj WireGuard i nftables:

sudo apt update
sudo apt install wireguard nftables

Powszechnym błędnym przekonaniem jest to, że Debian 12 potrzebuje modułu jądra WireGuard spoza drzewa. Tak nie jest. WireGuard jest obecny w jądrze Linuksa od lat; pakiety Debiana zapewniają niezbędne narzędzia do zarządzania przestrzenią użytkownika. Działanie: użyj pakietów Debiana zamiast pobierać niezweryfikowany skrypt instalacyjny.

Krok 2: Wygeneruj parę kluczy serwera

Utwórz pliki kluczowe z ograniczonymi uprawnieniami:

sudo -i
install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key
cat /etc/wireguard/server_public.key

Klucz prywatny musi pozostać prywatny. Klucz publiczny to ten, który kopiujesz do konfiguracji klienta. Najlepiej generować klucz prywatny każdego klienta na tym kliencie, a nie na serwerze. W ten sposób serwer nigdy nie będzie musiał posiadać kluczy prywatnych klienta.

Krok 3: Włącz przekierowywanie IPv4

Tunel VPN może się pomyślnie uruchomić, mimo że ruch routowany nadal nie działa. Powodem jest to, że przekierowywanie IP w Linuksie jest oddzielnym ustawieniem jądra od samego WireGuard. Utwórz trwały plik sysctl:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Ostatnie polecenie powinno zwrócić net.ipv4.ip_forward = 1. Dokumentacja jądra Debiana opisuje to ip_forwardjako przełącznik umożliwiający przekazywanie pakietów IPv4. Działanie: należy jawnie zweryfikować tę wartość, zamiast zakładać, że interfejs tunelu automatycznie włącza routing. Zapoznaj się z podręcznikiem Debiana ip(7) i dokumentacją pliku sysctl.conf .

Krok 4: Utwórz konfigurację serwera

Odczytaj prywatny klucz serwera, a następnie utwórz /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Następnie zabezpiecz plik:

sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPsjest często błędnie rozumiany jedynie jako lista dozwolonych adresów w stylu zapory sieciowej. Kontroluje on również routing. Na serwerze przypisanie 10.8.0.2/32do tego adresu informuje WireGuard, że pakiety dla tego konkretnego adresu tunelu należą do tego klienta. Nadaj każdemu klientowi unikalny adres i oddzielny [Peer]blok.

Inną przydatną opcją jest pominięcie tej opcji, SaveConfig = truejeśli zamierzasz zarządzać tym plikiem ręcznie. Za pomocą tej opcji SaveConfigmożesz wg-quickzapisać stan na żywo z powrotem do konfiguracji podczas wyłączania systemu, co może nadpisać ręczne zmiany. Działanie: zachowaj deklaratywny plik, chyba że chcesz zapisać stan na żywo.

Krok 5: Skonfiguruj maskowanie nftables

Jeśli klienci korzystający z pełnego tunelu mają uzyskać dostęp do Internetu przez serwer Debian, najłatwiejszym rozwiązaniem jest maskowanie IPv4. Najpierw zidentyfikuj interfejs wychodzący serwera:

ip route get 1.1.1.1

Poszukaj interfejsu po dev, takiego jak eth0, ens3lub enp1s0. Nie zakładaj, że zawsze jest to eth0.

Jeśli już utrzymujesz /etc/nftables.conftabelę NAT, zamiast zastępować plik, scal ją z istniejącym zestawem reguł:

table ip wireguard-nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "eth0" ip saddr 10.8.0.0/24 masquerade
    }
}

Zastąp eth0rzeczywistym interfejsem wychodzącym. Sprawdź poprawność przed załadowaniem:

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list ruleset

NAT nie jest z natury wymagany przez WireGuard. Jeśli docelowa sieć LAN ma już trasę powrotną do 10.8.0.0/24, dostęp trasowany może działać bez maskowania. NAT jest wygodny głównie wtedy, gdy chcesz, aby klienci zdalni korzystali z istniejącej trasy internetowej serwera, a nie kontrolujesz tras powrotnych w innym miejscu. Działanie: użyj maskowania w przypadku prostego ruchu wychodzącego z Internetu; preferuj jawne routingowanie, gdy kontrolujesz sieć i chcesz zachować adresy źródłowe.

Czy potrzebujesz również reguł zapory sieciowej?

Zależy to od zainstalowanej zapory sieciowej. Jeśli polityka wejściowa nftables jest restrykcyjna, zezwól na przychodzący ruch UDP 51820. Jeśli łańcuch forward ma domyślną politykę odrzucania, dodaj tam reguły, aby zezwolić na ruch z wg0miejsca docelowego i zezwolić na ustanowiony ruch powrotny. Dostawcy serwerów VPS w chmurze mogą również mieć osobną grupę zabezpieczeń lub zaporę sieciową dostawcy, która musi zezwalać na ruch UDP 51820.

Nie wklejaj bezmyślnie zupełnie nowego, domyślnego zestawu reguł zapory sieciowej do zdalnego serwera SSH. To może Cię zablokować. Działanie: sprawdź sudo nft list ruleseti zintegruj WireGuard z zaporą sieciową, którą już posiadasz.

Krok 6: Zbuduj profil klienta

Na kliencie wygeneruj własną parę kluczy za pomocą aplikacji WireGuard lub wg genkey. Pełny profil IPv4 tunelu wygląda następująco:

[Interface]
Address = 10.8.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Zastąp vpn.example.compubliczną nazwą DNS lub publicznym adresem IP serwera. Ten DNSwiersz jest opcjonalny, a obsługa implementacji klienta jest różna. W przypadku tunelu dzielonego zmień AllowedIPstylko na sieci, które powinny przechodzić przez VPN, na przykład 10.8.0.0/24plus prywatną sieć LAN, taką jak 192.168.50.0/24.

PersistentKeepalive = 25Jest również opcjonalny. Oficjalna dokumentacja WireGuard zaleca 25 sekund jako rozsądną wartość, gdy komputer za NAT lub zaporą stanową musi zachować swoje mapowanie w okresach bezczynności. Nie jest to ustawienie wydajnościowe i nie jest obowiązkowe dla każdego klienta. Działanie: należy go używać głównie w przypadku klientów mobilnych lub korzystających z NAT, którzy w przeciwnym razie stają się niedostępni po okresie bezczynności.

Krok 7: Uruchom WireGuard podczas rozruchu

Najpierw uruchom nftables, a następnie włącz interfejs WireGuard:

sudo systemctl enable --now nftables
sudo systemctl enable --now wg-quick@wg0
systemctl is-active nftables
systemctl is-active wg-quick@wg0

wg-quick@wg0odczytuje /etc/wireguard/wg0.conf. W wg-quickpodręczniku potwierdzono, że ta konwencja nazewnictwa jest standardowym skrótem dla konfiguracji przechowywanych w /etc/wireguard. Działanie: użyj usługi zamiast niestandardowego skryptu rozruchowego, chyba że masz bardziej złożony projekt menedżera sieci.

Krok 8: Sprawdź uzgadnianie i ruch

Podłącz klienta, a następnie sprawdź serwer:

sudo wg show
ip address show wg0
ping -c 3 10.8.0.2

Zdrowy peer zazwyczaj pokazuje niedawne uzgadnianie i liczniki transferów niezerowe po przekroczeniu tunelu. Jeśli skonfigurowano pełny tunel, sprawdź publiczny adres IPv4 klienta za pomocą zaufanej usługi sprawdzania adresów IP; powinien on być zgodny z adresem wyjściowym serwera Debian.

Typowe problemy i ich znaczenie

Tunel pełny czy tunel dzielony: który wybrać?

Użyj pełnego tunelu, gdy celem jest ochrona ruchu w niezaufanych sieciach Wi-Fi lub umożliwienie wyjścia ruchu internetowego z serwera Debian. Użyj tunelu dzielonego, gdy potrzebujesz jedynie zdalnego dostępu do serwera, sieci domowej, laboratorium lub aplikacji wewnętrznej i chcesz, aby normalny ruch internetowy pozostał lokalny. Wybór jest kontrolowany przede wszystkim przez klienta AllowedIPs.

W przypadku niewielkiego wdrożenia typu punkt-lokacja powyższa konfiguracja wystarczy do ustanowienia łatwej do utrzymania linii bazowej: jeden blok peerów na klienta, unikalne adresy tuneli, usługi zarządzane przez Debian oraz pliki NFTables dla faktycznie potrzebnego sposobu routingu. W przypadku większych wdrożeń, dystrybucja kluczy, cykl życia peerów, DNS, logowanie i zarządzanie konfiguracją stają się kwestiami operacyjnymi, mimo że sam protokół WireGuard pozostaje prosty.

Lista kontrolna ostatecznej weryfikacji

• wg-quick@wg0jest aktywny i wg0ma 10.8.0.1/24.
• Serwer nasłuchuje na protokole UDP 51820, a do tego portu można dotrzeć poprzez dowolną zaporę sieciową lub router.
• Każdy klient ma swoją własną parę kluczy i unikalny /32wpis na serwerze.
• net.ipv4.ip_forwardrówna się, 1gdy wymagany jest dostęp trasowany.
• Maskarada nftables jest dostępna w przypadku pełnego tunelu dostępu do Internetu, chyba że celowo użyjesz ścieżek powrotnych.
• wg showwyświetla ostatnie uzgadnianie po wysłaniu ruchu przez klienta.
• Klient AllowedIPsdopasowuje zamierzony projekt tunelu pełnego lub podzielonego.

Te kroki dotyczą systemu Debian 12 i standardowych narzędzi WireGuard dostępnych w Debianie. Topologia sieci, NAT nadrzędny, zapory sieciowe w chmurze, routing w prywatnych sieciach LAN i polityka IPv6 są specyficzne dla danego środowiska, więc nie można ich wywnioskować wyłącznie na podstawie konfiguracji WireGuard. Należy zweryfikować każdy z nich osobno, zamiast traktować każdy problem z łącznością jako awarię WireGuard.