Konfiguracja WireGuard Windows

Ten przewodnik wyjaśnia, jak skonfigurować tunel VPN WireGuard między dwoma komputerami z systemem Windows: serwerem WireGuard działającym na zdalnym hoście Windows, na przykład na VPS-ie z systemem Windows, oraz klientem WireGuard działającym na lokalnym komputerze z systemem Windows. Gdy tunel jest aktywny, oba komputery wymieniają dane przez szyfrowane połączenie prywatne, a opcjonalnie można kierować cały ruch klienta przez serwer.

Aby uprościć generowanie kluczy, ten przewodnik tworzy zarówno konfigurację serwera, jak i klienta w obrębie jednej aplikacji WireGuard, a następnie wdraża każdy plik konfiguracyjny na komputerze, do którego należy. Konfiguracja serwera działa na serwerze, a konfiguracja klienta na kliencie. Serwer i klient to zawsze osobne komputery. Ten sam proces służy do dodawania dowolnej liczby kolejnych klientów.

Przed rozpoczęciem zainstaluj najnowszą wersję WireGuard z oficjalnej strony instalacji (https://www.wireguard.com/install/) zarówno na serwerze, jak i na kliencie, oraz upewnij się, że masz uprawnienia administratora na każdym komputerze.

Konfiguracja w tym przewodniku wygląda następująco:

Server (public IP, listening on UDP 51820)
Tunnel address 10.0.0.1/24
        |
        |  encrypted WireGuard tunnel
        |
Client
Tunnel address 10.0.0.2/32

Tworzenie konfiguracji serwera

Uruchom C:\Program Files\WireGuard\wireguard.exe, kliknij Add tunnel i wybierz Add empty tunnel. WireGuard automatycznie generuje parę kluczy. Klucz publiczny wyświetlany u góry okna to klucz publiczny serwera. Będzie potrzebny później, podczas konfiguracji klienta.

Nadaj tunelowi nazwę i wypełnij sekcję interface kluczem prywatnym serwera, portem, na którym WireGuard będzie nasłuchiwać, oraz adresem wewnętrznym, którego serwer będzie używać wewnątrz tunelu.

[Interface]
PrivateKey = # private key of the WireGuard server
ListenPort = # port that WireGuard will listen on
Address = # internal IP address of the WireGuard server, for example 10.0.0.1/24

Użyj prywatnej podsieci dla sieci tunelu i utrzymuj serwer oraz wszystkich klientów w tym samym zakresie. Częstym wyborem jest 10.0.0.1/24 dla serwera oraz 10.0.0.2/32, 10.0.0.3/32 i tak dalej dla każdego klienta. Serwer używa prefiksu /24, dzięki czemu traktuje cały zakres tunelu jako osiągalny przez interfejs WireGuard. Każdy klient używa /32, ponieważ klient reprezentuje pojedynczy adres, a nie podsieć. Klient ustawiony na /24 zakładałby, że cały zakres znajduje się na jego własnym interfejsie, i nie wysyłałby przez tunel ruchu przeznaczonego dla innych adresów tunelu.

W edytorze tunelu, poniżej pola konfiguracji, możesz opcjonalnie włączyć Block untunneled traffic (kill-switch), który blokuje wszelki ruch wychodzący poza tunel, oraz ustawić Pre-shared key, który dodaje dodatkową warstwę zabezpieczeń. Obie opcje są opcjonalne. Zobacz sekcję „Zrozumienie AllowedIPs", aby dowiedzieć się, kiedy kill-switch jest przydatny i co blokuje.

Tworzenie konfiguracji klienta

Kliknij Add tunnel i wybierz Add empty tunnel po raz drugi, tym razem dla klienta. Klucz publiczny wyświetlany dla tego tunelu to klucz publiczny klienta, którego serwer potrzebuje, aby zaakceptować klienta.

Wypełnij konfigurację klienta:

[Interface]
PrivateKey = # private key of the WireGuard client
Address = # internal IP address of the WireGuard client, for example 10.0.0.2/32
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = # public key of the WireGuard server
AllowedIPs = # 0.0.0.0/0 for a full tunnel, or 10.0.0.0/24 for a split tunnel
Endpoint = # public IP address and port of the WireGuard server
PersistentKeepalive = 25

Endpoint musi być rzeczywistym publicznym adresem IP serwera wraz z portem ustawionym w ListenPort serwera, a nie wewnętrznym adresem tunelu. Pomoc w wyborze wartości AllowedIPs znajdziesz w sekcji „Zrozumienie AllowedIPs" poniżej.

Wiersze DNS i PersistentKeepalive są opcjonalne. DNS ustawia serwery DNS używane, gdy tunel jest aktywny, co zapobiega problemom z rozpoznawaniem nazw po połączeniu. Możesz użyć publicznych resolverów, takich jak 1.1.1.1, 1.0.0.1 lub 8.8.8.8, 8.8.4.4, albo serwera DNS samej sieci VPN. PersistentKeepalive = 25 wysyła mały pakiet co 25 sekund i pomaga utrzymać połączenie otwarte, gdy klient znajduje się za NAT.

Kopiuj klucze i Endpoint bardzo starannie. Błędnie wpisany klucz lub nieprawidłowy Endpoint to najczęstsza przyczyna braku połączenia tunelu.

Dodawanie klienta do serwera

Otwórz ponownie konfigurację serwera i dodaj sekcję [Peer] dla klienta, używając klucza publicznego klienta z poprzedniego kroku.

[Peer]
PublicKey = # public key of the WireGuard client
AllowedIPs = # internal IP address of the client

W konfiguracji serwera AllowedIPs pełni dwie funkcje. Informuje serwer, który adres tunelu należy do tego klienta, i działa jako lista routingu: każdy pakiet zaadresowany do tych zakresów jest szyfrowany i wysyłany do tego peera. W przypadku pojedynczego klienta jest to jego adres tunelu, na przykład 10.0.0.2/32. Jeśli klient ma również udostępniać sieć lokalną przez tunel, dodaj tutaj także tę podsieć, na przykład 10.0.0.2/32, 192.168.1.0/24. Powtórz ten krok dla każdego kolejnego klienta.

Konfiguracja Zapory systemu Windows na serwerze

Serwer musi akceptować przychodzący ruch WireGuard na swoim porcie UDP. Otwórz Zapora Windows Defender z zabezpieczeniami zaawansowanymi, wybierz Reguły przychodzące i kliknij Nowa reguła. Wybierz Port i kliknij Dalej. Wybierz UDP, wprowadź port WireGuard, na przykład 51820, i kliknij Dalej. Jeśli używasz więcej niż jednego portu, wymień je oddzielone przecinkami, na przykład 51820, 51821. Wybierz Zezwalaj na połączenie i kliknij Dalej. Wybierz profile, których dotyczy reguła. Jeśli serwer jest hostowany w centrum danych, zwykle wystarcza profil Publiczny; w przeciwnym razie pozostaw zaznaczone profile Domena, Prywatny i Publiczny. Kliknij Dalej, nadaj regule czytelną nazwę, taką jak WireGuard UDP 51820, i kliknij Zakończ.

Ta reguła przychodząca jest potrzebna tylko na serwerze, ponieważ to serwer jest stroną odbierającą połączenia przychodzące. Na VPS-ie upewnij się również, że Twój dostawca hostingu zezwala na przychodzący ruch UDP na tym porcie na poziomie sieci, a nie tylko w Zaporze systemu Windows.

Eksportowanie i wdrażanie konfiguracji

Gdy obie konfiguracje są gotowe, kliknij Export all tunnels to zip, wybierz lokalizację i zapisz.

Otwórz archiwum, aby znaleźć pliki konfiguracyjne wszystkich tuneli. Umieść konfigurację serwera na serwerze i przekaż każdemu klientowi jego własny plik konfiguracyjny. Jeśli komputer zawiera wiele tuneli, możesz również wyeksportować pojedynczy tunel z jego menu kontekstowego. Eksport do pliku zip jest wygodny, gdy oba tunele zostały utworzone na tym samym komputerze, jak w tym przewodniku. Jeśli tworzysz każdą konfigurację bezpośrednio na jej własnym hoście, eksport nie jest konieczny i możesz skopiować plik konfiguracyjny ręcznie.

Na serwerze wybierz konfigurację serwera i kliknij Aktywuj.

Na kliencie kliknij Add Tunnel, wybierz plik konfiguracyjny klienta i otwórz go.

Następnie kliknij Aktywuj.

Pierwszy klient jest teraz skonfigurowany. Dodaj kolejnych klientów w ten sam sposób: utwórz nowy pusty tunel dla każdego klienta i dodaj do konfiguracji serwera odpowiednią sekcję [Peer] z kluczem publicznym i adresem tunelu tego klienta, jak opisano w sekcji „Dodawanie klienta do serwera".

Warning: Jeśli konfigurujesz WireGuard na zdalnym serwerze przez sesję RDP, przeczytaj sekcję „Zrozumienie AllowedIPs", zanim aktywujesz tunel kierujący cały ruch. Konfiguracja z AllowedIPs = 0.0.0.0/0 może przekierować własny ruch serwera do tunelu i zerwać połączenie RDP.

Weryfikacja połączenia

Po aktywacji tunelu system Windows może pokazywać kartę WireGuard jako „Brak dostępu do sieci" lub „Brak dostępu do Internetu" w Centrum sieci i udostępniania. Jest to oczekiwane zachowanie, ponieważ Windows nie traktuje kart tuneli VPN jako standardowych połączeń internetowych i nie wpływa to na tunel. Windows ustala ten status za pomocą swojego sprawdzania łączności, które odpytuje określone adresy URL firmy Microsoft, więc ostrzeżenie może pojawić się również wtedy, gdy te zapytania są zablokowane lub nie są rozwiązywane przez Twój DNS, nawet gdy tunel działa.

Aby potwierdzić, że tunel działa, sprawdź jego status w kliencie WireGuard. Aktywny tunel pokazuje status Aktywny wraz z licznikami transferu danych. Jeśli liczniki rosną, tunel przesyła ruch.

Na serwerze możesz również potwierdzić, że WireGuard nasłuchuje na swoim porcie UDP, gdy tunel jest aktywny:

netstat -ano | findstr 51820

W programie PowerShell odpowiednikiem jest:

Get-NetUDPEndpoint -LocalPort 51820

Zastąp 51820 swoim portem WireGuard. Jeśli nic nie zostanie zwrócone, tunel nie jest aktywny lub port różni się od ustawionego w konfiguracji serwera.

Następnie otwórz Wiersz polecenia i wykonaj ping na wewnętrzny adres tunelu serwera:

ping 10.0.0.1

Zastąp 10.0.0.1 rzeczywistym adresem wewnętrznym ustawionym dla serwera. Odpowiedzi potwierdzają, że tunel działa.

Jeśli klient używa AllowedIPs = 0.0.0.0/0, możesz również potwierdzić, że ruch jest kierowany przez tunel:

tracert 8.8.8.8

Pierwszy przeskok powinien być wewnętrznym adresem IP serwera WireGuard.

Sprawdzanie uzgadniania WireGuard

Uzgadnianie (handshake) to najbardziej przydatny wskaźnik przy diagnozowaniu połączenia WireGuard. W aplikacji WireGuard otwórz tunel i obserwuj pole Latest handshake. W działającym tunelu uzgadnianie pojawia się w ciągu kilku sekund od aktywacji, a następnie aktualizuje się okresowo podczas przesyłania danych. Jeśli tunel jest bezczynny, między uzgodnieniami może upłynąć trochę czasu, więc krótka przerwa jest normalna. Jeśli pole pozostaje puste, peery nie mogą się nawzajem osiągnąć, co zwykle wskazuje na nieprawidłowy Endpoint, zamknięty port UDP lub niezgodne klucze.

Uzgadnianie możesz również sprawdzić z wiersza poleceń za pomocą narzędzia wg dostarczanego z WireGuard:

wg show

Dane wyjściowe wymieniają każdego peera wraz z czasem jego ostatniego uzgadniania i licznikami transferu.

Zrozumienie AllowedIPs

Wartość AllowedIPs w konfiguracji klienta decyduje o tym, jaki ruch jest wysyłany przez tunel. W skrócie: na kliencie AllowedIPs ustala, które pakiety są wysyłane do tunelu, natomiast na serwerze ustala, które pakiety są akceptowane od danego klienta i dokąd są kierowane.

AllowedIPs = 0.0.0.0/0 kieruje cały ruch przez tunel, w tym zwykłe przeglądanie Internetu. Użyj tej wartości, gdy chcesz uzyskać pełną ochronę ruchu. Aby ten ruch dotarł do Internetu, serwer musi go translować. Zobacz „Konfiguracja NAT na serwerze dla pełnego tunelowania" poniżej.

AllowedIPs = 10.0.0.0/24 kieruje przez tunel tylko ruch sieci wewnętrznej, podczas gdy zwykły ruch internetowy nadal korzysta ze standardowego połączenia. Użyj tej wartości, gdy musisz osiągnąć tylko określone zasoby w sieci zdalnej.

Możesz wymienić kilka podsieci oddzielonych przecinkami, na przykład AllowedIPs = 10.0.0.0/24, 192.168.1.0/24.

Tip: Opcja Block untunneled traffic (kill-switch) w edytorze tunelu działa w pełni przy AllowedIPs = 0.0.0.0/0. Blokuje wszystko, co przechodziłoby poza tunel, co blokuje również sieć lokalną. Jeśli potrzebujesz dostępu do drukarek lub innych urządzeń w sieci LAN, pozostaw kill-switch wyłączony.

Warning: Ustawienie AllowedIPs = 0.0.0.0/0 wysyła każde połączenie przez tunel. Jeśli zastosujesz to na zdalnym serwerze zarządzanym przez RDP, sesja RDP może zostać zerwana w chwili aktywacji tunelu, ponieważ ruch serwera zostaje przekierowany. Na serwerze osiąganym przez RDP kieruj tylko potrzebne podsieci i testuj z wąską wartością AllowedIPs, zanim przełączysz się na 0.0.0.0/0.

Konfiguracja NAT na serwerze dla pełnego tunelowania

Jeśli klienci używają AllowedIPs = 0.0.0.0/0 i chcesz, aby ich ruch faktycznie docierał do Internetu przez serwer, serwer musi translować wewnętrzne adresy WireGuard na swój własny adres zewnętrzny. W systemie Windows robi się to za pomocą polecenia New-NetNat, a nie skryptów PostUp i PostDown używanych w systemie Linux.

Otwórz PowerShell jako administrator na serwerze i wykonaj poniższe polecenie, używając podsieci tunelu przypisanej do serwera:

New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24

Zastąp 10.0.0.0/24 swoją podsiecią tunelu i upewnij się, że prefiks obejmuje każdy przypisywany adres klienta. Klient spoza tego zakresu, na przykład 10.0.1.2, nie zostałby objęty tą regułą. Aktywne reguły możesz przejrzeć w dowolnym momencie:

Get-NetNat

Aby później usunąć regułę NAT, wykonaj:

Remove-NetNat -Name WireGuardNAT

Jeśli klienci łączą się i uzgadnianie kończy się powodzeniem, ale ich ruch internetowy nadal nie przechodzi przez serwer, włącz przekazywanie IP na interfejsach biorących udział w routingu i przetestuj ponownie. Dokładna forma zależy od wersji systemu Windows, na przykład:

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

Zastosuj je do interfejsu zewnętrznego przenoszącego ruch internetowy oraz do interfejsu WireGuard, używając ich rzeczywistych nazw uzyskanych z Get-NetIPInterface.

Info: New-NetNat wymaga systemu Windows 10, Windows 11 lub Windows Server 2016 i nowszych, a w niektórych systemach wymaga włączenia funkcji Hyper-V, nawet jeśli w innym celu nie używasz Hyper-V. W niektórych planach VPS nie można włączyć Hyper-V, co blokuje tę metodę. To, czy samo New-NetNat wystarczy, czy trzeba dodatkowo włączyć przekazywanie IP, może zależeć od wersji systemu Windows, więc potwierdź to na swoim serwerze, gdy pełne tunelowanie nie działa.

Rozwiązywanie problemów

Tunel jest aktywny, ale nie ma połączenia z serwerem. Sprawdź, czy port UDP WireGuard, na przykład 51820, jest otwarty w zaporze na serwerze. Potwierdź, że klucze publiczne zostały poprawnie skopiowane między konfiguracją serwera i klienta. Upewnij się, że Endpoint w konfiguracji klienta wskazuje na rzeczywisty publiczny adres IP serwera, a nie na wewnętrzny adres tunelu.

DNS nie działa po połączeniu. Dodaj serwer DNS do sekcji interface klienta:

[Interface]
PrivateKey = ...
Address = ...
DNS = 1.1.1.1, 1.0.0.1

Liczniki pakietów nie rosną. Tunel nie przesyła danych. Sprawdź, czy AllowedIPs jest poprawnie ustawione po obu stronach, czy wewnętrzne adresy WireGuard nie kolidują z istniejącą siecią lokalną oraz czy ListenPort nie jest już używany przez inną aplikację.

Potrzebujesz więcej szczegółów do zdiagnozowania problemu. Otwórz tunel w aplikacji WireGuard i zajrzyj na kartę Log, która rejestruje uzgodnienia, błędy i zdarzenia połączeń w miarę ich występowania. Stamtąd możesz wyeksportować dziennik, jeśli musisz go udostępnić.

Automatyczne uruchamianie WireGuard po ponownym uruchomieniu serwera

Aby tunel działał po ponownych uruchomieniach, zainstaluj go jako usługę systemu Windows. Gdy tunel jest zainstalowany jako usługa, uruchamia się automatycznie po ponownym uruchomieniu. Otwórz Wiersz polecenia lub PowerShell jako administrator i wykonaj poniższe polecenie, używając ścieżki do swojego pliku konfiguracyjnego serwera:

wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"

Po instalacji tunel pojawia się na liście Usług systemu Windows jako WireGuard Manager, ze statusem Uruchomiona i typem uruchamiania Automatyczny, co potwierdza, że uruchomi się samodzielnie po ponownym uruchomieniu.

Wykonaj to polecenie tylko raz, a nie przy każdym uruchomieniu. Aktywacja tunelu z aplikacji WireGuard zwykle instaluje tę samą usługę, więc w wielu przypadkach wystarczy aktywować go raz. Aby później usunąć usługę, użyj nazwy tunelu, która jest nazwą pliku konfiguracyjnego bez rozszerzenia .conf:

wireguard /uninstalltunnelservice wg_server

Aby ponownie uruchomić usługę, na przykład po edycji konfiguracji, wykonaj polecenie deinstalacji, a następnie ponownie polecenie instalacji.

Info: Ponieważ tunel działa jako usługa, osobne zadanie w Harmonogramie zadań nie jest potrzebne.

Uruchom ponownie serwer i potwierdź, że tunel uruchamia się samodzielnie.