Konfiguracja programu WireGuard w systemie Windows
Ten poradnik 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 z systemem Windows, oraz klientem WireGuard działającym na lokalnym komputerze z systemem Windows. Po uruchomieniu tunelu oba komputery wymieniają dane przez szyfrowane połączenie prywatne, a opcjonalnie można kierować cały ruch klienta przez serwer.
Podstawowa konfiguracja tworzy tunel między serwerem a klientem. Skierowanie całego ruchu internetowego klienta przez serwer wymaga również NAT na serwerze, patrz „Konfiguracja NAT na serwerze dla pełnego tunelowania”.
Aby uprościć generowanie kluczy, w tym poradniku zarówno konfiguracja serwera, jak i klienta są tworzone w jednej aplikacji WireGuard, a następnie każdy plik konfiguracyjny jest przenoszony na komputer, do którego należy. Konfiguracja serwera działa na serwerze, a konfiguracja klienta na kliencie. Serwer i klient to zawsze osobne komputery. Tej samej procedury używa się do dodania dowolnej liczby kolejnych klientów.
Przed rozpoczęciem zainstaluj najnowszą wersję WireGuard ze strony instalacji WireGuard zarówno na serwerze, jak i na kliencie oraz upewnij się, że masz uprawnienia administratora na każdym z komputerów.
Konfiguracja opisana w tym poradniku wygląda następująco:
Serwer (publiczny adres IP, nasłuchuje na UDP 51820) Adres tunelu 10.0.0.1/24 | | szyfrowany tunel WireGuard | Klient Adres tunelu 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świetlony u góry okna jest kluczem publicznym serwera. Będzie potrzebny później przy konfiguracji klienta.
Nadaj tunelowi nazwę i uzupełnij sekcję Interface: kluczem prywatnym serwera, portem, na którym będzie nasłuchiwać WireGuard, oraz adresem wewnętrznym, którego serwer będzie używać wewnątrz tunelu.
[Interface] PrivateKey = # klucz prywatny serwera WireGuard ListenPort = # port, na którym będzie nasłuchiwać WireGuard Address = # wewnętrzny adres IP serwera WireGuard, na przykład 10.0.0.1/24
Dla sieci tunelu użyj prywatnej podsieci i utrzymuj serwer oraz wszystkich klientów w tym samym zakresie. Typowym wyborem jest 10.0.0.1/24 dla serwera oraz 10.0.0.2/32, 10.0.0.3/32 itd. dla kolejnych klientów. Serwer używa prefiksu /24, aby traktować 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 skonfigurowany z /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.
Konfiguracja serwera nie wyświetla pola wyboru Block untunneled traffic (kill-switch). Ta opcja pojawia się wyłącznie w konfiguracji klienta, która kieruje cały ruch przez tunel, patrz „Tworzenie konfiguracji klienta”.
Dla dodatkowej warstwy zabezpieczeń możesz dodać klucz wstępnie współdzielony (pre-shared key) do każdego peera. Wygeneruj go raz i dodaj tę samą linię do odpowiedniej sekcji [Peer] zarówno na serwerze, jak i na kliencie:
PresharedKey = # klucz wstępnie współdzielony, identyczny na serwerze i na kliencie
Klucz możesz wygenerować narzędziem wg dostarczanym z WireGuard:
"C:\Program Files\WireGuard\wg.exe" genpsk
Tworzenie konfiguracji klienta
Kliknij Add tunnel i po raz drugi wybierz Add empty tunnel, tym razem dla klienta. Klucz publiczny wyświetlony dla tego tunelu jest kluczem publicznym klienta, którego serwer potrzebuje, aby zaakceptować klienta.
Uzupełnij konfigurację klienta:
[Interface] PrivateKey = # klucz prywatny klienta WireGuard Address = # wewnętrzny adres IP klienta WireGuard, na przykład 10.0.0.2/32 DNS = 1.1.1.1, 1.0.0.1 [Peer] PublicKey = # klucz publiczny serwera WireGuard AllowedIPs = # 0.0.0.0/0 dla pełnego tunelu lub 10.0.0.0/24 dla tunelu dzielonego (split tunnel) Endpoint = # publiczny adres IP i port serwera WireGuard PersistentKeepalive = 25
Parametr Endpoint musi zawierać rzeczywisty publiczny adres IP serwera wraz z portem ustawionym w ListenPort serwera, a nie wewnętrzny adres tunelu. Wskazówki dotyczące wyboru wartości AllowedIPs znajdziesz w sekcji „Jak działa AllowedIPs” poniżej.
Linie DNS i PersistentKeepalive są opcjonalne. DNS ustawia serwery DNS używane przy aktywnym tunelu, co pomaga uniknąć problemów 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, gdy klient znajduje się za NAT.
Gdy konfiguracja klienta zawiera jedną sekcję [Peer], a jej AllowedIPs zawiera 0.0.0.0/0 (lub ::/0), edytor tunelu wyświetla pod polem konfiguracji pole wyboru Block untunneled traffic (kill-switch). W przypadku tunelu dzielonego, na przykład AllowedIPs = 10.0.0.0/24, pole wyboru w ogóle się nie pojawia.
Kill-switch jest domyślnie włączony, gdy tylko wpiszesz 0.0.0.0/0. Gdy tunel jest aktywny, reguły zapory zezwalają wyłącznie na ruch przechodzący przez tunel, ruch loopback, DHCP oraz wykrywanie sąsiadów IPv6 (neighbor discovery). Wszystko inne jest blokowane, w tym urządzenia w sieci lokalnej, takie jak drukarki i NAS. Jeśli ustawiono linię DNS, zapytania DNS są dozwolone tylko do wymienionych tam serwerów.
Wyczyszczenie pola wyboru nie jest zwykłym wyłączeniem ustawienia. Edytor przepisuje AllowedIPs: 0.0.0.0/0 zmienia się w 0.0.0.0/1, 128.0.0.0/1, a ::/0 w ::/1, 8000::/1. Cały ruch internetowy nadal przechodzi przez tunel, ale blokujące reguły zapory nie są tworzone. Ponowne zaznaczenie pola przywraca 0.0.0.0/0.
Kopiuj klucze i Endpoint bardzo uważnie. Błędnie wpisany klucz lub niewłaściwy Endpoint to najczęstsza przyczyna braku połączenia tunelu.
Dodawanie klienta do serwera
Ponownie otwórz konfigurację serwera i dodaj sekcję [Peer] dla klienta, używając klucza publicznego klienta z poprzedniego kroku.
[Peer] PublicKey = # klucz publiczny klienta WireGuard AllowedIPs = # wewnętrzny adres IP klienta
W konfiguracji serwera AllowedIPs pełni dwie role. Informuje serwer, który adres tunelu należy do danego klienta, oraz działa jak lista routingu: każdy pakiet adresowany do tych zakresów jest szyfrowany i wysyłany do tego peera. Dla pojedynczego klienta jest to jego adres tunelu, na przykład 10.0.0.2/32. Jeśli klient ma również udostępniać przez tunel sieć lokalną, 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 Zaporę Windows Defender z zabezpieczeniami zaawansowanymi, wybierz Reguły ruchu przychodzącego i kliknij Nowa reguła. Wybierz Port i kliknij Dalej. Wybierz UDP, wpisz 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, do których ma się stosować reguła. Jeśli serwer jest hostowany w centrum danych, zwykle wystarczy profil Publiczny, w przeciwnym razie pozostaw zaznaczone profile Domena, Prywatny i Publiczny. Kliknij Dalej, nadaj regule czytelną nazwę, na przykład WireGuard UDP 51820, i kliknij Zakończ.
Ta reguła ruchu przychodzącego jest potrzebna tylko na serwerze, ponieważ to serwer przyjmuje połączenia przychodzące. Na VPS upewnij się również, że 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, a każdemu klientowi przekaż jego własny plik konfiguracyjny. Jeśli na komputerze znajduje się wiele tuneli, możesz też 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 poradniku. Jeśli każdą konfigurację tworzysz bezpośrednio na jej własnym hoście, eksport nie jest wymagany i możesz skopiować plik konfiguracyjny ręcznie.
Na serwerze wybierz konfigurację serwera i kliknij Activate.
Na kliencie kliknij Add Tunnel, wybierz plik konfiguracyjny klienta i otwórz go.
Następnie kliknij Activate.
Pierwszy klient jest już skonfigurowany. Kolejnych klientów dodajesz 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, zgodnie z opisem w sekcji „Dodawanie klienta do serwera”.
Jeśli konfigurujesz WireGuard na zdalnym serwerze przez sesję RDP, przeczytaj sekcję „Jak działa AllowedIPs” przed aktywowaniem tunelu kierującego cały ruch. Konfiguracja z AllowedIPs = 0.0.0.0/0 może przekierować własny ruch serwera do tunelu i przerwać połączenie RDP.
Weryfikacja połączenia
Po aktywowaniu tunelu system Windows może pokazać adapter WireGuard jako „Brak dostępu do sieci” lub „Brak dostępu do Internetu” w Centrum sieci i udostępniania. Jest to zachowanie oczekiwane, ponieważ Windows nie traktuje adapterów tuneli VPN jako standardowych połączeń internetowych, i nie wpływa ono na działanie tunelu. Windows ustala ten status za pomocą testu łączności, który odpytuje określone adresy URL Microsoftu, więc ostrzeżenie może pojawić się również wtedy, gdy te zapytania są blokowane lub nie są rozwiązywane przez Twój DNS, nawet jeśli tunel działa.
Aby potwierdzić, że tunel działa, sprawdź jego status w kliencie WireGuard. Aktywny tunel pokazuje status Active wraz z licznikami przesyłanych danych. Jeśli liczniki rosną, tunel przekazuje ruch.
Na serwerze możesz też sprawdzić, czy WireGuard nasłuchuje na swoim porcie UDP, gdy tunel jest aktywny:
netstat -ano | findstr 51820
W PowerShellu 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 wewnętrznym adresem IP ustawionym dla serwera. Jeśli serwer odpowiada, ruch przechodzi przez tunel. Jeśli brak odpowiedzi, najpierw sprawdź handshake: Zapora systemu Windows w Windows Server domyślnie blokuje przychodzące pingi, więc brak odpowiedzi nie zawsze oznacza, że tunel nie działa.
Jeśli klient używa AllowedIPs = 0.0.0.0/0, możesz też potwierdzić, że ruch jest kierowany przez tunel:
tracert 8.8.8.8
Pierwszym przeskokiem powinien być wewnętrzny adres IP serwera WireGuard.
Sprawdzanie handshake WireGuard
Handshake jest najbardziej przydatnym wskaźnikiem przy diagnozowaniu połączenia WireGuard. W aplikacji WireGuard otwórz tunel i obserwuj pole Latest handshake. W działającym tunelu handshake pojawia się w ciągu kilku sekund od aktywacji, a następnie jest okresowo aktualizowany podczas przesyłania danych. Jeśli tunel jest bezczynny, między kolejnymi handshake’ami może upłynąć trochę czasu, więc krótka przerwa jest normalna. Jeśli pole pozostaje puste, peery nie mogą się ze sobą skontaktować, co zwykle wskazuje na błędny Endpoint, zamknięty port UDP lub niezgodne klucze.
Handshake można też sprawdzić z wiersza polecenia za pomocą narzędzia wg dostarczanego z WireGuard:
wg show
Wynik zawiera listę peerów wraz z czasem ostatniego handshake i licznikami transferu.
Jak działa AllowedIPs
Wartość AllowedIPs w konfiguracji klienta określa, jaki ruch jest wysyłany przez tunel. Krótko mówiąc, na kliencie AllowedIPs określa, które pakiety są wysyłane do tunelu, a na serwerze – które pakiety są akceptowane od danego klienta i dokąd są kierowane.
Wartość 0.0.0.0/0 kieruje przez tunel cały ruch, w tym zwykłe przeglądanie internetu. Użyj jej, gdy chcesz zapewnić pełną ochronę ruchu. Aby ten ruch dotarł do internetu, serwer musi go translować. Patrz „Konfiguracja NAT na serwerze dla pełnego tunelowania” poniżej.
Wartość taka jak 10.0.0.0/24 kieruje przez tunel tylko ruch sieci wewnętrznej, podczas gdy zwykły ruch internetowy nadal korzysta z normalnego połączenia. Użyj jej, gdy potrzebujesz dostępu wyłącznie do określonych zasobów w sieci zdalnej.
Możesz podać kilka podsieci oddzielonych przecinkami, na przykład 10.0.0.0/24, 192.168.1.0/24.
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 tunelem, co obejmuje również sieć lokalną. Jeśli potrzebujesz dostępu do drukarek lub innych urządzeń w sieci LAN, pozostaw kill-switch wyłączony.
Ustawienie AllowedIPs = 0.0.0.0/0 kieruje każde połączenie przez tunel. Jeśli zastosujesz je na zdalnym serwerze zarządzanym przez RDP, sesja RDP może zostać przerwana w momencie aktywacji tunelu, ponieważ ruch serwera zostaje przekierowany. Na serwerze, do którego łączysz się przez RDP, kieruj tylko potrzebne podsieci i przetestuj wąską wartość AllowedIPs, zanim przejdziesz na 0.0.0.0/0.
Dostęp do sieci lokalnej przy aktywnym tunelu
W przypadku tunelu dzielonego, na przykład AllowedIPs = 10.0.0.0/24, sieć lokalna działa jak zwykle i nie trzeba nic zmieniać. Poniższe kroki dotyczą pełnego tunelu.
Najprostszą opcją jest wyczyszczenie pola wyboru Block untunneled traffic (kill-switch) w edytorze tunelu klienta. Edytor zastępuje 0.0.0.0/0 wartością 0.0.0.0/1, 128.0.0.0/1. Twoja podsieć lokalna, na przykład 192.168.1.0/24, ma bardziej szczegółową trasę przez adapter fizyczny, więc Windows wysyła ruch LAN bezpośrednio do sieci lokalnej, a ruch internetowy nadal przechodzi przez tunel. Wadą jest to, że nic nie blokuje ruchu, jeśli tunel przestanie działać.
Jeśli chcesz mieć pewność, że ruch LAN nigdy nie trafi do tunelu, jawnie wyłącz zakres lokalny z AllowedIPs. Na przykład poniższa wartość obejmuje każdy adres IPv4 z wyjątkiem 192.168.0.0/16:
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3
Jeśli Twoja sieć lokalna używa innego zakresu, na przykład 10.x.x.x lub 172.16.x.x, oblicz listę dla tego zakresu za pomocą kalkulatora AllowedIPs i upewnij się, że podsieć tunelu nadal jest uwzględniona. Ponieważ ta wartość nie zawiera trasy /0, kill-switch nie jest z nią dostępny.
Info Unikaj używania tej samej podsieci dla tunelu i sieci lokalnej. Jeśli Twoja sieć domowa to 10.0.0.0/24, wybierz inny zakres tunelu, na przykład 10.8.0.0/24.
Aby uzyskać dostęp do sieci znajdującej się za serwerem, na przykład biurowej sieci LAN 192.168.10.0/24, serwer nie wymaga dodatkowego wpisu, ponieważ ma już trasę do własnej sieci LAN. Na kliencie dodaj ją do AllowedIPs w sekcji [Peer], na przykład AllowedIPs = 10.0.0.0/24, 192.168.10.0/24. Serwer musi również przekazywać i translować ten ruch, patrz „Konfiguracja NAT na serwerze dla pełnego tunelowania”. Urządzenia w tej sieci LAN odpowiadają na adres LAN serwera, więc NAT na serwerze jest najprostszym sposobem, aby odpowiedzi wracały przez tunel.
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 uruchom 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 własną podsiecią tunelu i upewnij się, że prefiks obejmuje wszystkie przypisywane adresy klientów. Klient spoza tego zakresu, na przykład 10.0.1.2, nie zostałby dopasowany do tej reguły. Aktywne reguły możesz sprawdzić w dowolnym momencie:
Get-NetNat
Aby później usunąć regułę NAT, uruchom:
Remove-NetNat -Name WireGuardNAT
Jeśli klienci łączą się i handshake kończy się powodzeniem, ale ich ruch internetowy nadal nie przechodzi przez serwer, włącz przekazywanie IP (IP forwarding) na interfejsach biorących udział w routingu i przetestuj ponownie. Dokładna postać polecenia zależy od wersji Windows, na przykład:
Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled
Zastosuj je do interfejsu zewnętrznego, przez który przechodzi ruch internetowy, oraz do interfejsu WireGuard, używając ich rzeczywistych nazw z polecenia Get-NetIPInterface.
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 poza tym nie korzystasz z Hyper-V. W niektórych planach VPS nie można włączyć Hyper-V, co uniemożliwia użycie tej metody. To, czy samo New-NetNat wystarcza, czy trzeba również włączyć przekazywanie IP, może zależeć od wersji Windows, dlatego sprawdź 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. Upewnij się, że klucze publiczne zostały poprawnie skopiowane między konfiguracjami serwera i klienta. Upewnij się, że Endpoint w konfiguracji klienta wskazuje rzeczywisty publiczny adres IP serwera, a nie 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 przekazuje 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ę.
Nie można wyczyścić pola wyboru kill-switch. Edytor przepisuje AllowedIPs tylko wtedy, gdy potrafi odczytać całą konfigurację. Sprawdź, czy sekcja [Peer] zawiera prawidłowy klucz publiczny skopiowany z serwera oraz czy każde ustawienie znajduje się w osobnej linii, a następnie spróbuj ponownie.
Potrzebujesz więcej szczegółów, aby zdiagnozować problem. Otwórz tunel w aplikacji WireGuard i przejdź do karty Log, która na bieżąco rejestruje handshake’i, błędy i zdarzenia połączenia. Stamtąd możesz wyeksportować dziennik, jeśli musisz go komuś udostępnić.
Automatyczne uruchamianie WireGuard po ponownym uruchomieniu serwera
Aby tunel działał po ponownych uruchomieniach, zainstaluj go jako usługę systemu Windows. Tunel zainstalowany jako usługa uruchamia się automatycznie po restarcie. Otwórz Wiersz polecenia lub PowerShell jako administrator i uruchom poniższe polecenie, używając ścieżki do pliku konfiguracyjnego serwera:
wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"
Uruchom to polecenie tylko raz, a nie przy każdym starcie. Aktywowanie tunelu z poziomu aplikacji WireGuard zwykle instaluje tę samą usługę, więc w wielu przypadkach wystarczy jednorazowa aktywacja. Aby później usunąć usługę, użyj nazwy tunelu, czyli nazwy pliku konfiguracyjnego bez rozszerzenia .conf.
wireguard /uninstalltunnelservice wg_server
Aby ponownie uruchomić usługę, na przykład po edycji konfiguracji, uruchom polecenie odinstalowania, a następnie ponownie polecenie instalacji.
Ponieważ tunel działa jako usługa, osobne zadanie w Harmonogramie zadań nie jest potrzebne.
Uruchom serwer ponownie i sprawdź, czy tunel startuje samoczynnie.
