Samodzielnie hostowany WireGuard VPN daje laptopowi i telefonowi zaszyfrowaną ścieżkę do serwera, który kontrolujesz. Przydaje się, gdy chcesz mieć stabilny wychodzący adres IP, bezpieczny dostęp w niezaufanej sieci Wi-Fi albo prywatną trasę do innej sieci. Nie zapewnia anonimowości: witryny nadal widzą jeden adres VPS, a dostawca hostingu nadal zarządza siecią bazową.
Ten przewodnik buduje VPN z pełnym tunelem IPv4 na Ubuntu Server. Zainstalujesz WireGuard, wygenerujesz klucze z restrykcyjnymi uprawnieniami, włączysz routing, dodasz reguły zapory i NAT, podłączysz klientów desktopowych i mobilnych oraz zweryfikujesz tunel. Ten sam projekt obsłuży IPv6, ale dopiero gdy VPS ma routowaną przestrzeń IPv6, a Ty osobno skonfigurujesz przekazywanie i reguły zapory dla IPv6.
Czym jest WireGuard?
WireGuard to nowoczesny, wieloplatformowy protokół VPN wraz z implementacją, który przesyła zaszyfrowane pakiety IP przez UDP. Specyfikacja protokołu WireGuard Specyfikacja definiuje stały zestaw prymitywów kryptograficznych, w tym ChaCha20-Poly1305, Curve25519, BLAKE2s, SipHash24 i HKDF. Celowo niewielki projekt sprawia, że konfiguracja i audyt są prostsze niż w protokołach z wieloma wymiennymi zestawami szyfrów.
WireGuard nie ma centralnego systemu kont ani wbudowanego katalogu użytkowników. Każde urządzenie jest peerem z własną parą kluczy, adresem w tunelu i regułami AllowedIPs. Na VPS jeden peer zwykle pełni rolę bramy wystawionej do internetu, a laptopy i telefony inicjują połączenia do niego.
Dlaczego warto używać WireGuard na VPS?
- Prosty model peerów: Każde urządzenie dostaje jedną parę kluczy i jeden wpis peera.
- Mała powierzchnia ataku: WireGuard stosuje zwięzły protokół i stały zestaw kryptograficzny zamiast udostępniać długą listę przestarzałych opcji.
- Dobra wydajność: Integracja z jądrem w Linuksie i wydajna kryptografia mogą dać wysoką przepustowość, choć wynik nadal zależy od CPU, przepustowości sieci, opóźnień i rozmiaru pakietów.
- Klienci wieloplatformowi: Oficjalne klienty są dostępne dla Windows 10 i 11, macOS, Androida oraz iOS, a Linux i kilka systemów BSD dostarcza natywne narzędzia lub pakiety.
- Roaming: Peer może zmieniać sieci i źródłowe adresy IP bez otrzymywania nowej tożsamości WireGuard; serwer zapamiętuje ostatni uwierzytelniony endpoint.
- Przejrzysta kontrola routingu: AllowedIPs decyduje zarówno o tym, które cele idą przez tunel, jak i o tym, które adresy w tunelu należą do danego peera.
Powiązane materiały: przewodnik Cloudzy po VPS do VPN. W przypadku starszych wdrożeń zobacz przewodnik Cloudzy po konfiguracji PPTP; nie wybieraj PPTP do nowej sieci VPN, w której liczy się bezpieczeństwo.
Pomiń ręczną konfigurację: WireGuard jednym kliknięciem
Jeśli nie masz zaplecza technicznego albo wolisz nie zajmować się instalacją samodzielnie, Cloudzy oferuje wdrożenie WireGuard VPN jednym kliknięciem. Reszta przewodnika opisuje budowę ręczną, a ta sekcja skrót.
- Zaloguj się do panelu sterowania Cloudzy.
- Wybierz WireGuard z listy aplikacji.
- Utwórz VPS w wybranej lokalizacji na wybranym planie. Wystarczy maszyna z Ubuntu o podstawowych parametrach.
Gdy VPS będzie gotowy, zaloguj się i uruchom następujące polecenie, aby wyświetlić konfigurację:
cat client.confZobaczysz coś w tym stylu:
Użyj tej konfiguracji, aby utworzyć nowy tunel w kliencie WireGuard na swoim komputerze, i połączenie jest gotowe. Jeśli wolisz rozumieć każdy element albo potrzebujesz układu, którego gotowy obraz nie obejmuje, przejdź do ręcznej konfiguracji poniżej.
Jak skonfigurować WireGuard na Ubuntu
Poniższe polecenia dotyczą aktualnego wydania Ubuntu Server. Uruchamiaj je przez SSH jako użytkownik z uprawnieniami sudo. Nie zamykaj sesji SSH, dopóki zapora nie zostanie potwierdzona, a wcześniej wykonaj migawkę VPS, jeśli dostawca to umożliwia.
Wymagania wstępne
- Jeden VPS z Ubuntu i publicznym adresem IPv4
- Konto inne niż root z dostępem sudo
- Dostęp SSH oraz dane konsoli awaryjnej dostawcy VPS
- Jedno urządzenie klienckie z oficjalną aplikacją WireGuard lub narzędziami wiersza poleceń
Nie potrzebujesz drugiego serwera Ubuntu. Klientem może być komputer z Windows, Mac, laptop z Linuksem, telefon z Androidem albo iPhone.
Krok 1: Instalacja WireGuard
sudo apt update
sudo apt install wireguard -ySprawdź, czy narzędzia są dostępne:
wg --versionKrok 2: Bezpieczne wygenerowanie kluczy serwera
Utwórz katalog WireGuard i wygeneruj parę kluczy z restrykcyjną umask. Klucza prywatnego nigdy nie wolno kopiować na klienta ani publikować w logach.
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'Wyświetl klucze, gdy musisz je wkleić do plików konfiguracyjnych:
sudo cat /etc/wireguard/server.key
sudo cat /etc/wireguard/server.pubKrok 3: Utworzenie konfiguracji serwera
Otwórz konfigurację interfejsu:
sudo nano /etc/wireguard/wg0.confWklej poniższy blok i zamień SERVER_PRIVATE_KEY na klucz prywatny z poprzedniego kroku:
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEYSieć tunelu 10.8.0.0/24 to tylko przykład. Wybierz inny zakres prywatny, jeśli nakłada się na sieć domową, biurową lub chmurową, do której musisz się dostać. Nie dodawaj SaveConfig = true: przy wyłączaniu interfejsu może nadpisać plik i skasować ręczne zmiany.
sudo chmod 600 /etc/wireguard/wg0.confKrok 4: Włączenie przekazywania IPv4
VPS musi routować pakiety między wg0 a swoim publicznym interfejsem sieciowym. Umieść to ustawienie w osobnym pliku sysctl:
sudo nano /etc/sysctl.d/70-wireguard-routing.confnet.ipv4.ip_forward = 1Zastosuj i sprawdź:
sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf
sysctl net.ipv4.ip_forwardOdpowiada to modelowi routingu opisanemu w przewodniku Ubuntu po bramie WireGuard. IPv6 wymaga routowanego prefiksu IPv6, osobnych adresów w tunelu, przekazywania IPv6 i reguł zapory dla IPv6; nie kieruj ruchu klienta na ::/0, dopóki ta ścieżka nie jest kompletna.
Krok 5: Dodanie reguł zapory i NAT
Ustal nazwę publicznego interfejsu VPS. W poniższym wyniku zwróć uwagę na wartość po dev; typowe nazwy to eth0, ens3 i enp1s0.
ip route show defaultOtwórz ponownie wg0.conf i dodaj poniższe wiersze pod [Interface]. Jeśli Twój publiczny interfejs nazywa się inaczej, zamień eth0 wszędzie:
PostUp = iptables -I FORWARD 1 -i %i -o eth0 -j ACCEPT; iptables -I FORWARD 1 -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i %i -o eth0 -j ACCEPT; iptables -D FORWARD -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADEJeśli UFW jest aktywne, najpierw zezwól na SSH, a dopiero potem zmieniaj jego stan i otwórz port UDP WireGuard:
sudo ufw allow OpenSSH
sudo ufw allow 51820/udp
sudo ufw statusJeśli UFW jest teraz wyłączone, a chcesz je włączyć, najpierw sprawdź, czy istnieje reguła OpenSSH. Nie wyłączaj i nie włączaj ponownie UFW przez SSH tylko po to, by zastosować te reguły; to niepotrzebnie zwiększa ryzyko odcięcia się od serwera.
Krok 6: Uruchomienie interfejsu WireGuard
sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0 --no-pager
sudo wg showJeśli usługa się nie uruchomi, uruchom journalctl, zanim zmienisz cokolwiek innego:
sudo journalctl -u wg-quick@wg0 -n 50 --no-pagerDodawanie klienta WireGuard
Każde urządzenie potrzebuje własnej pary kluczy i własnego adresu IP w tunelu. Nigdy nie używaj jednej konfiguracji klienta na dwóch urządzeniach: zduplikowane klucze i adresy sprawiają, że routing staje się nieprzewidywalny, i uniemożliwiają czyste odebranie dostępu.
Krok 1: Wygenerowanie kluczy klienta
Oficjalne aplikacje desktopowe i mobilne potrafią wygenerować klucze przy tworzeniu pustego tunelu. Na kliencie z Linuksem użyj:
umask 077
wg genkey | tee client.key | wg pubkey > client.pubZostaw client.key na tym urządzeniu. Na serwer skopiuj wyłącznie client.pub.
Krok 2: Dodanie peera na serwerze
sudo nano /etc/wireguard/wg0.confDopisz jeden blok peera. Zamień CLIENT_PUBLIC_KEY na klucz publiczny klienta:
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32Wiersz Address = 10.8.0.2/32 przypisuje adres w tunelu po stronie klienta. W bloku [Peer] na serwerze AllowedIPs = 10.8.0.2/32 wiąże ten adres z danym peerem na potrzeby routingu i weryfikacji źródła. Dla kolejnego urządzenia użyj 10.8.0.3/32, a potem zwiększaj dalej, bez powtórzeń.
sudo systemctl restart wg-quick@wg0Krok 3: Zbudowanie konfiguracji klienta
Utwórz plik client.conf na kliencie i zamień wszystkie symbole zastępcze:
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.8.0.2/32
DNS = 1.1.1.1
[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = VPS_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25AllowedIPs = 0.0.0.0/0 czyni z tego pełny tunel IPv4. Aby uzyskać dostęp wyłącznie do sieci VPN, użyj AllowedIPs = 10.8.0.0/24. Opcja PersistentKeepalive przydaje się klientowi za NAT-em, którego mapowanie ma pozostać osiągalne w bezczynności; przewodnik szybkiego startu WireGuard zaznacza, że większość peerów jej nie potrzebuje.
Krok 4: Import konfiguracji
Użyj przewodnik instalacji klientów WireGuard , aby pobrać obsługiwanego klienta dla swojej platformy.
- Windows: Wybierz Add Tunnel, a następnie zaimportuj client.conf.
- macOS: Wybierz Import tunnel(s) from file i wskaż plik client.conf.
- Android lub iOS: Zaimportuj plik albo zeskanuj wygenerowany z niego kod QR.
Na kliencie z Ubuntu lub Debianem, na którym znajduje się client.conf, zainstaluj qrencode i wyświetl plik w terminalu tego klienta:
sudo apt install qrencode -y
qrencode -t ansiutf8 < client.confKod QR zawiera klucz prywatny klienta. Pokazuj go wyłącznie w zaufanym terminalu, nie zapisuj zrzutów ekranu, a po zaimportowaniu przez telefon wyczyść terminal.
Krok 5: Weryfikacja tunelu
Uruchom tunel, wygeneruj ruch z klienta i wykonaj te sprawdzenia na VPS:
sudo wg show
ip -brief address show wg0Świeży handshake i rosnące liczniki transferu potwierdzają, że WireGuard wymienia pakiety. Następnie zweryfikuj wyjście przez pełny tunel po stronie klienta:
curl -4 https://api.ipify.org; echoPolecenie powinno zwrócić publiczny adres IPv4 VPS. Jeśli nie ma handshake'u, sprawdź adres endpointu, port UDP, zaporę w chmurze, regułę UFW i klucze. Jeśli handshake jest, ale nie ma internetu, sprawdź przekazywanie IP, nazwę publicznego interfejsu, reguły NAT i DNS.
Czy można postawić WireGuard za Nginx?
Zdalny dokumentacja modułu stream w NGINX wyjaśnia, jak NGINX może przekazywać UDP z jednego portu na drugi, więc potrafi przesłać UDP/80 lub UDP/443 do WireGuard na UDP/51820. To jednak przekaźnik UDP, a nie odwrotne proxy HTTP. Nie zamienia WireGuard w TCP ani HTTPS i nie sprawia, że protokół wygląda jak zwykły ruch webowy.
W większości wdrożeń prościej jest zmienić ListenPort w WireGuard i otworzyć odpowiedni port UDP, niż dokładać NGINX. Jeśli sieć całkowicie blokuje UDP albo stosuje głęboką inspekcję pakietów, przekaźnik UDP na NGINX tego nie rozwiąże. Dokumentacja ograniczeń WireGuard Dokumentacja ograniczeń WireGuard stwierdza, że obfuskacja wykracza poza zakres tego protokołu.
Podłączenie VPS do sieci domowej
VPS może pełnić rolę węzła między klientem w podróży a urządzeniem w Twoim domu. To peer po stronie domu nawiązuje wychodzące połączenie WireGuard do VPS, dzięki czemu nie potrzebujesz publicznego IP w domu. Jeśli ten domowy peer jest za NAT-em, ustaw mu PersistentKeepalive.
Dotarcie do całej domowej sieci LAN wymaga czegoś więcej niż dodania peera. Wpis peera na VPS odpowiadający domowej bramie musi zawierać domową podsieć w AllowedIPs, na przykład 192.168.1.0/24. Zdalny klient z pełnym tunelem (AllowedIPs = 0.0.0.0/0) i tak kieruje ten ruch przez VPS; wpis 192.168.1.0/24 dodawaj na kliencie tylko przy tunelowaniu dzielonym. Domowa brama również musi przekazywać ruch między WireGuard a siecią lokalną. Dodaj albo trasę na domowym routerze, albo starannie ograniczoną regułę NAT na domowej bramie. Najpierw sprawdź nakładanie się adresacji: klient podłączony do innej sieci 192.168.1.0/24 nie przekieruje obu sieci czysto bez przenumerowania lub bardziej zaawansowanego routingu opartego na politykach.
WireGuard hostowany samodzielnie a komercyjny VPN
Hostowanie we własnym zakresie zmienia to, kto obsługuje VPN, ale samo w sobie nie poprawia anonimowości. Prywatny VPS daje jeden stabilny wychodzący adres IP, który łatwo powiązać z siecią hostingową. Usługa komercyjna zwykle oferuje współdzielone adresy wyjściowe i łatwą zmianę lokalizacji, ale musisz polegać na jej regulaminach, sposobie działania i publikowanych niezależnych audytach.
Sam WireGuard jest lekki, a mały VPS to często rozsądny punkt startu dla jednej osoby i kilku urządzeń. Nie traktuj stałej liczby RAM ani vCPU jako gwarancji przepustowości. Przetestuj przy swojej rzeczywistej liczbie urządzeń, regionie, rozmiarze pakietów i oczekiwanym paśmie, a potem zmień rozmiar, jeśli ograniczeniem stanie się wysycenie CPU, utrata pakietów albo opóźnienia.
Wybierz własny hosting, gdy stabilny osobisty adres wyjściowy, zdalny dostęp albo kontrola nad serwerem znaczą więcej niż wybór lokalizacji i wygoda. Wybierz komercyjny VPN, gdy zależy Ci na wielu krajach, współdzielonych wyjściach, szerokim wsparciu dla urządzeń konsumenckich i na tym, by ktoś inny zajmował się awariami.
| Kryterium decyzji | WireGuard hostowany samodzielnie | Komercyjny VPN |
|---|---|---|
| Model kosztowy | Jeden serwer plus Twój czas na administrację | Abonament, często tańszy przy dłuższych okresach |
| Lokalizacje wyjściowe | Jedna lokalizacja na serwer | Wiele lokalizacji dostępnych w aplikacji |
| Konfiguracja | Sam konfigurujesz klucze, routing, reguły zapory i klientów | Zainstalować aplikację i zalogować się |
| Konserwacja | Sam łatasz, monitorujesz, robisz kopie zapasowe i diagnozujesz | Usługę obsługuje dostawca |
| Model prywatności | Kontrolujesz serwer, ale dostawca hostingu wciąż widzi metadane | Polegasz na regulaminach dostawcy i publikowanych przez niego niezależnych audytach |
| Najlepszy wybór | Stabilny osobisty adres wyjściowy, zdalny dostęp i kontrola nad infrastrukturą | Zmiana lokalizacji, mało utrzymania i szerokie wsparcie urządzeń |
Podsumowanie
Niezawodne wdrożenie WireGuard sprowadza się do pięciu rzeczy: chronione klucze prywatne, unikalne adresy peerów, poprawne AllowedIPs, działające przekazywanie i NAT oraz reguła zapory dla nasłuchującego portu UDP. Zanim zaufasz tunelowi, sprawdź zarówno handshake, jak i publiczny adres wyjściowy, a po wdrożeniu regularnie aktualizuj VPS.
Jeśli chcesz zbudować serwer ręcznie, zacznij od czystego rozwiązań Cloudzy Ubuntu VPS. Jeśli wolisz pominąć kroki instalacji, skorzystaj z wdrożenia WireGuard jednym kliknięciem od Cloudzy i przejdź od razu do konfiguracji klienta oraz weryfikacji.
Często zadawane pytania
Dlaczego WireGuard pokazuje peera, ale nie ma handshake'u?
Wpis peera dowodzi tylko tego, że konfiguracja się wczytała. Brak handshake'u zwykle oznacza, że klient nie dociera do serwera albo klucze się nie zgadzają. Sprawdź Endpoint po stronie klienta, publiczny adres IP serwera, port UDP/51820 zarówno w zaporze dostawcy, jak i w UFW, oraz klucze publiczne po obu stronach. Przed sprawdzeniem wygeneruj ruch z klienta, bo bezczynny WireGuard milczy.
Dlaczego tunel się łączy, ale internet przestaje działać?
Handshake bez dostępu do internetu zwykle wskazuje na routing, a nie na szyfrowanie. Sprawdź net.ipv4.ip_forward, potwierdź nazwę publicznego interfejsu w regule NAT, przejrzyj reguły FORWARD i przetestuj DNS oddzielnie od surowej łączności IP. Upewnij się też, że AllowedIPs po stronie klienta odpowiada zamierzonemu tunelowi pełnemu lub dzielonemu.
Czy każdy klient potrzebuje PersistentKeepalive?
Nie. Dodaj ją, gdy peer za NAT-em musi utrzymać otwarte mapowanie w czasie bezczynności, co często dotyczy telefonów, bram domowych i niektórych restrykcyjnych sieci. Pomiń ją, gdy peer komunikuje się często albo nie musi być osiągalny z drugiej strony w bezczynności.
