Konfiguracja programu WireGuard w systemie Windows
W niniejszym przewodniku wyjaśniono, jak skonfigurować tunel VPN WireGuard między dwoma komputerami z systemem Windows: serwerem WireGuard działającym na zdalnym hoście z systemem Windows (na przykład na serwerze VPS z systemem Windows) oraz klientem WireGuard działającym na lokalnym komputerze z systemem Windows. Gdy tunel jest aktywny, oba komputery wymieniają dane za pośrednictwem zaszyfrowanego, prywatnego połączenia, a użytkownik może opcjonalnie przekierować cały ruch klienta przez serwer.
Aby uprościć generowanie kluczy, w niniejszym przewodniku konfiguracje zarówno serwera, jak i klienta są tworzone w ramach jednej aplikacji WireGuard, a następnie każdy plik konfiguracyjny jest wdrażany na komputerze, do którego należy. Konfiguracja serwera działa na serwerze, a konfiguracja klienta – na kliencie. Serwer i klient to zawsze oddzielne komputery. Ten sam proces służy do dodawania dowolnej liczby dodatkowych klientów.
Przed rozpoczęciem należy zainstalować najnowszą wersję WireGuard ze strony instalacyjnej WireGuard zarówno na serwerze, jak i na kliencie, oraz upewnić się, że posiada się uprawnienia administratora na każdym z tych komputerów.
Konfiguracja opisana 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 plik C:\Program Files\WireGuard\wireguard.exe, kliknij opcję Dodaj tunel, a następnie wybierz opcję Dodaj pusty tunel. WireGuard automatycznie wygeneruje parę kluczy. Klucz publiczny wyświetlany w górnej części okna to klucz publiczny serwera. Będzie on potrzebny później podczas konfiguracji klienta.
Nadaj tunelowi nazwę i w sekcji „Interfejs” wprowadź klucz prywatny serwera, port, na którym WireGuard będzie nasłuchiwał, oraz adres wewnętrzny, z którego serwer będzie korzystał 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 adresów. Często wybierane są adresy 10.0.0.1/24 dla serwera oraz 10.0.0.2/32, 10.0.0.3/32 itd. dla każdego klienta. Serwer używa prefiksu /24, więc traktuje cały zakres tunelu jako dostępny przez interfejs WireGuard. Każdy klient używa prefiksu /32, ponieważ klient reprezentuje pojedynczy adres, a nie podsieć. Klient z ustawieniem /24 zakładałby, że cały zakres znajduje się na jego własnym interfejsie i nie wysyłałby ruchu do innych adresów w tunelu przez sam tunel.
W edytorze tunelu, poniżej pola konfiguracji, można opcjonalnie włączyć opcję „Blokuj ruch poza tunelem (kill-switch)”, która blokuje wszelki ruch wychodzący poza tunel, oraz ustawić „Klucz wstępny”, który zapewnia dodatkową warstwę bezpieczeństwa. Obie opcje są opcjonalne. Zobacz sekcję „Omówienie AllowedIPs”, aby dowiedzieć się, kiedy funkcja kill-switch jest przydatna i co blokuje.
Tworzenie konfiguracji klienta
Kliknij „Dodaj tunel” i po raz drugi wybierz „Dodaj pusty tunel”, tym razem dla klienta. Klucz publiczny wyświetlany dla tego tunelu to klucz publiczny klienta, którego serwer potrzebuje, aby zaakceptować klienta.
Wprowadź 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
Pole „Endpoint” musi zawierać rzeczywisty publiczny adres IP serwera wraz z portem ustawionym w polu „ListenPort” serwera, a nie wewnętrzny adres tunelu. Aby uzyskać pomoc w wyborze wartości „AllowedIPs”, zapoznaj się z sekcją „Opis AllowedIPs” poniżej.
Wiersze „DNS ” i „PersistentKeepalive” są opcjonalne. Pole „DNS” określa serwery DNS używane podczas działania tunelu, co zapobiega problemom z rozpoznawaniem nazw po nawiązaniu połączenia. Można używać publicznych serwerów rozpoznających nazwy, 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ć otwarte połączenie, gdy klient znajduje się za NAT.
Klucze i adres punktu końcowego należy skopiować bardzo dokładnie. Błędnie wpisany klucz lub nieprawidłowy adres punktu końcowego to najczęstsza przyczyna niepowodzenia połączenia tunelowego.
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 parametr AllowedIPs pełni dwie funkcje. Informuje serwer, który adres tunelu należy do tego klienta, oraz działa jako lista routingu: każdy pakiet adresowany do tych zakresów jest szyfrowany i wysyłany do tego partnera. 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 również tę podsieć, na przykład 10.0.0.2/32, 192.168.1.0/24. Powtórz ten krok dla każdego dodatkowego klienta.
Konfiguracja zapory systemu Windows na serwerze
Serwer musi akceptować przychodzący ruch WireGuard na swoim porcie UDP. Otwórz Zaporę systemu Windows Defender z zaawansowanymi zabezpieczeniami, wybierz opcję „Reguły przychodzące” i kliknij „Nowa reguła”. Wybierz opcję „Port” i kliknij „Dalej”. Wybierz protokół UDP, wprowadź numer portu WireGuard, na przykład 51820, a następnie kliknij „Dalej”. Jeśli korzystasz z więcej niż jednego portu, podaj je, oddzielając przecinkami, na przykład 51820, 51821. Wybierz opcję Zezwól na połączenie i kliknij Dalej. Wybierz profile, do których ma zastosowanie ta reguła. Jeśli serwer jest hostowany w centrum danych, zazwyczaj wystarczy profil Publiczny; w przeciwnym razie pozostaw zaznaczone profile Domenowy, Prywatny i Publiczny. Kliknij Dalej, nadaj regule jasną nazwę, np. WireGuard UDP 51820, a następnie kliknij Zakończ.
Ta reguła ruchu przychodzącego jest potrzebna tylko na serwerze, ponieważ to serwer jest stroną odbierającą połączenia przychodzące. W przypadku serwera VPS upewnij się również, że dostawca usług hostingowych zezwala na ruch przychodzący UDP na tym porcie na poziomie sieci, a nie tylko w zaporze systemu Windows.
Eksportowanie i wdrażanie konfiguracji
Gdy obie konfiguracje będą gotowe, kliknij opcję „Eksportuj wszystkie tunele do pliku ZIP”, wybierz lokalizację i zapisz.
Otwórz archiwum, aby znaleźć pliki konfiguracyjne wszystkich tuneli. Umieść konfigurację serwera na serwerze i przypisz każdemu klientowi jego własny plik konfiguracyjny. Jeśli na komputerze znajduje się wiele tuneli, możesz również wyeksportować pojedynczy tunel z jego menu kontekstowego. Eksportowanie do pliku ZIP jest wygodne, gdy oba tunele zostały utworzone na tym samym komputerze, tak jak w tym przewodniku. Jeśli każda konfiguracja jest tworzona bezpośrednio na własnym hoście, eksportowanie nie jest wymagane i plik konfiguracyjny można skopiować ręcznie.
Na serwerze wybierz konfigurację serwera i kliknij przycisk Aktywuj.
Na kliencie kliknij „Dodaj tunel”, wybierz plik konfiguracyjny klienta i otwórz go.
Następnie kliknij „Aktywuj”.
Pierwszy klient został skonfigurowany. Dodaj kolejnych klientów w ten sam sposób: utwórz nowy pusty tunel dla każdego klienta, a następnie dodaj do konfiguracji serwera odpowiednią sekcję [Peer] zawierającą klucz publiczny tego klienta oraz adres tunelu, zgodnie z opisem w sekcji „Dodawanie klienta do serwera”.
Jeśli konfigurujesz WireGuard na zdalnym serwerze za pośrednictwem sesji RDP, przed aktywacją tunelu, który przekierowuje cały ruch, zapoznaj się z sekcją „Zrozumienie AllowedIPs”. Konfiguracja z AllowedIPs = 0.0.0.0/0 może przekierować ruch własny serwera do tunelu i spowodować zerwanie połączenia RDP.
Sprawdzanie połączenia
Po aktywacji tunelu system Windows może wyświetlać 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ż system Windows nie traktuje kart tuneli VPN jako standardowych połączeń internetowych i nie ma to wpływu na działanie tunelu. System Windows określa ten status na podstawie testu łączności, który sprawdza określone adresy URL firmy Microsoft, więc ostrzeżenie może pojawić się również wtedy, gdy te testy są blokowane lub nie są rozpoznawane przez serwer DNS, nawet jeśli tunel działa.
Aby upewnić się, że tunel działa, sprawdź jego status w kliencie WireGuard. Aktywny tunel wyświetla status „Aktywny” wraz z licznikami transferu danych. Jeśli liczniki rosną, tunel przepuszcza ruch.
Na serwerze można również sprawdzić, czy WireGuard nasłuchuje na swoim porcie UDP, gdy tunel jest aktywny:
netstat -ano | findstr 51820
W PowerShellu odpowiednikiem tego polecenia jest:
Get-NetUDPEndpoint -LocalPort 51820
Zastąp 51820 swoim portem WireGuard. Jeśli nie zostanie zwrócony żaden wynik, tunel nie jest aktywny lub port różni się od tego ustawionego w konfiguracji serwera.
Następnie otwórz wiersz polecenia i wyślij polecenie ping do wewnętrznego adresu tunelu serwera:
ping 10.0.0.1
Zastąp 10.0.0.1 rzeczywistym wewnętrznym adresem IP, który ustawiłeś dla serwera. Odpowiedzi potwierdzają, że tunel działa.
Jeśli klient używa AllowedIPs = 0.0.0.0/0, możesz również sprawdzić, czy ruch jest kierowany przez tunel:
tracert 8.8.8.8
Pierwszym przeskokiem powinien być wewnętrzny adres IP serwera WireGuard.
Sprawdzanie uzgodnienia WireGuard
Uścisk dłoni jest najbardziej przydatnym wskaźnikiem podczas diagnozowania połączenia WireGuard. W aplikacji WireGuard otwórz tunel i obserwuj pole „Najnowszy uścisk dłoni ”. W przypadku działającego tunelu uścisk dłoni pojawia się w ciągu kilku sekund od aktywacji, a następnie jest okresowo aktualizowany podczas przesyłania danych. Jeśli tunel jest w stanie bezczynności, między kolejnymi uzgodnieniami może upłynąć trochę czasu, więc krótka przerwa jest normalna. Jeśli pole pozostaje puste, węzły nie mogą się ze sobą połączyć, co zazwyczaj wskazuje na nieprawidłowy punkt końcowy, zamknięty port UDP lub niezgodne klucze.
Można również sprawdzić uzgodnienie z poziomu wiersza poleceń za pomocą narzędzia wg dostarczanego wraz z WireGuard:
wg show
Wynik wyświetla listę wszystkich węzłów wraz z czasem ostatniego uzgodnienia oraz licznikami transferu.
Zrozumienie AllowedIPs
Wartość AllowedIPs w konfiguracji klienta decyduje o tym, jaki ruch jest przesyłany przez tunel. Krótko mówiąc, po stronie klienta AllowedIPs określa, które pakiety są wysyłane do tunelu, natomiast po stronie serwera określa, które pakiety są akceptowane od danego klienta i dokąd są one kierowane.
Wartość 0.0.0.0/0 kieruje cały ruch przez tunel, w tym zwykłe przeglądanie Internetu. Należy jej używać, gdy wymagana jest pełna ochrona ruchu. Aby ten ruch dotarł do Internetu, serwer musi go przetłumaczyć. Zobacz sekcję „Konfiguracja NAT na serwerze w celu pełnego tunelowania” poniżej.
Wartość taka jak 10.0.0.0/24 kieruje przez tunel wyłącznie ruch sieci wewnętrznej, podczas gdy zwykły ruch internetowy nadal korzysta z normalnego połączenia. Należy jej używać, gdy potrzebny jest dostęp wyłącznie do określonych zasobów w sieci zdalnej.
Można podać kilka podsieci oddzielonych przecinkami, na przykład 10.0.0.0/24, 192.168.1.0/24.
Opcja „Blokuj ruch nieprzekazywany przez tunel (kill-switch) ” w edytorze tunelu działa w pełni przy ustawieniu AllowedIPs = 0.0.0.0/0. Blokuje ona wszystko, co miałoby trafić poza tunel, co powoduje również zablokowanie sieci lokalnej. Jeśli potrzebujesz dostępu do drukarek lub innych urządzeń w sieci LAN, pozostaw opcję kill-switch wyłączoną.
Ustawienie AllowedIPs = 0.0.0.0/0 powoduje, że każde połączenie jest kierowane przez tunel. Jeśli zastosujesz to ustawienie na zdalnym serwerze, którym zarządzasz za pośrednictwem RDP, sesja RDP może się rozłączyć w momencie aktywacji tunelu, ponieważ ruch serwera jest przekierowywany. Na serwerze dostępnym przez RDP należy przekierowywać tylko te podsieci, które są potrzebne, i przetestować ustawienie z wąską wartością AllowedIPs przed przełączeniem na 0.0.0.0/0.
Konfiguracja NAT na serwerze w celu pełnego tunelowania
Jeśli klienci używają ustawienia AllowedIPs = 0.0.0.0/0, a chcesz, aby ich ruch faktycznie docierał do Internetu przez serwer, serwer musi przekształcić wewnętrzne adresy WireGuard na swój własny adres zewnętrzny. W systemie Windows odbywa się to za pomocą polecenia New-NetNat, a nie za pomocą skryptów PostUp i PostDown używanych w systemie Linux.
Otwórz PowerShell jako administrator na serwerze i uruchom następujące 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 przypisany adres klienta. Klient spoza tego zakresu, na przykład 10.0.1.2, nie zostanie objęty tą regułą. W dowolnym momencie możesz przejrzeć aktywne reguły:
Get-NetNat
Aby później usunąć regułę NAT, uruchom:
Remove-NetNat -Name WireGuardNAT
Jeśli klienci łączą się, a nawiązanie połączenia przebiega pomyślnie, ale ich ruch internetowy nadal nie przechodzi przez serwer, włącz przekazywanie adresów IP na interfejsach zaangażowanych w routing i przeprowadź ponowny test. Dokładna forma polecenia zależy od wersji systemu Windows, na przykład:
Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled
Zastosuj ją do interfejsu zewnętrznego, który obsługuje ruch internetowy, oraz do interfejsu WireGuard, używając ich rzeczywistych nazw z polecenia Get-NetIPInterface.
Polecenie New-NetNat wymaga systemu Windows 10, Windows 11 lub Windows Server 2016 i nowszych, a na niektórych systemach wymaga włączenia funkcji Hyper-V, nawet jeśli w innym celu nie korzystasz z Hyper-V. W niektórych planach VPS nie można włączyć funkcji Hyper-V, co uniemożliwia zastosowanie tej metody. To, czy samo polecenie New-NetNat wystarczy, czy też konieczne jest dodatkowo włączenie przekierowania adresów IP, może zależeć od wersji systemu Windows, dlatego należy to sprawdzić na 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 sieciowej na serwerze. Upewnij się, że klucze publiczne zostały poprawnie skopiowane między konfiguracjami serwera i klienta. Upewnij się, że punkt końcowy (Endpoint) w konfiguracji klienta wskazuje rzeczywisty publiczny adres IP serwera, a nie wewnętrzny adres tunelu.
DNS nie działa po nawiązaniu połączenia. Dodaj serwer DNS w sekcji interfejsu 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 lista AllowedIPs jest poprawnie skonfigurowana po obu stronach, czy wewnętrzne adresy WireGuard nie kolidują z istniejącą siecią lokalną oraz czy port ListenPort nie jest już używany przez inną aplikację.
Potrzebujesz więcej szczegółów, aby zdiagnozować problem. Otwórz tunel w aplikacji WireGuard i przejrzyj zakładkę „Log”, która rejestruje uzgodnienia, błędy i zdarzenia związane z połączeniem w miarę ich występowania. Jeśli chcesz udostępnić ten dziennik, możesz go stamtąd wyeksportować.
Automatyczne uruchamianie WireGuard po ponownym uruchomieniu serwera
Aby tunel działał nawet po ponownym uruchomieniu systemu, zainstaluj go jako usługę systemu Windows. Gdy tunel jest zainstalowany jako usługa, uruchamia się automatycznie po ponownym uruchomieniu systemu. Otwórz wiersz polecenia lub PowerShell jako administrator i uruchom następujące polecenie, podając ścieżkę do pliku konfiguracyjnego serwera:
wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"
Polecenie to należy uruchomić tylko raz, a nie przy każdym uruchomieniu systemu. Aktywacja tunelu z poziomu aplikacji WireGuard zazwyczaj powoduje zainstalowanie tej samej usługi, więc w wielu przypadkach wystarczy ją aktywować tylko raz. Aby później usunąć usługę, należy użyć 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, należy najpierw wykonać polecenie odinstalowania, a następnie ponownie polecenie instalacji.
Ponieważ tunel działa jako usługa, nie jest potrzebne oddzielne zadanie w Harmonogramie zadań.
Uruchom ponownie serwer i sprawdź, czy tunel uruchamia się samoczynnie.
