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

Przykładowy scenariusz: Maya używa serwera VPS z systemem Debian 12 jako osobistego punktu końcowego VPN, gdy pracuje w kawiarni. Jej laptop powinien dotrzeć do serwera VPS przez szyfrowany tunel WireGuard i przesyłać ruch internetowy IPv4 przez ten serwer. Ten przykład nie jest raportem z testu na żywo; publiczne adresy IP, klucze i dane wyjściowe terminala pokazane poniżej to symbole zastępcze lub reprezentatywne makiety.

Ta konfiguracja to sieć VPN typu punkt-lokacja: jeden klient łączy się z jednym serwerem. Wykorzystuje ona narzędzia WireGuard z pakietu Debian, pojedynczy węzeł, przekierowanie IPv4 i NAT IPv4. Zakłada ona, że ​​VPS ma publiczny lub przekierowany adres IPv4. Można nim zarządzać za pomocą sudo, a port UDP 51820 jest do niego podłączony. Poniższy opis nie obejmuje konfiguracji routowanego IPv6 ani sieci prywatnej za VPS.

Najpierw zaplanuj adresy i dostęp

W przykładzie użyto 10.8.0.0/24sieci VPN 10.8.0.1na serwerze i 10.8.0.2pierwszym kliencie Maya. Użyj podsieci, która nie nakłada się na sieć Wi-Fi, sieć biurową ani chmurę klienta. Kolizja może spowodować skierowanie ruchu niewłaściwą trasą, nawet jeśli uzgadnianie zakończy się powodzeniem.

WireGuard korzysta z uwierzytelniania za pomocą klucza publicznego. Serwer potrzebuje klucza publicznego klienta, a klient potrzebuje klucza publicznego serwera; każdy klucz prywatny pozostaje na urządzeniu, które jest jego właścicielem. Dokumentacja WireGuard Debiana opisuje pakiet i konfigurację peera, a przewodnik szybkiego startu WireGuard dokumentuje generowanie kluczy i zachowanie funkcji keepalive. Zapoznaj się z dokumentacją WireGuard Debiana i przewodnikiem szybkiego startu WireGuard .

Skonfiguruj serwer Debian 12

1. Zainstaluj narzędzia

Zaktualizuj indeks pakietu i zainstaluj WireGuard oraz nftables, które dostarczą przykładową regułę maskowania IPv4. Uruchom je na serwerze VPS:

sudo apt update
sudo apt install wireguard nftables

Debian pakuje WireGuard za pomocą wireguardmetapakietu i jego narzędzi. Jeśli serwer korzysta już z menedżera zapory sieciowej, takiego jak UFW, firewalld lub reguł zarządzanych przez dostawcę, przed dodaniem czegokolwiek należy zidentyfikować aktywny zestaw reguł. Nie zastępuj istniejącej konfiguracji zapory tym przykładem.

2. Znajdź interfejs publiczny i włącz przekazywanie

Zapytaj tabelę routingu, którego interfejsu Debian używa do dotarcia do zewnętrznego adresu IPv4:

ip route get 1.1.1.1

W przykładzie trasa używa eth0. Twój VPS może wyświetlać inną nazwę, taką jak ens3lub enp1s0; użyj nazwy z własnego wyjścia w regule NAT później. Zwróć również uwagę na publiczny adres IPv4 serwera lub nazwę DNS. Jeśli serwer znajduje się za routerem, przekieruj UDP 51820 z tego routera do hosta Debian.

Przekierowanie IPv4 jest wymagane dla pełnego tunelu. Włącz je teraz i zapisz po ponownym uruchomieniu:

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. To ustawienie zezwala na przekazywanie pakietów; samo w sobie nie otwiera zapory sieciowej ani nie zapewnia NAT.

3. Utwórz klucz serwera i parę kluczy klienta

Utwórz klucz serwera na hoście Debian z ograniczonymi uprawnieniami do plików:

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'

Wygeneruj parę kluczy klienta na urządzeniu klienckim, jeśli to możliwe. Na kliencie z systemem Linux z wireguard-toolszainstalowanym:

umask 077
wg genkey | tee client.key | wg pubkey > client.pub

W przypadku telefonu utwórz nowy tunel w oficjalnej aplikacji WireGuard i pozwól jej wygenerować klucze profilu. Skopiuj na serwer tylko klucz publiczny klienta. Zachowaj go client.keyw tajemnicy; nigdy nie wklejaj go do konfiguracji serwera ani nie wysyłaj na czacie. Podręcznik Debian Bookwormwg(8) opisuje polecenia klawiszy i pola interfejsu.

4. Utwórz interfejs serwera i dodaj równorzędnego

Utwórz /etc/wireguard/wg0.confz następującą strukturą. Zastąp każdy symbol zastępczy wielką literą odpowiadającym mu kluczem rzeczywistym. Odczytaj lokalnie klucz prywatny serwera za pomocą sudo cat /etc/wireguard/server.key; umieść klucz publiczny klienta w sekcji równorzędnej.

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

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Chroń plik, ponieważ zawiera on klucz prywatny:

sudo chown root:root /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPs = 10.8.0.2/32Przypisuje temu użytkownikowi jeden adres VPN i uniemożliwia innemu użytkownikowi jego przejęcie. Każdemu dodatkowemu urządzeniu przypisz własną parę kluczy i odrębny adres, taki jak 10.8.0.3/32. Nie używaj ponownie jednego profilu klienta na wielu urządzeniach, jeśli potrzebujesz oddzielnego odwołania lub tożsamości.

5. Dodaj NAT IPv4 i zezwól na port WireGuard

W przypadku przykładowego pełnego tunelu IPv4 pakiety wychodzące 10.8.0.0/24muszą przechodzić przez interfejs publiczny z NAT-em źródłowym. Dodaj równoważną regułę do istniejącej konfiguracji NFTables serwera lub menedżera zapory. Ta samodzielna tabela NFTables ilustruje tę regułę; zastąp ją eth0interfejsem wykrytym w kroku 2:

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

Jeśli korzystasz z Debiana nftables.service, scal tabelę z konfiguracją ładowaną przez usługę podczas rozruchu i sprawdź poprawność całego pliku sudo nft -c -f /etc/nftables.confprzed jego ponownym załadowaniem. Sprawdź, czy bieżąca konfiguracja usuwa lub zastępuje istniejące reguły przed jej zastosowaniem. Sam NAT nie zastępuje polityki forward-chain, która blokuje ruch: zezwalaj na przekierowanie z interfejsu WAN i ruch powrotny w aktywnej zaporze sieciowej. Podręcznikwg0 Debiana opisuje ładowanie reguł nftables i instrukcje NAT.nft(8)

Zarówno w zaporze dostawcy VPS, jak i w zaporze dowolnego hosta, zezwól na przychodzący UDP 51820. Nie otwieraj TCP 51820 dla tego tunelu WireGuard. Zachowaj regułę dostępu SSH podczas zmiany polityki zapory i skorzystaj z konsoli dostawcy lub innej ścieżki odzyskiwania, jeśli ponowne załadowanie zapory mogłoby spowodować rozłączenie.

Skonfiguruj i podłącz klienta

6. Zbuduj profil klienta

Utwórz nowy tunel w aplikacji klienckiej WireGuard lub zapisz taką konfigurację na kliencie Linux. Zastąp klucz prywatny, klucz publiczny serwera i punkt końcowy rzeczywistymi wartościami. Poniższy adres TEST-NET jest tylko przykładem i nie dotrze do prawdziwego serwera.

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

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0Przekierowuje adresy IPv4 przez tunel, więc jest to pełny wybór tunelu IPv4. W przypadku wąskiego tunelu dzielonego, który dociera tylko do adresu serwera WireGuard, należy użyć 10.8.0.0/24zamiast tego. Aby dotrzeć do sieci LAN za serwerem, należy uwzględnić rzeczywistą podsieć tej sieci LAN w adresie klienta AllowedIPs, dodać trasę powrotną lub odpowiedni NAT i zezwolić na ruch przez zaporę sieciową serwera; te kroki zależą od routera sieci LAN i nie są uwzględnione w tym przykładzie.

PersistentKeepalive = 25Może pomóc klientowi za NAT pozostać dostępnym po okresach bezczynności. Jest to opcjonalne; dokumentacja WireGuarda podaje, że większość użytkowników tego nie potrzebuje, ale podaje 25 sekund jako powszechnie użyteczny interwał, w którym mapowanie NAT musi pozostać otwarte. To DNSpole jest obsługiwane przez niektórych klientów i klientów w oparciu o wg-quick; jeśli Twoja aplikacja je ignoruje, skonfiguruj DNS za pomocą własnych ustawień tej aplikacji.

7. Uruchom tunel i sprawdź uzgadnianie

W systemie Debian uruchom interfejs podczas rozruchu za pomocą:

sudo systemctl enable --now wg-quick@wg0
sudo wg show

Zaimportuj lub aktywuj profil klienta po osiągnięciu UDP 51820. W [tutaj należy wg showzaznaczyć pole "], sprawdź, czy oczekiwany peer pojawia się i czy latest handshakeaktualizuje się po wysłaniu ruchu przez klienta. W wg-quick(8)podręczniku Debian Bookworm opisano pomocnika konfiguracji interfejsu używanego przez jednostkę systemd.

Brak uzgadniania wskazuje przede wszystkim na dostępność lub niezgodność kluczy: należy potwierdzić adres i port punktu końcowego, reguły zapory UDP, klucz publiczny serwera w profilu klienta, klucz publiczny klienta w wg0.conforaz popraw czas systemowy. Uzgadnianie bez ruchu roboczego zazwyczaj wskazuje na przekierowanie, NAT, nakładanie się tras lub regułę łańcucha przekazywania zapory.

8. Zweryfikuj ruch i zapoznaj się z limitem IPv6

Po połączeniu klienta należy najpierw sprawdzić adres tunelowy serwera, a następnie sprawdzić publiczny adres IPv4 widziany przez zewnętrzną usługę sprawdzania adresów IPv4:

ping -c 3 10.8.0.1
curl -4 https://ifconfig.me

Ping powinien dotrzeć do serwera, jeśli protokół ICMP jest dozwolony. Zewnętrzne sprawdzenie IPv4 powinno pokazać publiczny adres wyjściowy serwera VPS dla konfiguracji pełnego tunelu. Jeśli adres publiczny się nie zmieni, sprawdź AllowedIPsprzekierowanie, nazwę interfejsu NAT oraz politykę przekierowania zapory.

Ten przykład dotyczy wyłącznie protokołu IPv4. AllowedIPs = 0.0.0.0/0Nie kieruje ruchem IPv6, więc klient z łącznością IPv6 może nadal wysyłać ruch IPv6 poza tunel. Nie należy opisywać tej konfiguracji jako kompletnego tunelu prywatności z dwoma stosami. Aby przesyłać ruch IPv6 przez WireGuard, należy przydzielić i przekierować adresy IPv6 dla tunelu, włączyć przekierowywanie IPv6, skonfigurować odpowiednią zaporę sieciową i reguły routingu, a następnie dodać ::/0klienta dopiero po tym, jak ścieżka będzie działać od początku do końca. Wsparcie dostawców jest zróżnicowane. W przeciwnym razie należy świadomie wybrać politykę podzielonego tunelu i sprawdzić zachowanie klienta w zakresie IPv6.

Typowe problemy i szybka kontrola końcowa

• Brak uzgadniania: potwierdź przychodzący protokół UDP 51820 na zaporach dostawcy i hosta, publiczny adres IP lub DNS punktu końcowego oraz publiczny klucz równorzędny każdej ze stron.
• Uzgadnianie działa, ale strony internetowe się nie ładują: sprawdź net.ipv4.ip_forward=1, reguła NAT używa faktycznego interfejsu wyjściowego, a zapora zezwala na przekazywany ruch.
• Tylko niektóre sieci ulegają awarii: sprawdź, czy 10.8.0.0/24nie nakłada się na sieć lokalną lub zdalną. W razie potrzeby zmień numerację tunelu, aktualizując jednocześnie oba urządzenia i regułę zapory.
• Działa do momentu ponownego uruchomienia: sprawdź, czy opcja wg-quick@wg0jest włączona i czy ustawienia zapory oraz sysctl są zachowane w normalnej konfiguracji systemu.
• Protokół IPv6 nadal korzysta z połączenia lokalnego: jest to oczekiwane w tym przykładzie wyłącznie z IPv4. Skonfiguruj i przetestuj trasę tunelu IPv6, zanim zaczniesz polegać na oświadczeniu o pełnej prywatności tunelu.

Przed zakończeniem konfiguracji należy sprawdzić, czy usługa serwera jest aktywna, wg showzgłasza niedawne uzgadnianie i rosnące liczniki transferów, klient może nawiązać połączenie 10.8.0.1, a sprawdzenie ruchu wychodzącego IPv4 zgłasza publiczny adres serwera. Zrestartuj serwer dopiero po wprowadzeniu trwałych ustawień zapory sieciowej i przekierowania, a następnie powtórz te sprawdzenia. W przypadku dodatkowych urządzeń równorzędnych należy wydać oddzielne pary kluczy i unikalne adresy IP tunelu, a następnie usunąć urządzenie, usuwając wpis dotyczący urządzenia równorzędnego i ponownie wczytując interfejs.