Jak skonfigurować WireGuard w Ubuntu

Wprowadzenie

WireGuard to lekka wirtualna sieć prywatna (VPN), która obsługuje zarówno połączenia IPv4, jak i IPv6. VPN pozwala na korzystanie z nieznanych sieci tak, jakbyś był w sieci prywatnej. Umożliwia bezpieczniejsze korzystanie z internetu z urządzeń takich jak laptopy czy telefony komórkowe podczas łączenia się z niezaufanymi sieciami, w tym publicznym WiFi.

Szyfrowanie WireGuard opiera się na kluczach publicznych i prywatnych, które umożliwiają uczestnikom nawiązywanie między sobą zaszyfrowanych tuneli. Każda wersja WireGuard używa stałego zestawu nowoczesnych metod kryptograficznych, co pomaga utrzymać protokół prostym i przewidywalnym. Takie rozwiązanie eliminuje negocjacje w czasie pracy i zmniejsza ryzyko błędów konfiguracji.

Dla porównania, inne oprogramowanie VPN, takie jak OpenVPN i IPsec, opiera się na protokole Transport Layer Security oraz certyfikatach w celu uwierzytelniania i ustanawiania zaszyfrowanych tuneli. Chociaż takie podejście zapewnia elastyczność i obsługuje szeroką gamę klientów, zwiększa również złożoność konfiguracji i utrudnia przewidywanie zachowania systemu w praktyce.

W tym samouczku skonfigurujesz WireGuard na serwerze Ubuntu oraz skonfigurujesz inną maszynę, aby łączyła się z nim jako węzeł przy użyciu zarówno IPv4, jak i IPv6, co powszechnie nazywane jest konfiguracją dual-stack. Dowiesz się również, jak trasować ruch węzłów przez serwer WireGuard w konfiguracji bramy, a także jak korzystać z VPN do szyfrowanej komunikacji peer-to-peer.

Oprócz podstawowej konfiguracji, ten przewodnik omawia praktyczne zagadnienia ważne w rzeczywistych wdrożeniach. Obejmują one zrozumienie architektury peer-to-peer WireGuard, zarządzanie i rotację kluczy, prawidłowe obsługiwanie IPv6 i routingu dual-stack, zwiększanie niezawodności dla peerów stojących za NAT, optymalizację wydajności oraz zrozumienie, jak WireGuard wypada w porównaniu z OpenVPN pod względem protokołów transportowych i zachowania zapory sieciowej.

Do celów tego poradnika, inny system Ubuntu jest używany jako Peer WireGuard. Późniejsze poradniki z tej serii obejmują instalację i używanie WireGuard na Windows, macOS, Android i iOS.

Wymagania wstępne

Aby wykonać ten samouczek, będziesz potrzebować:

• Jeden serwer Ubuntu z użytkownikiem sudo niebędącym rootem i włączoną zaporą sieciową. Aby to skonfigurować, możesz skorzystać z naszego poradnika Początkowa konfiguracja serwera z Ubuntu. W całym tym przewodniku będziemy odnosić się do niego jako do Serwera WireGuard.

• Będziesz potrzebować maszyny klienckiej, której użyjesz do połączenia się z serwerem WireGuard. W tym samouczku będziemy odnosić się do tej maszyny jako WireGuard Peer. Dla celów tego samouczka zaleca się użycie swojej lokalnej maszyny jako WireGuard Peer, ale możesz również używać serwerów zdalnych lub telefonów komórkowych jako klientów, jeśli wolisz. Jeśli korzystasz z systemu zdalnego, upewnij się, że wykonasz wszystkie opcjonalne sekcje później w tym samouczku, w przeciwnym razie możesz zablokować sobie dostęp do systemu.

• Aby korzystać z WireGuard z IPv6, musisz również upewnić się, że Twój serwer jest skonfigurowany do obsługi tego rodzaju ruchu. Jeśli chcesz włączyć obsługę IPv6 z WireGuard i używasz Linuksowego Dropleta na Linux-Console.net, zapoznaj się z tą stroną dokumentacji Jak włączyć IPv6 na Dropletach. Możesz dodać obsługę IPv6 podczas tworzenia Dropleta lub później, korzystając z instrukcji na tej stronie.

Przegląd architektury WireGuard

Przed skonfigurowaniem WireGuard warto zrozumieć, jak systemy, węzły i ruch sieciowy wzajemnie oddziałują. WireGuard korzysta ze świadomie prostej architektury, która unika płaszczyzn kontrolnych, urzędów certyfikacyjnych oraz dynamicznych negocjacji parametrów konfiguracji w czasie działania. Wszystkie operacje szyfrowania, uwierzytelniania i trasowania są określone wprost w plikach konfiguracyjnych.

Terminologia projektowania i topologii peer-to-peer

WireGuard jest w gruncie rzeczy protokołem peer-to-peer. Ten sam software WireGuard i moduł jądra działają na wszystkich uczestniczących systemach, i nie ma odrębnych plików binarnych dla serwera czy klienta.

W tym samouczku termin Serwer WireGuard odnosi się do centralnego węzła w topologii gwiazda. System ten jest publicznie dostępny i pełni rolę punktu koordynacyjnego dla innych węzłów. Termin Peer WireGuard odnosi się do urządzeń łączących się z tym węzłem. Terminy te opisują topologię sieci używaną w tym przewodniku, a nie różne role lub możliwości oprogramowania.

Zrozumienie tej różnicy jest ważne, ponieważ WireGuard nie ma opcji konfiguracji tylko dla serwera. Każdy system może działać jako węzeł centralny, węzeł poboczny lub oba, w zależności całkowicie od tego, jak zdefiniowane są klucze, adresy i reguły routingu.

Główne składniki w wdrożeniu WireGuard

Wdrożenie WireGuard składa się z niewielkiej liczby wyraźnie określonych komponentów, z których każdy ma konkretną odpowiedzialność.

• Centralny węzeł (Hub): Centralny węzeł to system dostępny publicznie, który nasłuchuje zaszyfrowanego ruchu UDP na jednym porcie. Udostępnia wirtualny interfejs tunelowy, zwykle nazywany wg0, i przechowuje klucze publiczne innych węzłów, które mają uprawnienia do komunikacji z nim. Hub nie wyszukuje dynamicznie węzłów ani nie akceptuje połączeń domyślnie. Ruch jest akceptowany tylko od węzłów, których klucze publiczne i dozwolone zakresy IP są wyraźnie skonfigurowane.

• Łączenie węzłów (Spokes): Łączące się węzły to urządzenia, które ustanawiają zaszyfrowane tunele do węzła centralnego. Urządzenia te mogą być laptopami, serwerami, maszynami wirtualnymi lub systemami mobilnymi. Każdy węzeł posiada unikalną parę kluczy kryptograficznych oraz jeden lub więcej prywatnych adresów IP przypisanych do jego interfejsu tunelu. Węzeł przesyła ruch do tunelu tylko wtedy, gdy jego zasady routingu nakazują mu to zrobić.

• Interfejs tunelowy (wg0): Interfejs tunelowy to wirtualne urządzenie sieciowe tworzone na każdym uczestniczącym systemie. Cały szyfrowany ruch wchodzi i wychodzi przez ten interfejs. Z punktu widzenia systemu operacyjnego, wg0 zachowuje się jak standardowy interfejs sieciowy, co pozwala na stosowanie zwykłych tabel routingu, reguł zapory ogniowej i zachowań przekazywania ruchu.

Szyfrowanie, uwierzytelnianie i procedury powitalne

WireGuard używa kryptografii klucza publicznego do uwierzytelniania uczestników i szyfrowania ruchu. Każdy uczestnik generuje długoterminowy klucz prywatny, który pozostaje na lokalnym systemie i nigdy nie jest przesyłany. Odpowiadający mu klucz publiczny jest udostępniany innym uczestnikom i dodawany do ich konfiguracji.

Gdy rozpoczyna się komunikacja, WireGuard wykonuje cichy, automatyczny kryptograficzny uścisk dłoni oparty na frameworku protokołu Noise. Ten uścisk dłoni ustanawia efemeryczne klucze sesyjne i zapewnia Doskonałą Tajemniczość Przemieszczeń. Klucze sesyjne są okresowo wymieniane bez interwencji użytkownika.

WireGuard nie negocjuje zestawów szyfrów, metod uwierzytelniania ani wersji protokołu. Wszystkie elementy kryptograficzne są ustalone przez projekt. Usuwa to całą klasę błędów konfiguracyjnych, jednocześnie zapewniając nowoczesne gwarancje bezpieczeństwa.

Obsługiwane wzorce przepływu ruchu

WireGuard obsługuje wiele wzorców ruchu w zależności od tego, jak skonfigurowano trasowanie i przekazywanie. Ten samouczek skupia się na dwóch najczęstszych przypadkach użycia.

Dostęp typu peer-to-peer lub w sieci wewnętrznej

W konfiguracji peer-to-peer lub dostępu wewnętrznego ruch jest szyfrowany tylko między systemami należącymi do VPN. Centralny węzeł działa jako bezpieczny punkt końcowy lub przekaźnik, ale nie przekazuje ruchu do sieci zewnętrznych.

Ta konfiguracja jest zazwyczaj używana do dostępu do prywatnych usług, zarządzania infrastrukturą lub łączenia izolowanych systemów. Ruch jest kierowany do tunelu tylko wtedy, gdy adres docelowy pasuje do prywatnych zakresów IP zdefiniowanych w konfiguracji partnera.

Tryb bramy VPN

W trybie bramy, centralny węzeł przekazuje ruch od innych węzłów do sieci zewnętrznych, w tym publicznego Internetu. Węzły wysyłają część lub cały swój ruch przez tunel, a centralny węzeł kieruje ten ruch dalej, stosując przekazywanie IP i translację adresów sieciowych.

Ta konfiguracja wymaga dodatkowych ustawień systemowych, w tym przekazywania jądra i reguł zapory sieciowej. Gdy tryb bramki jest włączony, ruch wychodzący od peerów wydaje się pochodzić z publicznego adresu IP centralnego peera.

Podwójna rola AllowedIPs

Dyrektywa AllowedIPs służy dwóm różnym celom w WireGuard.

Po pierwsze, definiuje zachowanie routingu wychodzącego. Gdy adres docelowy pakietu pasuje do wpisu w AllowedIPs, pakiet ten jest kierowany przez tunel WireGuard.

Po drugie, AllowedIPs działa jak ścisła lista kontroli dostępu przychodzącego. Gdy pakiet jest odbierany od partnera, WireGuard sprawdza adres IP źródła pakietu. Jeśli adres źródłowy nie znajduje się na liście AllowedIPs tego partnera, pakiet jest natychmiast odrzucany.

Ta podwójna rola jest zamierzona i jest jednym z najczęstszych źródeł błędów konfiguracyjnych. Sama poprawna trasowanie nie wystarcza. Adresy IP źródłowe, z których może korzystać peer, muszą być również wyraźnie dozwolone.

Automatyzacja trasowania i narzędzia pomocnicze

Sam moduł jądra WireGuard nie modyfikuje tras systemowych, ustawień DNS ani reguł zapory sieciowej. Służy jedynie do szyfrowania i odszyfrowywania pakietów oraz kojarzenia ich z peerami.

Automatyzacja trasowania jest obsługiwana przez narzędzia pomocnicze, takie jak wg-quick. To narzędzie odczytuje plik konfiguracyjny WireGuard i stosuje niezbędne wpisy w tablicy routingu, ustawienia DNS oraz reguły zapory ogniowej, gdy tunel jest uruchamiany lub zamykany.

Jeżeli WireGuard jest konfigurowany za pomocą alternatywnych narzędzi, takich jak surowe polecenia wg, systemd-networkd lub niestandardowe skrypty, te zmiany tras muszą być zarządzane ręcznie.

To rozdzielenie utrzymuje główny protokół prostym, jednocześnie umożliwiając elastyczną integrację z różnymi stosami sieciowymi systemu.

Krok 1 — Instalacja WireGuard i wygenerowanie pary kluczy

Pierwszym krokiem w tym samouczku jest zainstalowanie WireGuard na swoim serwerze. Na początek zaktualizuj indeks pakietów swojego serwera WireGuard i zainstaluj WireGuard, korzystając z poniższych poleceń. Może zostać wyświetlony monit o podanie hasła użytkownika sudo, jeśli jest to pierwsze użycie sudo w tej sesji:

sudo apt update

sudo apt install wireguard

Teraz, gdy masz zainstalowany WireGuard, następnym krokiem jest wygenerowanie pary kluczy prywatnego i publicznego dla serwera. Użyjesz wbudowanych poleceń wg genkey i wg pubkey, aby utworzyć klucze, a następnie dodasz klucz prywatny do pliku konfiguracyjnego WireGuard.

Będziesz musiał również zmienić uprawnienia do klucza, który właśnie utworzyłeś, używając polecenia chmod, ponieważ domyślnie plik jest czytelny dla każdego użytkownika na Twoim serwerze.

Utwórz klucz prywatny dla WireGuard i zmień jego uprawnienia, używając następujących poleceń:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

Polecenie sudo chmod go=... usuwa wszelkie uprawnienia do pliku dla użytkowników i grup innych niż root, aby upewnić się, że tylko on może uzyskać dostęp do prywatnego klucza.

Powinieneś otrzymać pojedynczą linię zakodowanego w formacie base64 wyjścia, które jest kluczem prywatnym. Kopia wyjścia jest również przechowywana w pliku /etc/wireguard/private.key do późniejszego wykorzystania przez część polecenia tee. Dokładnie zanotuj wyjściowy klucz prywatny, ponieważ będziesz musiał dodać go później do pliku konfiguracyjnego WireGuard w tej sekcji.

Kolejnym krokiem jest utworzenie odpowiadającego klucza publicznego, który jest wyprowadzany z klucza prywatnego. Do utworzenia pliku klucza publicznego użyj następującego polecenia:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

To polecenie składa się z trzech pojedynczych poleceń połączonych ze sobą za pomocą operatora | (pipe):

• sudo cat /etc/wireguard/private.key: to polecenie odczytuje plik klucza prywatnego i wypisuje go do standardowego strumienia wyjściowego.
• wg pubkey: drugie polecenie przyjmuje wyjście z pierwszego polecenia jako dane wejściowe i przetwarza je, aby wygenerować klucz publiczny.
• sudo tee /etc/wireguard/public.key: końcowe polecenie pobiera wynik polecenia generującego klucz publiczny i przekierowuje go do pliku o nazwie /etc/wireguard/public.key.

Kiedy uruchomisz polecenie, ponownie otrzymasz pojedynczą linię zakodowanego w base64 wyniku, który jest kluczem publicznym dla twojego serwera WireGuard. Skopiuj go w jakieś miejsce do odniesienia, ponieważ będziesz musiał przekazać klucz publiczny każdemu węzłowi, który łączy się z serwerem.

Krok 2 — Wybór adresów IPv4 i IPv6

W poprzedniej sekcji zainstalowałeś WireGuard i wygenerowałeś parę kluczy, która będzie używana do szyfrowania ruchu do i z serwera. W tej sekcji utworzysz plik konfiguracyjny dla serwera i skonfigurujesz WireGuard tak, aby uruchamiał się automatycznie po ponownym uruchomieniu serwera. Zdefiniujesz również prywatne adresy IPv4 i IPv6, które będą używane przez Twój serwer WireGuard i jego węzły.

Jeśli planujesz korzystać zarówno z adresów IPv4, jak i IPv6, postępuj zgodnie z obiema tymi sekcjami. W przeciwnym razie postępuj zgodnie z instrukcjami w odpowiedniej sekcji, odpowiedniej dla potrzeb sieci Twojego VPN.

Krok 2(a) — Wybór zakresu IPv4

Jeśli używasz swojego serwera WireGuard z klientami IPv4, serwer potrzebuje zakresu prywatnych adresów IPv4 do użycia przez klientów oraz dla swojego interfejsu tunelowego. Możesz wybrać dowolny zakres adresów IP z następujących zarezerwowanych bloków adresów (jeśli chcesz dowiedzieć się więcej o tym, jak te bloki są przydzielane, odwiedź specyfikację RFC 1918):

• 10.0.0.0 do 10.255.255.255 (prefiks 10/8)
• 172.16.0.0 do 172.31.255.255 (prefiks 172.16/12)
• 192.168.0.0 do 192.168.255.255 (prefiks 192.168/16)

Na potrzeby tego samouczka użyjemy 10.8.0.0/24 jako bloku adresów IP z pierwszego zakresu zarezerwowanych adresów IP. Ten zakres pozwoli na połączenie do 255 różnych peerów i generalnie nie powinien nachodzić ani kolidować z innymi prywatnymi zakresami IP. Możesz swobodnie wybrać zakres adresów, który będzie pasował do konfiguracji twojej sieci, jeśli ten przykładowy zakres nie jest kompatybilny z twoimi sieciami.

Serwer WireGuard będzie używać pojedynczego adresu IP z zakresu jako swojego prywatnego adresu IPv4 tunelu. Tutaj użyjemy 10.8.0.1/24, ale można użyć dowolnego adresu z zakresu od 10.8.0.1 do 10.8.0.255. Zanotuj wybrany adres IP, jeśli użyjesz czegoś innego niż 10.8.0.1/24. Ten adres IPv4 dodasz do pliku konfiguracyjnego, który zdefiniujesz w Tworzenie konfiguracji serwera WireGuard.

Krok 2(b) — Wybór zakresu IPv6

Jeśli używasz WireGuard z IPv6, będziesz musiał wygenerować unikalny lokalny prefiks adresu IPv6 unicast na podstawie algorytmu opisanego w RFC 4193. Adresy, których używasz z WireGuard, będą powiązane z wirtualnym interfejsem tunelowym. Będziesz musiał wykonać kilka kroków, aby wygenerować losowy, unikalny prefiks IPv6 w zarezerwowanym bloku prywatnych adresów IPv6 fd00::/8.

Według RFC zaleca się, aby uzyskać unikalny prefiks IPv6 poprzez połączenie czasu dnia z unikalną wartością identyfikacyjną z systemu, takiego jak numer seryjny lub identyfikator urządzenia. Następnie wartości te są haszowane i skracane, co skutkuje zestawem bitów, które mogą być używane jako unikalny adres w zarezerwowanym prywatnym bloku fd00::/8 adresów IP.

Aby rozpocząć generowanie zakresu IPv6 dla Twojego serwera WireGuard, zbierz 64-bitowy znacznik czasu, używając narzędzia date za pomocą następującego polecenia:

date +%s%N

Otrzymasz liczbę podobną do poniższej, która jest liczbą sekund (%s w poleceniu date) oraz nanosekund (%N) od 1970-01-01 00:00:00 UTC połączonych razem:

1628101352127592197

Zapisz wartość w jakimś miejscu do późniejszego użycia w tej sekcji. Następnie skopiuj wartość machine-id dla swojego serwera z pliku /var/lib/dbus/machine-id. Ten identyfikator jest unikalny dla Twojego systemu i nie powinien się zmieniać tak długo, jak serwer istnieje.

cat /var/lib/dbus/machine-id

Otrzymasz wynik podobny do poniższego:

/var/lib/dbus/machine-id
20086c25853947c7aeee2ca1ea849d7d

Teraz musisz połączyć znacznik czasu z machine-id i zahashować otrzymaną wartość za pomocą algorytmu SHA-1. Polecenie będzie używać następującego formatu:

printf <timestamp><machine-id> | sha1sum

Uruchom polecenie, podstawiając swoje wartości znacznika czasu i identyfikatora maszyny:

printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sum

Otrzymasz wartość haszującą, taką jak następująca:

4f267c51857d6dc93a0bca107bca2f0d86fac3bc  -

Zwróć uwagę, że wynik polecenia sha1sum jest w formacie szesnastkowym, więc do przedstawienia pojedynczego bajtu danych używane są dwa znaki. Na przykład 4f i 26 w przykładowym wyniku to pierwsze dwa bajty przetworzonych danych.

Algorytm w RFC wymaga jedynie najmniej znaczących (ostatnich) 40 bitów, czyli 5 bajtów, wygenerowanego hasza. Użyj polecenia cut, aby wydrukować ostatnie 5 bajtów zakodowanych w formacie szesnastkowym z hasza:

printf 4f267c51857d6dc93a0bca107bca2f0d86fac3bc | cut -c 31-

Argument -c mówi poleceniu cut, aby wybrało tylko określony zestaw znaków. Argument 31- mówi poleceniu cut, aby wydrukowało wszystkie znaki od pozycji 31 do końca wiersza wejściowego.

Powinieneś otrzymać wynik podobny do następującego:

0d86fac3bc

W tym przykładzie wyjściowym zestaw bajtów to: 0d 86 fa c3 bc.

Teraz możesz skonstruować swój unikalny prefiks sieci IPv6, dodając 5 bajtów, które wygenerowałeś, do prefiksu fd, oddzielając co 2 bajty dwukropkiem : dla czytelności. Ponieważ każda podsieć w twoim unikalnym prefiksie może pomieścić łącznie 18 446 744 073 709 551 616 możliwych adresów IPv6, możesz ograniczyć podsieć do standardowego rozmiaru /64 dla uproszczenia.

Używając bajtów wygenerowanych wcześniej z rozmiarem podsieci /64, otrzymany prefiks będzie następujący:

Unique Local IPv6 Address Prefix
fd0d:86fa:c3bc::/64

Ten zakres fd0d:86fa:c3bc::/64 jest tym, którego będziesz używać do przypisywania indywidualnych adresów IP swoim interfejsom tunelu WireGuard na serwerze i urządzeniach klienckich. Aby przydzielić adres IP dla serwera, dodaj 1 po końcowych znakach ::. Powstały adres będzie wyglądał tak: fd0d:86fa:c3bc::1/64. Urządzenia klienckie mogą używać dowolnego adresu w tym zakresie, ale zazwyczaj zwiększa się wartość o jeden przy każdym dodaniu nowego klienta, np. fd0d:86fa:c3bc::2/64. Zanotuj adres IP i przejdź do konfiguracji serwera WireGuard w następnej sekcji tego samouczka.

Rozważania dotyczące konfiguracji IPv6 i podwójnego stosu

Obecne kroki w tym samouczku wyjaśniają, jak generować adresy IPv6 i przypisywać je do interfejsów WireGuard. Jednak zachowanie IPv6 w WireGuard różni się pod kilkoma istotnymi względami od IPv4, szczególnie gdy WireGuard jest używany jako brama VPN. Zrozumienie tych różnic pomaga zapobiegać awariom routingu, częściowemu tunelowaniu i typowym wyciekom IPv6.

Obsługa IPv6 w WireGuard

WireGuard obsługuje IPv6 jako pełnoprawny protokół. Ruch IPv6 jest szyfrowany, uwierzytelniany i kierowany przy użyciu tych samych mechanizmów co ruch IPv4. Nie ma oddzielnego trybu IPv6 ani dodatkowej opcji konfiguracji. Jeśli adresy IPv6 zostaną przypisane do interfejsu tunelu i reguły routingu na to pozwalają, ruch IPv6 przepływa przez tunel automatycznie.

W przeciwieństwie do IPv4, IPv6 został zaprojektowany tak, aby unikać NAT, używając globalnie trasowalnych adresów, ale w praktyce wiele środowisk VPN i chmurowych nadal korzysta z NAT dla uproszczenia operacyjnego. Jednak to zachowanie zależy od środowiska sieciowego. W wielu konfiguracjach bramek VPN, takich jak instancje VPS w chmurze czy domowe routery, serwer nie otrzymuje przypisanego prefiksu IPv6, który można by trasować do peerów VPN.

W tych powszechnych scenariuszach węzły są przypisywane prywatne adresy IPv6, zazwyczaj z zakresu Unique Local Address (ULA). Gdy używane są prywatne adresy IPv6, a serwer nie ma dla nich routowalnego prefiksu, nadal wymagane jest maskowanie IPv6. Zwykle implementuje się je za pomocą reguł ip6tables -t nat, podobnie jak maskowanie IPv4, aby umożliwić węzłom VPN dostęp do publicznego Internetu.

IPv6 może całkowicie uniknąć NAT, gdy dostępna jest odpowiednia delegacja prefiksu. Jednak większość prostych wdrożeń bramek VPN nadal polega na maskowaniu IPv6, aby utrzymać zarządzanie trasowaniem pod kontrolą.

Wyjaśnienie działania trybu Dual-Stack

Konfiguracja dwupodstawowa umożliwia korzystanie zarówno z IPv4, jak i IPv6 na tym samym interfejsie WireGuard. W tej konfiguracji interfejs wg0 otrzymuje jeden adres IPv4 i jeden adres IPv6, a każdy protokół jest trasowany niezależnie.

System operacyjny ocenia trasy IPv4 i IPv6 osobno. Peer może skutecznie przesyłać ruch IPv4 przez tunel, podczas gdy ruch IPv6 go omija, lub odwrotnie. Takie zachowanie jest oczekiwane i prawie zawsze wskazuje na problem z konfiguracją, a nie błąd samego WireGuarda.

Aby routing w trybie podwójnego stosu działał poprawnie, muszą być spełnione pewne warunki. Zarówno serwer, jak i peer muszą mieć przypisane adresy IPv4 i IPv6 do swoich interfejsów WireGuard. Dyrektywa AllowedIPs musi obejmować zarówno zakresy IPv4, jak i IPv6. Przekazywanie pakietów musi być włączone osobno dla IPv4 i IPv6. Zasady zapory sieciowej muszą zezwalać na przepływ i powrotny ruch dla obu protokołów.

Przypisywanie adresów i długości prefiksów

Dla IPv4 wdrożenia WireGuard zazwyczaj korzystają z prywatnych zakresów adresów, takich jak 10.0.0.0/8 lub 192.168.0.0/16. Każdemu węzłowi zwykle przypisuje się jeden adres IPv4.

Dla IPv6 powszechnie definiuje się sieć VPN jako prefiks /64, na przykład fd00::/64. Podczas gdy sieci Ethernet wymagają /64 do wykrywania sąsiadów i autokonfiguracji adresów, WireGuard działa jako interfejs punkt-punkt warstwy 3 i nie korzysta z tych mechanizmów.

Z tego powodu bezpieczne i często zalecane jest przypisanie każdemu węzłowi adresu IPv6 /128, takiego jak fd00::2/128. Używanie adresów /128 zapewnia ścisłe zachowanie routingu i zapobiega próbom bezpośredniej komunikacji węzłów z innymi adresami w podsieci bez odpowiednich reguł routingu.

Definiowanie sieci jako /64, podczas przypisywania węzłom adresów /128, zapewnia przejrzystość i unika niejednoznacznego routingu.

Trasowanie całego ruchu za pomocą IPv6

Gdy WireGuard jest skonfigurowany jako brama VPN, ruch IPv6 musi być kierowany w sposób jawny, tak samo jak ruch IPv4.

Dla IPv4, trasowanie całego ruchu wykorzystuje prefiks 0.0.0.0/0. Dla IPv6, równoważnym prefiksem jest ::/0. Oba prefiksy muszą być uwzględnione, jeśli celem jest trasowanie całego ruchu przez VPN.

Jeśli skonfigurowany jest tylko 0.0.0.0/0, ruch IPv4 jest przesyłany przez VPN, podczas gdy ruch IPv6 nadal korzysta z lokalnego interfejsu sieciowego. Ta sytuacja jest znana jako wyciek IPv6. Zwykle skutkuje to tym, że zapytania DNS, ruch w sieci web lub połączenia aplikacji omijają VPN przez IPv6, podczas gdy ruch IPv4 pozostaje chroniony.

Wycieki IPv6 są częstym źródłem zamieszania i zawsze powinny być sprawdzane, gdy włączona jest sieć dual-stack.

Zapora sieciowa, przekazywanie i ICMPv6

Przekazywanie IPv6 musi być włączone niezależnie od przekazywania IPv4. Włączenie jednego nie powoduje automatycznego włączenia drugiego. Obie opcje są wymagane podczas kierowania ruchem między interfejsami.

Reguły zapory sieciowej muszą być również zdefiniowane wprost dla IPv6. Narzędzia takie jak ufw, iptables i nftables traktują IPv4 i IPv6 jako oddzielne zestawy reguł. Brakujące reguły dla IPv6 mogą cicho blokować ruch, nawet gdy łączność IPv4 wydaje się działać.

Szczególnie ważne jest zezwalanie na ruch ICMPv6. W przeciwieństwie do IPv4, IPv6 zależy od ICMPv6 do podstawowych funkcji, takich jak wykrywanie maksymalnego rozmiaru jednostki transmisyjnej (Path MTU Discovery). Jeśli ICMPv6 jest zablokowany, połączenia mogą się zawieszać lub nie działać prawidłowo podczas przesyłania większych pakietów, nawet jeśli małe pakiety wydają się działać.

Typowe pułapki w konfiguracji Dual-Stack

W wdrożeniach WireGuard w trybie dual-stack często występuje kilka problemów. Trasy IPv6 mogą być nieobecne w dyrektywie AllowedIPs, co powoduje, że ruch IPv6 omija tunel. Przekazywanie IPv6 może nie być włączone na serwerze, co uniemożliwia opuszczenie interfejsu tunelu przez ruch. Reguły zapory mogą pozwalać na ruch IPv4, ale blokować ruch IPv6 lub ICMPv6. Serwery DNS mogą zwracać adresy IPv6, mimo że routowanie IPv6 nie jest poprawnie skonfigurowane.

Te problemy często pojawiają się jako sporadyczne awarie i są często mylnie diagnozowane jako problemy z aplikacją lub protokołem.

Wybór między IPv4-only, IPv6-only a Dual-Stack

W niektórych środowiskach korzystanie z jednego protokołu upraszcza operacje.

Wdrożenia wyłącznie IPv4 są łatwiejsze do integracji z systemami i narzędziami dziedziczonymi. Wdrożenia wyłącznie IPv6 eliminują potrzebę NAT dla IPv4 i unikają wyczerpania adresów, ale wymagają spójnego wsparcia IPv6 ze strony dostawców i sieci klientów.

Wdrożenia w trybie dual-stack zapewniają największą elastyczność, ale wymagają również najstaranniejszego planowania, konfiguracji i weryfikacji.

Krok 3 — Tworzenie konfiguracji serwera WireGuard

Przed utworzeniem konfiguracji serwera WireGuard będziesz potrzebować następujących informacji:

• Upewnij się, że masz dostępny klucz prywatny z Instalowanie WireGuard i generowanie pary kluczy.
• Jeśli korzystasz z WireGuard z IPv4, będziesz potrzebować adresu IP, który wybrałeś dla serwera w Wybieranie zakresu IPv4, który w tym przykładzie to 10.8.0.1/24.
• Jeśli używasz WireGuard z IPv6, będziesz potrzebować adresu IP serwera, który wygenerowałeś w Wybieranie zakresu IPv6. W tym przykładzie adres IP to fd0d:86fa:c3bc::1/64.

Gdy będziesz miał wymagany klucz prywatny i adres(y) IP, utwórz nowy plik konfiguracyjny, używając nano lub innego wybranego edytora, uruchamiając następujące polecenie:

sudo nano /etc/wireguard/wg0.conf

Dodaj następujące wiersze do pliku, zamieniając swój klucz prywatny w miejsce zaznaczonej wartości base64_encoded_private_key_goes_here oraz adres(y) IP w linii Address. Możesz także zmienić linię ListenPort, jeśli chcesz, aby WireGuard był dostępny na innym porcie:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd0d:86fa:c3bc::1/64
ListenPort = 51820
SaveConfig = true

Linia SaveConfig zapewnia, że po wyłączeniu interfejsu WireGuard wszelkie zmiany zostaną zapisane w pliku konfiguracyjnym.

Zapisz i zamknij plik /etc/wireguard/wg0.conf. Jeśli używasz nano, możesz to zrobić za pomocą CTRL+X, następnie Y i ENTER, aby potwierdzić. Masz teraz początkową konfigurację serwera, którą możesz rozbudować w zależności od tego, jak planujesz korzystać z serwera VPN WireGuard.

Krok 4 — Dostosowywanie konfiguracji sieciowej serwera WireGuard

Jeśli używasz WireGuard, aby połączyć klienta z serwerem WireGuard w celu uzyskania dostępu wyłącznie do usług na serwerze, nie musisz wypełniać tej sekcji. Jeśli jednak chcesz, aby ruch internetowy klienta WireGuard był przekazywany przez serwer WireGuard, będziesz musiał skonfigurować przekazywanie IP, postępując zgodnie z tą częścią samouczka.

Aby skonfigurować przekazywanie, otwórz plik /etc/sysctl.conf za pomocą nano lub innego preferowanego edytora:

sudo nano /etc/sysctl.conf

Jeśli używasz IPv4 z WireGuard, dodaj następującą linię na końcu pliku:

net.ipv4.ip_forward=1

Jeśli używasz IPv6 z WireGuard, dodaj tę linię na końcu pliku:

net.ipv6.conf.all.forwarding=1

Jeśli używasz zarówno IPv4, jak i IPv6, upewnij się, że uwzględniasz obie linie. Zapisz i zamknij plik po zakończeniu.

Aby odczytać plik i załadować nowe wartości dla bieżącej sesji terminala, uruchom:

sudo sysctl -p

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

Teraz Twój serwer WireGuard będzie mógł przekazywać przychodzący ruch z wirtualnego urządzenia VPN Ethernet do innych na serwerze, a stamtąd do publicznego Internetu. Korzystanie z tej konfiguracji pozwoli Ci kierować cały ruch internetowy z Twojego klienta WireGuard przez adres IP serwera, a publiczny adres IP klienta będzie skutecznie ukryty.

Jednak zanim ruch będzie mógł być prawidłowo kierowany przez Twój serwer, będziesz musiał skonfigurować kilka reguł zapory. Reguły te zapewnią prawidłowy przepływ ruchu do i od Twojego serwera WireGuard oraz jego uczestników.

Krok 5 — Konfigurowanie zapory sieciowej serwera WireGuard

W tej sekcji edytujesz konfigurację serwera WireGuard, aby dodać reguły zapory sieciowej, które zapewnią prawidłowe kierowanie ruchu do i z serwera oraz klientów. Podobnie jak w poprzedniej sekcji, pomiń ten krok, jeśli używasz swojego VPN WireGuard wyłącznie do połączenia między maszynami w celu uzyskania dostępu do zasobów ograniczonych do twojego VPN.

Aby umożliwić ruch VPN WireGuard przez zaporę serwera, należy włączyć maskaradę, która jest koncepcją iptables zapewniającą dynamiczną translację adresów sieciowych (NAT) w locie, umożliwiającą prawidłowe kierowanie połączeń klientów.

Najpierw znajdź publiczny interfejs sieciowy swojego serwera WireGuard, używając podpolecenia ip route:

ip route list default

Interfejs publiczny to ciąg znaków znajdujący się w wyniku tego polecenia, który występuje po słowie „dev”. Na przykład, wynik ten pokazuje interfejs o nazwie eth0, który jest podświetlony poniżej:

default via 203.0.113.1 dev eth0 proto static

Zanotuj nazwę swojego urządzenia, ponieważ dodasz ją do reguł iptables w następnym kroku.

Aby dodać reguły zapory sieciowej do serwera WireGuard, otwórz ponownie plik /etc/wireguard/wg0.conf za pomocą nano lub innego ulubionego edytora.

sudo nano /etc/wireguard/wg0.conf

Na dole pliku, po linii SaveConfig=true, wklej następujące linie:

/etc/wireguard/wg0.conf
. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Linie PostUp będą uruchamiane, gdy serwer WireGuard uruchomi wirtualny tunel VPN. W tym przykładzie dodadzą trzy reguły ufw i iptables:

• ufw route allow in on wg0 out on eth0: Ta reguła pozwoli na przekazywanie ruchu IPv4 i IPv6, który przychodzi przez interfejs VPN wg0, do interfejsu sieciowego eth0 na serwerze. Działa ona w połączeniu z wartościami sysctl net.ipv4.ip_forward i net.ipv6.conf.all.forwarding, które skonfigurowałeś w poprzedniej sekcji.
• iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Ta reguła konfiguruje maskowanie (masquerading) i przepisuje ruch IPv4, który przychodzi na interfejsie VPN wg0, aby wyglądało, jakby pochodził bezpośrednio z publicznego adresu IPv4 serwera WireGuard.
• ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Ta reguła konfiguruje maskarowanie i przepisuje ruch IPv6, który przychodzi na interfejs VPN wg0, tak aby wyglądał, jakby pochodził bezpośrednio z publicznego adresu IPv6 serwera WireGuard.

Reguły PreDown uruchamiają się, gdy serwer WireGuard zatrzymuje wirtualny tunel VPN. Są one odwrotnością reguł PostUp i służą do cofania reguł przekierowywania i maskowania dla interfejsu VPN, gdy VPN jest zatrzymany.

W obu przypadkach edytuj konfigurację, aby uwzględnić lub wykluczyć reguły IPv4 i IPv6 odpowiednie dla Twojego VPN. Na przykład, jeśli używasz tylko IPv4, możesz pominąć linie z poleceniami ip6tables.

Natomiast, jeśli używasz tylko IPv6, edytuj konfigurację, aby uwzględniała jedynie polecenia ip6tables. Linie ufw powinny istnieć dla dowolnej kombinacji sieci IPv4 i IPv6. Zapisz i zamknij plik po zakończeniu.

Ostatnia część konfigurowania zapory sieciowej na serwerze WireGuard polega na zezwoleniu na ruch do i z samego portu UDP WireGuard. Jeśli nie zmieniłeś portu w pliku /etc/wireguard/wg0.conf serwera, port, który otworzysz, to 51820. Jeśli wybrałeś inny port podczas edytowania konfiguracji, upewnij się, że zastąpisz go w następującym poleceniu UFW.

Jeśli zapomniałeś otworzyć port SSH podczas wykonywania wcześniejszego poradnika, dodaj go tutaj również:

sudo ufw allow 51820/udp

sudo ufw allow OpenSSH

Po dodaniu tych reguł, wyłącz i ponownie włącz UFW, aby go zrestartować i wczytać zmiany ze wszystkich zmodyfikowanych plików:

sudo ufw disable

sudo ufw enable

Możesz potwierdzić, że zasady zostały wprowadzone, uruchamiając polecenie ufw status. Wykonaj je, a powinieneś otrzymać wynik podobny do poniższego:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
51820/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

Twój serwer WireGuard jest teraz skonfigurowany do prawidłowego obsługiwania ruchu VPN, w tym przekazywania i maskowania dla połączeń. Po zastosowaniu reguł zapory sieciowej możesz uruchomić samą usługę WireGuard, aby nasłuchiwała połączeń ze stronami.

Krok 6 — Uruchamianie serwera WireGuard

WireGuard można skonfigurować tak, aby działał jako usługa systemd przy użyciu wbudowanego skryptu wg-quick. Chociaż można ręcznie używać polecenia wg, aby za każdym razem tworzyć tunel przy korzystaniu z VPN, jest to proces ręczny, który staje się powtarzalny i podatny na błędy. Zamiast tego można użyć systemctl, aby zarządzać tunelem przy pomocy skryptu wg-quick.

Używanie usługi systemd oznacza, że możesz skonfigurować WireGuard tak, aby uruchamiał się podczas startu systemu, dzięki czemu będziesz mógł połączyć się z VPN w dowolnym momencie, o ile serwer działa. Aby to zrobić, włącz usługę wg-quick dla tunelu wg0, który zdefiniowałeś, dodając ją do systemctl:

sudo systemctl enable wg-quick@wg0.service

Teraz uruchom usługę:

sudo systemctl start wg-quick@wg0.service

Sprawdź dwukrotnie, czy usługa WireGuard jest aktywna za pomocą następującego polecenia. Powinieneś zobaczyć, że usługa jest wymieniona jako aktywna. Zwróć uwagę, że wg-quick kończy działanie po skonfigurowaniu interfejsu, więc active (exited) jest normalne.

sudo systemctl status wg-quick@wg0.service

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2021-08-25 15:24:14 UTC; 5s ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 3245 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 3245 (code=exited, status=0/SUCCESS)

Aug 25 15:24:14 wg0 wg-quick[3245]: [#] wg setconf wg0 /dev/fd/63
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -6 address add fd0d:86fa:c3bc::1/64 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip link set mtu 1420 up dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ufw route allow in on wg0 out on eth0
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added (v6)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

Wynik pokazuje polecenia ip, które są używane do utworzenia wirtualnego urządzenia wg0 oraz przypisania mu adresów IPv4 i IPv6, które dodałeś do pliku konfiguracyjnego. Możesz użyć tych reguł do rozwiązywania problemów z tunelem lub bezpośrednio z poleceniem wg, jeśli chcesz spróbować ręcznie skonfigurować interfejs VPN.

Po skonfigurowaniu i uruchomieniu serwera, kolejnym krokiem jest skonfigurowanie swojej maszyny klienckiej jako peer WireGuard i połączenie się z serwerem WireGuard.

Krok 7 — Konfigurowanie klienta WireGuard

Konfigurowanie klienta WireGuard jest podobne do konfigurowania serwera WireGuard. Po zainstalowaniu oprogramowania klienta wygenerujesz parę kluczy publiczny/prywatny, wybierzesz adres IP lub adresy dla klienta, zdefiniujesz plik konfiguracyjny dla klienta, a następnie uruchomisz tunel za pomocą skryptu wg-quick.

Możesz dodać do swojej sieci VPN dowolną liczbę peerów, generując parę kluczy i konfigurację za pomocą poniższych kroków. Jeśli dodasz wielu peerów do VPN, pamiętaj, aby śledzić ich prywatne adresy IP, aby uniknąć konfliktów.

Aby skonfigurować Peer WireGuard, upewnij się, że masz zainstalowany pakiet WireGuard, używając następujących poleceń apt. Na Peers WireGuard uruchom:

sudo apt update

sudo apt install wireguard

Tworzenie pary kluczy peer-a WireGuard

Następnie będziesz musiał wygenerować parę kluczy na węźle (peer) używając tych samych kroków, które zastosowałeś na serwerze. Na swoim lokalnym komputerze lub zdalnym serwerze, który będzie pełnił rolę węzła, przejdź dalej i utwórz klucz prywatny dla węzła, używając następujących poleceń:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

Ponownie otrzymasz pojedynczą linię wyjściową zakodowaną w formacie base64, która jest kluczem prywatnym. Kopia wyjścia jest również przechowywana w /etc/wireguard/private.key. Starannie zanotuj wyświetlony klucz prywatny, ponieważ będziesz musiał dodać go do pliku konfiguracyjnego WireGuard w dalszej części tego rozdziału.

Następnie użyj następującego polecenia, aby utworzyć plik klucza publicznego:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Otrzymasz ponownie pojedynczą linię zakodowanego w base64 wyjścia, które jest kluczem publicznym dla Twojego Peera WireGuard. Skopiuj go w jakieś miejsce do celów referencyjnych, ponieważ będziesz musiał przekazać klucz publiczny do serwera WireGuard, aby nawiązać zaszyfrowane połączenie.

Tworzenie pliku konfiguracyjnego peer’a WireGuard

Teraz, gdy masz parę kluczy, możesz utworzyć plik konfiguracyjny dla węzła, który zawiera wszystkie informacje potrzebne do nawiązania połączenia z serwerem WireGuard.

Będziesz potrzebować kilku informacji do pliku konfiguracyjnego:

• Zakodowany w formacie base64 klucz prywatny, który wygenerowałeś na węźle.
• Zakresy adresów IPv4 i IPv6, które zdefiniowałeś na serwerze WireGuard.
• Zakodowany w base64 klucz publiczny z serwera WireGuard.
• Publiczny adres IP i numer portu serwera WireGuard. Zazwyczaj będzie to adres IPv4, ale jeśli Twój serwer ma adres IPv6, a Twoja maszyna kliencka ma połączenie z internetem przez IPv6, możesz go użyć zamiast IPv4.

Mając wszystkie te informacje pod ręką, otwórz nowy plik /etc/wireguard/wg0.conf na maszynie WireGuard Peer za pomocą nano lub wybranego edytora:

sudo nano /etc/wireguard/wg0.conf

Dodaj następujące linie do pliku, podstawiając odpowiednie dane w wyróżnionych sekcjach według potrzeb:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd0d:86fa:c3bc::2/64

[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd0d:86fa:c3bc::/64
Endpoint = 203.0.113.1:51820

Zwróć uwagę, że pierwsza linia Address używa adresu IPv4 z podsieci 10.8.0.0/24, którą wybrałeś wcześniej. Ten adres IP może być dowolny w tej podsieci, pod warunkiem że różni się od adresu IP serwera. Zwykle najłatwiej jest przydzielać adresy, zwiększając je o 1 za każdym razem, gdy dodajesz nowego klienta.

Zwróć również uwagę, jak druga linia Address używa adresu IPv6 z podsieci, którą wygenerowałeś wcześniej, i zwiększa adres serwera o jeden. Ponownie, każdy adres IP z tego zakresu jest prawidłowy, jeśli zdecydujesz się użyć innego adresu.

Inną istotną częścią pliku jest ostatnia linia AllowedIPs. Te dwa zakresy IPv4 i IPv6 informują peer, aby wysyłał ruch przez VPN tylko wtedy, gdy system docelowy ma adres IP w jednym z tych zakresów. Korzystając z dyrektywy AllowedIPs, możesz ograniczyć VPN na peerze, aby łączył się tylko z innymi peerami i usługami w sieci VPN, lub możesz skonfigurować ustawienie tak, aby cały ruch był tunelowany przez VPN i używał serwera WireGuard jako bramy.

Jeśli używasz tylko IPv4, pomiń końcowy zakres fd0d:86fa:c3bc::/64 (łącznie z przecinkiem ,). Natomiast jeśli używasz tylko IPv6, uwzględnij tylko prefiks fd0d:86fa:c3bc::/64 i pomiń zakres IPv4 10.8.0.0/24.

W obu przypadkach, jeśli chcesz przekierować cały ruch swojego partnera przez VPN i używać serwera WireGuard jako bramy dla całego ruchu, możesz użyć 0.0.0.0/0, co oznacza całą przestrzeń adresów IPv4, oraz ::/0 dla całej przestrzeni adresów IPv6.

(Opcjonalnie) Konfigurowanie Peera do przesyłania całego ruchu przez tunel

Jeżeli zdecydowałeś się przekierować cały ruch z węzła przez tunel, używając tras 0.0.0.0/0 lub ::/0, a węzeł to system zdalny, będziesz musiał wykonać kroki opisane w tej sekcji. Jeśli Twój węzeł to system lokalny, najlepiej pominąć tę sekcję.

Dla zdalnych węzłów, do których uzyskujesz dostęp za pomocą SSH lub innego protokołu używając publicznego adresu IP, będziesz musiał dodać kilka dodatkowych reguł do pliku wg0.conf węzła. Te reguły zapewnią, że nadal będziesz mógł łączyć się z systemem spoza tunelu, gdy jest on połączony. W przeciwnym razie, gdy tunel zostanie ustanowiony, cały ruch, który normalnie byłby obsługiwany przez publiczny interfejs sieciowy, nie będzie poprawnie kierowany, aby ominąć interfejs tunelu wg0, co spowoduje niedostępność zdalnego systemu.

Najpierw musisz określić adres IP, który system używa jako swoją domyślną bramę. Uruchom następujące polecenie ip route:

ip route list table main default

Otrzymasz wynik podobny do poniższego:

default via 203.0.113.1 dev eth0 proto static

Zanotuj wyróżniony adres IP bramy 203.0.113.1 do późniejszego użycia oraz urządzenie eth0. Nazwa twojego urządzenia może być inna. Jeśli tak jest, zastąp ją w miejsce eth0 w poniższych poleceniach.

Następnie znajdź publiczny adres IP systemu, sprawdzając urządzenie za pomocą polecenia ip address show:

ip -brief address show eth0

Otrzymasz wynik podobny do poniższego:

eth0             UP             203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64

W tym przykładzie wyjścia, wyróżniony adres IP 203.0.113.5 (bez końcowego /20) jest publicznym adresem przypisanym do urządzenia eth0, który będziesz musiał dodać do konfiguracji WireGuard.

Teraz otwórz plik /etc/wireguard/wg0.conf klienta WireGuard za pomocą nano lub innego ulubionego edytora.

sudo nano /etc/wireguard/wg0.conf

Przed linią [Peer] dodaj następujące 4 linie:

PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1

[Peer]
. . .

Te linie utworzą niestandardową regułę routingu i dodadzą niestandardową trasę, aby zapewnić, że ruch publiczny do systemu korzysta z domyślnej bramy.

• PostUp=ip rule add table 200 from 203.0.113.5 - To polecenie tworzy regułę, która sprawdza wszelkie wpisy tras w tabeli o numerze 200, gdy adres IP pasuje do publicznego adresu systemu 203.0.113.5.
• PostUp=ip route add table 200 default via 203.0.113.1 - To polecenie zapewnia, że cały ruch przetwarzany przez tabelę 200 będzie korzystał z bramy 203.0.113.1 do routingu, zamiast z interfejsu WireGuard.

Linie PreDown usuwają niestandardową regułę i trasę, gdy tunel zostaje zamknięty.

Jeśli przesyłasz cały ruch partnera przez VPN, upewnij się, że skonfigurowałeś poprawne reguły sysctl i iptables na serwerze WireGuard w sekcjach Dostosowywanie konfiguracji sieciowej serwera WireGuard oraz Konfigurowanie zapory serwera WireGuard.

(Opcjonalnie) Konfigurowanie serwerów DNS peer-a WireGuard

Jeśli używasz serwera WireGuard jako bramy VPN dla całego ruchu swoich peerów, będziesz musiał dodać linię do sekcji [Interface], która określa serwery DNS. Jeśli nie dodasz tego ustawienia, Twoje zapytania DNS mogą nie być zabezpieczone przez VPN lub mogą zostać ujawnione dostawcy usług internetowych lub innym osobom trzecim.

Jeśli używasz WireGuard tylko do dostępu do zasobów w sieci VPN lub w konfiguracji peer-to-peer, możesz pominąć tę sekcję.

Aby dodać resolver DNS do konfiguracji twojego peera, najpierw określ, których serwerów DNS używa twój Serwer WireGuard. Uruchom następujące polecenie na Serwerze WireGuard, zastępując nazwę urządzenia ethernet w miejsce eth0, jeśli różni się od tego przykładu:

resolvectl dns eth0

Powinieneś otrzymać wynik podobny do następującego:

Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888

Adresy IP, które są wyświetlane, to serwery DNS, z których korzysta serwer. Możesz wybrać dowolne lub wszystkie z nich, albo tylko IPv4 lub IPv6 w zależności od swoich potrzeb. Zrób notatkę z serwerów DNS, których będziesz używać.

Następnie będziesz musiał dodać wybrane przez siebie serwery DNS do pliku konfiguracyjnego Peer’a WireGuard. Wróć na Peer WireGuard i otwórz plik /etc/wireguard/wg0.conf za pomocą nano lub wybranego edytora:

sudo nano /etc/wireguard/wg0.conf

Przed linią [Peer] dodaj następujące:

DNS = 67.207.67.2 2001:4860:4860::8844

[Peer]
. . .

Ponownie, w zależności od Twoich preferencji lub wymagań dotyczących IPv4 i IPv6, możesz edytować listę zgodnie z potrzebami.

Global: 67.207.67.2 67.207.67.3
. . .

Mając wszystkie te ustawienia rozwiązywania DNS, możesz teraz dodać klucz publiczny partnera do serwera, a następnie uruchomić tunel WireGuard na partnerze.

Krok 8 — Dodawanie klucza publicznego uczestnika do serwera WireGuard

Przed podłączeniem klienta do serwera ważne jest dodanie jego klucza publicznego do serwera WireGuard. Ten krok zapewnia możliwość połączenia się i przesyłania ruchu przez VPN. Bez wykonania tego kroku serwer WireGuard nie pozwoli klientowi na wysyłanie ani odbieranie ruchu przez tunel.

Upewnij się, że masz kopię klucza publicznego Peer WireGuard zakodowanego w base64, uruchamiając:

sudo cat /etc/wireguard/public.key

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

Teraz zaloguj się na serwer WireGuard i wykonaj następujące polecenie:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd0d:86fa:c3bc::2

Zwróć uwagę, że część polecenia allowed-ips przyjmuje listę adresów IPv4 i IPv6 oddzielonych przecinkami. Możesz określić pojedyncze adresy IP, jeśli chcesz ograniczyć adres IP, który peer może przypisać sobie samodzielnie, lub przedział, jak w przykładzie, jeśli Twoi peerzy mogą używać dowolnego adresu IP w zakresie VPN. Zwróć również uwagę, że żaden z peerów nie może mieć tego samego ustawienia allowed-ips.

Jeżeli chcesz zaktualizować allowed-ips dla istniejącego węzła, możesz ponownie wykonać tę samą komendę, ale zmienić adresy IP. Wspieranych jest kilka adresów IP. Na przykład, aby zmienić węzeł WireGuard, który właśnie dodałeś, dodając IP takie jak 10.8.0.100 do istniejących adresów 10.8.0.2 i fd0d:86fa:c3bc::2, wykonaj następujące polecenie:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd0d:86fa:c3bc::2

Gdy już uruchomisz polecenie dodające partnera, sprawdź status tunelu na serwerze, używając polecenia wg:

sudo wg

interface: wg0
 public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 private key: (hidden)
 listening port: 51820

peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 allowed ips: 10.8.0.2/32, fd0d:86fa:c3bc::/128

Zwróć uwagę, jak linia peer pokazuje klucz publiczny Peer w WireGuard oraz adresy IP lub zakresy adresów, które może wykorzystać do przypisania sobie adresu IP.

Teraz, gdy zdefiniowałeś parametry połączenia współpracownika na serwerze, następnym krokiem jest uruchomienie tunelu u tego współpracownika.

Krok 9 — Podłączanie klienta WireGuard do tunelu

Teraz, gdy Twój serwer i peer są skonfigurowane, aby obsługiwać wybrany przez Ciebie protokół IPv4, IPv6, przesyłanie pakietów i rozwiązywanie DNS, nadszedł czas, aby połączyć peera z tunelem VPN.

Ponieważ możesz chcieć, aby VPN był włączony tylko w określonych przypadkach, użyjemy polecenia wg-quick, aby ręcznie nawiązać połączenie. Jeśli chcesz zautomatyzować uruchamianie tunelu tak jak robiłeś to na serwerze, postępuj według tych kroków w sekcji Uruchamianie serwera WireGuard zamiast używać polecenia wg-quick.

Jeśli kierujesz cały ruch przez VPN i skonfigurowałeś przekazywanie DNS, będziesz musiał zainstalować narzędzie resolvconf na Peerze WireGuard, zanim uruchomisz tunel. Uruchom następujące polecenie, aby to skonfigurować:

sudo apt install resolvconf

Aby uruchomić tunel, uruchom następujące polecenie na peeringu WireGuard:

sudo wg-quick up wg0

Otrzymasz wynik podobny do poniższego:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x

Zwróć uwagę na wyróżnione adresy IPv4 i IPv6, które przypisałeś do peer'a.

Jeśli ustawisz AllowedIPs na peera na 0.0.0.0/0 i ::/0 (lub użyjesz zakresów innych niż te, które wybrałeś dla VPN), to Twój wynik będzie wyglądał następująco:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

W tym przykładzie zwróć uwagę na podświetlone trasy, które dodało polecenie, a które odpowiadają AllowedIPs w konfiguracji peer.

Możesz sprawdzić status tunelu na hoście zdalnym za pomocą polecenia wg:

sudo wg

interface: wg0
 public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 private key: (hidden)
 listening port: 49338
 fwmark: 0xca6c

peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 endpoint: 203.0.113.1:51820
 allowed ips: 10.8.0.0/24, fd0d:86fa:c3bc::/64
 latest handshake: 1 second ago
 transfer: 6.50 KiB received, 15.41 KiB sent

Możesz również ponownie sprawdzić status na serwerze, a otrzymasz podobny wynik.

Sprawdź, czy twój partner korzysta z VPN, używając poleceń ip route i ip -6 route. Jeśli używasz VPN jako bramy dla całego ruchu internetowego, sprawdź, który interfejs będzie używany do ruchu skierowanego do serwerów DNS CloudFlare 1.1.1.1 i 2606:4700:4700::1111.

ip route get 1.1.1.1

1.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
   cache

Zwróć uwagę, że używane jest urządzenie wg0 oraz adres IPv4 10.8.0.2, który przypisałeś do węzła. Podobnie, jeśli używasz IPv6, uruchom następujące polecenie:

ip -6 route get 2606:4700:4700::1111

2606:4700:4700::1111 from :: dev wg0 table 51820 src fd0d:86fa:c3bc::2 metric 1024 pref medium

Zwróć ponownie uwagę na interfejs wg0 oraz adres IPv6 fd0d:86fa:c3bc::2, który przypisałeś do peera.

Jeśli Twój rówieśnik ma zainstalowaną przeglądarkę, możesz również odwiedzić ipleak.net i ipv6-test.com, aby potwierdzić, że Twój rówieśnik przekierowuje swój ruch przez VPN.

Gdy będziesz gotowy, aby rozłączyć VPN na urządzeniu zdalnym, użyj polecenia wg-quick:

sudo wg-quick down wg0

Otrzymasz wynik podobny do poniższego, wskazujący, że tunel VPN został zamknięty:

[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f

Jeśli ustawisz AllowedIPs na peera na 0.0.0.0/0 i ::/0 (lub użyjesz innych zakresów niż te, które wybrałeś dla VPN), to Twój wynik będzie wyglądał następująco:

[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

Aby ponownie połączyć się z VPN, uruchom ponownie polecenie wg-quick up wg0 na węźle. Jeśli chcesz całkowicie usunąć konfigurację węzła z serwera WireGuard, możesz wykonać następujące polecenie, pamiętając o zastąpieniu odpowiednim kluczem publicznym węzła, który chcesz usunąć:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

Zazwyczaj należy usunąć konfigurację peer tylko wtedy, gdy peer już nie istnieje lub gdy jego klucze szyfrowania zostały naruszone lub zmienione. W przeciwnym razie lepiej pozostawić konfigurację, aby peer mógł ponownie połączyć się z VPN bez konieczności każdorazowego dodawania jego klucza i allowed-ips.

Zarządzanie i rotacja kluczy WireGuard

WireGuard opiera się na statycznych parach kluczy publicznych i prywatnych do uwierzytelniania i szyfrowania. Ten projekt znacząco zmniejsza złożoność konfiguracji, ale jednocześnie przenosi odpowiedzialność za zarządzanie kluczami całkowicie na administratora. W przypadku długotrwałych wdrożeń VPN, współdzielonej infrastruktury lub środowisk z wieloma węzłami, ostrożne zarządzanie kluczami jest niezbędne dla utrzymania bezpieczeństwa i stabilności operacyjnej.

Zrozumienie typów kluczy WireGuard

Każdy uczestnik WireGuard używa dwóch rodzajów kluczy kryptograficznych.

• Długoterminowe klucze prywatne: Klucz prywatny jednoznacznie identyfikuje uczestnika i musi pozostawać poufny przez cały czas. Klucz ten jest używany podczas szyfrowanych powitań (handshake) do uwierzytelniania uczestnika i generowania krótkotrwałych kluczy sesyjnych. Jeśli klucz prywatny zostanie ujawniony, każdy system posiadający ten klucz może podszywać się pod uczestnika.

• Długoterminowe klucze publiczne: Klucz publiczny jest wyprowadzany z klucza prywatnego i udostępniany innym uczestnikom sieci. Na centralnym węźle klucze publiczne określają, które uczestnicy mogą się komunikować i z jakich adresów IP mogą korzystać.

Oprócz tych długoterminowych kluczy, WireGuard automatycznie generuje efemeryczne klucze sesyjne podczas szyfrowanych wymian. Klucze sesyjne są okresowo rotowane i zapewniają tzw. Perfect Forward Secrecy bez udziału administratora.

Zalecane praktyki zarządzania kluczami

Następujące praktyki pomagają zmniejszyć ryzyko i uprościć bieżące operacje:

• Przypisz unikalną parę kluczy do każdego uczestnika: Każde urządzenie powinno mieć swoją własną prywatną i publiczną parę kluczy. Używanie unikalnych kluczy pozwala na cofnięcie dostępu dla pojedynczego urządzenia bez wpływu na pozostałe. Ponowne używanie kluczy w wielu systemach zwiększa skutki kompromitacji i utrudnia audyt.

• Ogranicz dostęp do materiału klucza prywatnego: Pliki klucza prywatnego powinny być czytelne tylko dla użytkownika root. W systemach Linux zazwyczaj oznacza to ustawienie uprawnień na 600 za pomocą polecenia takiego jak chmod 600 /etc/wireguard/private.key. Ograniczenie dostępu do plików pomaga zapobiegać przypadkowemu ujawnieniu poprzez kopie zapasowe, logi lub użytkowników bez odpowiednich uprawnień.

• Utrzymuj jawny rejestr peerów: Prowadź zapis, który przypisuje każdy klucz publiczny peerów do nazwy urządzenia, przypisanych adresów IPv4 i IPv6 oraz przeznaczenia. Ta dokumentacja staje się coraz ważniejsza wraz ze wzrostem liczby peerów i ułatwia rozwiązywanie problemów, audyty oraz rutynową konserwację.

• Niezwłocznie usuń nieużywanych lub nieaktywnych uczestników: Gdy urządzenie zostaje wycofane z eksploatacji lub nie wymaga już dostępu do VPN, usuń jego klucz publiczny z centralnej konfiguracji uczestników. Pozostawienie nieużywanych kluczy zwiększa powierzchnię ataku i utrudnia przyszłe przeglądy.

Sytuacje, które wymagają rotacji kluczy

Rotacja kluczy powinna być przeprowadzana w kilku typowych scenariuszach:

• Podejrzenie lub potwierdzenie ujawnienia klucza: Jeśli ktoś mógł skopiować, wyciec lub uzyskać dostęp do prywatnego klucza bez uprawnienia, należy go natychmiast wymienić, aby zapobiec podszywaniu się.

• Utracone lub skradzione urządzenia: Gdy urządzenie zostanie zgubione lub skradzione, zmiana jego kluczy zapewnia, że nie będzie mogło już łączyć się z VPN, nawet jeśli pierwotna konfiguracja zostanie odzyskana.

• Wymagania dotyczące bezpieczeństwa organizacyjnego: Niektóre środowiska wymagają okresowej rotacji kluczy, aby spełnić wewnętrzne polityki lub normy zgodności, nawet jeśli nie podejrzewa się żadnego naruszenia.

• Zmiany w posiadaniu lub roli urządzenia: Gdy urządzenie zostaje przypisane do innego użytkownika lub celu, rotacja jego kluczy zapobiega niezamierzonemu dalszemu dostępowi.

Bezpieczna rotacja kluczy współpracownika

WireGuard mapuje wewnętrzne adresy IP do konkretnych kluczy publicznych przy użyciu tablicy routingu kluczy kryptograficznych. Z powodu tego projektu ten sam wewnętrzny adres IP nie może być bezpiecznie przypisany do dwóch kluczy publicznych w tym samym czasie. Rotacja kluczy zazwyczaj wiąże się więc z krótką przerwą w łączności podczas aktualizacji konfiguracji.

Aby zmienić klucze partnera, postępuj zgodnie z tym procesem:

1. Wygeneruj nową parę kluczy prywatnych i publicznych na węźle.
2. Zaktualizuj konfigurację centralnego węzła, aby zastąpić stary klucz publiczny nowym, zachowując te same wartości AllowedIPs. Nie restartuj jeszcze interfejsu.
3. Zaktualizuj plik konfiguracyjny partnera, aby używał nowego prywatnego klucza.
4. Zastosuj zaktualizowaną konfigurację na centralnym węźle, na przykład przeładowując usługę WireGuard lub używając wg syncconf. W tym momencie węzeł tymczasowo straci łączność.
5. Zrestartuj interfejs WireGuard na węźle, aby zaczął używać nowego klucza prywatnego.
6. Sprawdź, czy nowe uzgadnianie połączenia zostaje zakończone i czy ruch sieciowy przebiega prawidłowo.
7. Usuń wszelkie pozostałe odniesienia do starego klucza, jeśli nadal istnieją.

To podejście oparte na wymianie odzwierciedla sposób, w jaki WireGuard egzekwuje kryptograficzne trasowanie i unika niejednoznacznych lub sprzecznych konfiguracji.

Rotacja kluczy na centralnym węźle

Zmiana klucza prywatnego centralnego węzła wpływa na wszystkie podłączone węzły. Konfiguracja każdego węzła musi zostać zaktualizowana o nowy klucz publiczny, zanim połączenie zostanie przywrócone.

Ponieważ ta zmiana wpływa na każdego uczestnika jednocześnie, rotacja klucza centralnego powinna być starannie zaplanowana i przeprowadzona w czasie okna serwisowego. W praktyce klucze centralne są rotowane rzadziej niż klucze uczestników.

Zarządzanie wstępnie udostępnionymi kluczami (opcjonalne)

Oprócz par kluczy publicznego i prywatnego, WireGuard obsługuje opcjonalny wstępnie udostępniony klucz (PSK) dla każdego węzła. PSK dodaje dodatkową warstwę szyfrowania symetrycznego oprócz istniejącej kryptografii WireGuarda.

Klucze wstępnie udostępnione (Pre-Shared Keys) są powszechnie używane w środowiskach o wysokim poziomie bezpieczeństwa jako ochrona przed przyszłymi postępami w kryptografii. Jeśli zaszyfrowany ruch zostanie zarejestrowany dzisiaj, a w przyszłości podstawowy algorytm klucza publicznego zostanie złamany, PSK nadal uniemożliwi odszyfrowanie wcześniejszych sesji.

Jeśli używane są PSK, powinny być traktowane jako poufne tajemnice i okresowo wymieniane. Wymiana PSK przebiega według tego samego schematu operacyjnego co wymiana kluczy partnerów i musi być skoordynowana po obu stronach połączenia.

Wybór częstotliwości rotacji

WireGuard nie narzuca stałego harmonogramu rotacji kluczy. Odpowiednie odstępy rotacji zależą od środowiska.

• Osobiste lub krótkotrwałe wdrożenia mogą nie wymagać zaplanowanej rotacji.
• Środowiska współdzielone lub produkcyjne zazwyczaj rotują klucze co 6 do 12 miesięcy.
• Środowiska o wysokim poziomie bezpieczeństwa mogą wymagać częstszej rotacji zgodnie z polityką.

Regularna rotacja zmniejsza ryzyko związane z długożyjącymi poświadczeniami i dostosowuje wdrożenia WireGuard do powszechnych praktyk bezpieczeństwa.

WireGuard vs OpenVPN: Różnice praktyczne

WireGuard i OpenVPN to powszechnie używane technologie VPN, ale stosują bardzo różne podejścia do szyfrowania, konfiguracji i zachowania sieci. Zrozumienie tych różnic pomaga deweloperom wybrać rozwiązanie, które najlepiej odpowiada ich ograniczeniom operacyjnym.

Konfiguracja i model operacyjny

WireGuard używa statycznego modelu konfiguracji opartego na parach kluczy publicznych i prywatnych. Wszyscy uczestnicy są zdefiniowani w sposób jawny, a zachowanie trasowania jest kontrolowane przez stałe wartości konfiguracyjne. Nie ma kanału kontrolnego, urzędu certyfikacji ani dynamicznego negocjowania parametrów.

OpenVPN opiera się na TLS i certyfikatach X.509. Wykorzystuje kanał sterujący do uwierzytelniania klientów, negocjowania ustawień szyfrowania i zarządzania sesjami. Ten model zapewnia elastyczność, ale zwiększa złożoność konfiguracji i obsługi.

W praktyce konfiguracje WireGuard są krótsze, łatwiejsze do audytu i mniej podatne na subtelne błędy konfiguracyjne. Konfiguracje OpenVPN oferują większą kontrolę, ale wymagają starannego zarządzania, aby pozostały bezpieczne i spójne.

Kryptografia i projektowanie systemów bezpieczeństwa

WireGuard używa stałego zestawu nowoczesnych metod kryptograficznych. Te wybory nie są konfigurowalne. Takie rozwiązanie eliminuje ataki typu downgrade na kryptografię i usuwa konieczność wybierania zestawów szyfrów.

OpenVPN obsługuje szeroką gamę algorytmów szyfrowania i metod uwierzytelniania. Choć ta elastyczność pozwala na zgodność z systemami starszej generacji, zwiększa również ryzyko słabych lub niespójnych konfiguracji.

Oba rozwiązania obsługują Perfect Forward Secrecy. WireGuard automatycznie wykonuje rotację kluczy poprzez mechanizm handshake, podczas gdy OpenVPN opiera się na zachowaniu sesji TLS.

Charakterystyka wydajności

WireGuard został zaprojektowany z myślą o wysokiej wydajności i niskim opóźnieniu. Działa w jądrze Linuksa i ma niewielką bazę kodu, co zmniejsza narzut i przełączanie kontekstu. W większości środowisk WireGuard zapewnia większą przepustowość i bardziej spójne opóźnienia przy minimalnej konfiguracji.

Historycznie, OpenVPN działa w przestrzeni użytkownika i wiąże się z dodatkowymi narzutami wynikającymi z przełączania kontekstu i obsługi protokołu. Nowoczesne wersje OpenVPN obsługują Kernel Data Channel Offload (DCO), co znacznie poprawia wydajność, lecz ta funkcja nie zawsze jest włączona ani dostępna w domyślnych wdrożeniach.

Nawet przy DCO, WireGuard zazwyczaj osiąga wysoką wydajność przy mniejszej liczbie zmiennych konfiguracyjnych.

Roaming sieciowy i obchodzenie zapory

WireGuard radzi sobie ze zmianami sieci w sposób płynny. Jeśli adres IP węzła się zmieni, na przykład przy przełączaniu się między WiFi a sieciami mobilnymi, tunel nadal działa bez potrzeby ponownej negocjacji.

Jednak WireGuard działa wyłącznie przez UDP. Chociaż UDP jest wydajne, czasami bywa blokowane w restrykcyjnych sieciach publicznych WiFi, w zaporach korporacyjnych lub w sieciach instytucjonalnych. WireGuard nie ma natywnej metody awaryjnej, gdy ruch UDP jest blokowany.

OpenVPN obsługuje zarówno UDP, jak i TCP. Gdy UDP jest niedostępne, OpenVPN może zostać skonfigurowany do działania przez port TCP 443, co sprawia, że ruch VPN wygląda podobnie do standardowego ruchu HTTPS. Ta funkcja sprawia, że OpenVPN jest bardziej niezawodny w środowiskach z rygorystycznymi zasadami zapory sieciowej lub cenzurą.

Dla użytkowników działających za restrykcyjnymi sieciami wsparcie TCP często jest decydującym czynnikiem przy wyborze OpenVPN zamiast WireGuard.

Zakres funkcji i rozszerzalność

OpenVPN zawiera funkcje, których WireGuard celowo nie zapewnia. Należą do nich uwierzytelnianie oparte na użytkownikach, dynamiczne przydzielanie adresów oraz integracja z zewnętrznymi systemami tożsamości.

WireGuard koncentruje się wyłącznie na bezpiecznym tunelowaniu. Procesy uwierzytelniania, kontrola dostępu i dynamiczna konfiguracja muszą być obsługiwane poza protokołem.

To sprawia, że OpenVPN lepiej nadaje się do środowisk wymagających skomplikowanej autoryzacji lub scentralizowanego zarządzania użytkownikami, podczas gdy WireGuard jest lepiej przystosowany do VPN-ów na poziomie infrastruktury i dostępu opartego na równorzędnych węzłach.

Porównanie podsumowujące

Wybór między WireGuard a OpenVPN

WireGuard jest dobrze przystosowany do infrastruktury VPN, tuneli międzylokacyjnych, klientów mobilnych oraz środowisk, w których priorytetem są prostota, wydajność i przewidywalność.

OpenVPN pozostaje dobrym wyborem dla środowisk korporacyjnych, które wymagają tunelowania opartego na TCP, zaawansowanej autoryzacji lub niezawodnej pracy za restrykcyjnymi zaporami sieciowymi.

W wielu nowoczesnych wdrożeniach WireGuard zastępuje OpenVPN nie dlatego, że oferuje więcej funkcji, lecz dlatego, że oferuje mniej funkcji, ale o bardziej przejrzystym działaniu.

Dostrajanie i optymalizacja wydajności

WireGuard działa dobrze przy ustawieniach domyślnych, ale rzeczywiste warunki sieciowe mogą wpływać na niezawodność i przepustowość. Czynniki takie jak rozmiar pakietu, zakres routingu, zachowanie NAT i rozwiązywanie DNS mają wpływ na to, jak tunel zachowuje się podczas ciągłego lub przerywanego użytkowania.

Przyjrzyjmy się najczęstszym obszarom strojenia i sytuacjom, w których odpowiednie są korekty.

Wybór MTU i fragmentacja pakietów

Maksymalna jednostka transmisji (MTU) określa największy rozmiar pakietu, który może być przesłany bez fragmentacji. WireGuard szyfruje i enkapsuluje pakiety, co zmniejsza efektywną wartość MTU w porównaniu do fizycznego interfejsu sieciowego.

Domyślnie WireGuard używa MTU o wartości 1420. Ta wartość uwzględnia łączny narzut nagłówków IPv6, UDP oraz enkapsulacji WireGuard i sprawdza się w większości sieci opartych na Ethernet. Niektóre środowiska wymagają mniejszego MTU. Jest to częste w sieciach mobilnych, połączeniach PPPoE oraz na platformach chmurowych z dodatkowymi warstwami enkapsulacji. Gdy MTU jest zbyt duże, pakiety mogą być odrzucane lub fragmentowane. Często skutkuje to tym, że połączenia działają dla małych żądań, ale zatrzymują się lub nie powiodą przy większych transferach. W przypadku wystąpienia tych objawów zaleca się stopniowe obniżanie MTU. Wartości takie jak 1360, a w bardziej restrykcyjnych środowiskach 1280 – czyli minimalne MTU dla IPv6 – często rozwiązują te problemy przy minimalnym wpływie na przepustowość.

MTU powinno być ustawione jawnie w sekcji [Interface] pliku konfiguracyjnego, aby zapewnić spójne działanie po ponownym uruchomieniu.

Zakres i wpływ AllowedIPs

Dyrektywa AllowedIPs wpływa zarówno na zachowanie trasowania, jak i na wydajność. Szerokie zakresy adresów powodują przechodzenie większego ruchu przez tunel, co zwiększa obciążenie szyfrowaniem i obciążenie serwera. Używanie wąskich wartości AllowedIPs ogranicza tunel tylko do ruchu, który wymaga ochrony. To zmniejsza użycie CPU i unika niepotrzebnej enkapsulacji.

Gdy skonfigurowano 0.0.0.0/0 lub ::/0, cały ruch jest kierowany przez VPN. Ta konfiguracja jest odpowiednia, gdy prywatność, scentralizowana kontrola wychodzącego ruchu lub niezaufane sieci są istotne, ale zwiększa opóźnienia i zużycie zasobów dla ogólnego ruchu internetowego.

Optymalizacja wydajności często polega na zawężeniu AllowedIPs tam, gdzie to możliwe, oraz unikaniu routingu pełnotunelowego, chyba że jest to wymagane.

Przechodzenie przez NAT i stabilność połączenia (PersistentKeepalive)

WireGuard celowo pozostaje cichy, gdy nie przesyłane są żadne dane. Domyślnie nie wysyła okresowych pakietów utrzymujących połączenie (keepalive). W środowiskach korzystających z NAT, takich jak domowe routery, sieci mobilne czy wiele sieci w chmurze, ta cisza może spowodować zamknięcie mapowania połączenia przez urządzenie NAT. Kiedy to się stanie, ruch przychodzący z serwera jest blokowany, aż partner ponownie wyśle dane. To zachowanie często odbierane jest jako opóźnienia, powolne połączenia lub sporadyczne awarie.

Aby temu zapobiec, WireGuard oferuje ustawienie PersistentKeepalive. Opcję tę można dodać do sekcji [Peer] w konfiguracji peer. Spowoduje to, że peer będzie wysyłał mały pakiet utrzymujący połączenie w regularnych odstępach czasu, aby utrzymać otwartą translację NAT. Wartość 25 sekund jest powszechnie stosowana i dobrze działa z większością urządzeń NAT. Jeśli połączenie działa na początku, ale przestaje działać po okresie bezczynności, włączenie PersistentKeepalive=25 jest głównym i zalecanym sposobem naprawy.

Rozwiązywanie DNS i zachowanie tunelu

Konfiguracja DNS ma znaczący wpływ na postrzeganą wydajność VPN. Gdy serwery DNS nie są prawidłowo kierowane przez tunel, aplikacje mogą wydawać się wolne lub zawodnie działać, nawet gdy sam tunel funkcjonuje poprawnie.

W konfiguracjach bramowych zapytania DNS powinny być wysyłane przez VPN, aby zapewnić spójne trasowanie i uniknąć wycieków. Wymaga to jawnego określenia serwerów DNS w konfiguracji peer. Gdy DNS jest źle skonfigurowany, typowe objawy to wolne ładowanie stron, niestabilne połączenie lub ruch kierowany poza VPN mimo aktywnego tunelu.

Wybór resolverów, do których można dotrzeć przez tunel i które odpowiadają szybko, poprawia zarówno niezawodność, jak i komfort korzystania.

Różnice wydajności między IPv4 a IPv6

W środowiskach z podwójnym stosem, IPv4 i IPv6 mogą zachowywać się inaczej. Ścieżki IPv6 mogą mieć różne ograniczenia MTU, polityki routingu lub działanie zapory ogniowej.

Testowanie obu protokołów niezależnie pomaga zidentyfikować problemy specyficzne dla protokołu. Narzędzia takie jak ping, tracepath i ip route get są przydatne do weryfikacji trasowania i zachowania MTU dla każdej rodziny adresów.

Jeśli wydajność IPv6 wydaje się niestabilna, upewnij się, że ruch ICMPv6 jest dozwolony. ICMPv6 jest wymagany do odkrywania MTU ścieżki, a jego blokowanie może powodować zablokowanie połączeń przy większych pakietach.

CPU i narzut szyfrowania

WireGuard używa nowoczesnej kryptografii, która jest wydajna na większości systemów. Jednak szyfrowanie nadal zużywa zasoby procesora.

Na małych maszynach wirtualnych, wbudowanych routerach lub systemach bez sprzętowego przyspieszenia, konfiguracje pełnotunelowe mogą maksymalnie obciążyć procesor przy ciągłym obciążeniu.

Monitorowanie zużycia CPU podczas dużego ruchu pomaga określić, czy problemy z wydajnością są spowodowane obciążeniem wynikającym z szyfrowania, a nie konfiguracją sieci. W takich przypadkach może być konieczne zmniejszenie ruchu przesyłanego przez tunel lub aktualizacja instancji serwera.

Weryfikacja zmian wydajności

Dostosowywanie wydajności powinno być przeprowadzane stopniowo. Po każdej zmianie należy sprawdzić łączność i stabilność, zanim zostaną wprowadzone kolejne poprawki.

Przydatne kroki weryfikacyjne obejmują sprawdzanie stabilności nawiązywania połączenia za pomocą wg, mierzenie opóźnień i przepustowości przed i po zmianach oraz potwierdzanie zachowania trasowania za pomocą ip route i ip -6 route. Takie podejście minimalizuje ryzyko i upraszcza rozwiązywanie problemów.

Najczęściej zadawane pytania

1. Czym jest WireGuard i jak działa na Ubuntu?

WireGuard to nowoczesna technologia VPN zaprojektowana tak, aby była znacznie szybsza i łatwiejsza w konfiguracji niż starsze opcje, takie jak OpenVPN czy IPsec. Można ją traktować jako bezpieczny tunel, który łączy Twoje urządzenia bezpośrednio. W przeciwieństwie do starszych VPN-ów, które są ciężkie i skomplikowane, WireGuard jest wyjątkowo lekki. Na Ubuntu działa poprzez uruchamianie bezpośrednio w jądrze Linuksa – rdzeniu systemu operacyjnego. Ponieważ działa głęboko w systemie, a nie jako osobna aplikacja na wierzchu, zużywa bardzo mało energii baterii i przetwarza dane niesamowicie szybko.

Aby nawiązać połączenie, WireGuard używa metody bardzo podobnej do SSH. Generuje parę „kluczy” dla każdego urządzenia: klucz prywatny (który pozostaje tajny na urządzeniu) oraz klucz publiczny (który udostępniasz innym urządzeniom, z którymi chcesz się połączyć). Połączenie następuje tylko wtedy, gdy klucze idealnie pasują, co sprawia, że proces uzgadniania jest szybki i bezpieczny.

2. Czy WireGuard jest bezpieczniejszy niż OpenVPN?

Dla większości użytkowników WireGuard uważany jest za bezpieczniejszy z powodu swojej prostoty i nowoczesnego projektu. Głównym powodem jest wielkość jego kodu. WireGuard został stworzony przy użyciu zaledwie około 4 000 linii kodu, podczas gdy OpenVPN ma ich ponad 100 000. Ta ogromna różnica sprawia, że ekspertom ds. bezpieczeństwa znacznie łatwiej jest przeanalizować kod WireGuard i znaleźć luki (błędy) zanim zrobią to osoby o złych zamiarach.

WireGuard zmusza również do korzystania z najnowszych, najsilniejszych standardów szyfrowania dostępnych obecnie. Starsze VPN-y pozwalają na elastyczność kryptograficzną, co oznacza, że mogą przełączać się na słabsze metody szyfrowania, aby wspierać starsze urządzenia. WireGuard usuwa tę opcję, uniemożliwiając atakującym oszukanie twojego VPN-u i zmuszenie go do użycia słabszego szyfru. Dodatkowo, WireGuard jest domyślnie niewidoczny; jeśli nieautoryzowane urządzenie wyśle pakiet do twojego serwera, WireGuard po prostu nie odpowie. Sprawia to, że twój serwer staje się niewidoczny dla hakerów skanujących otwarte porty.

3. Czy mogę skonfigurować WireGuard na Ubuntu bez użycia Dockera?

Tak, możesz go łatwo skonfigurować bezpośrednio na systemie bez użycia kontenerów Dockera. W rzeczywistości uruchamianie go bezpośrednio jest często preferowaną metodą na Ubuntu, ponieważ oprogramowanie jest dostępne w standardowych repozytoriach oprogramowania Ubuntu. Zazwyczaj wystarczy wykonać poniższe standardowe polecenia instalacyjne, które pobiorą niezbędne oprogramowanie prosto z oficjalnego źródła Ubuntu.

sudo apt update
sudo apt install wireguard

4. Jak dodać wielu klientów (peerów) WireGuard?

WireGuard wykorzystuje koncepcję peer-to-peer, co oznacza, że każde podłączone urządzenie traktowane jest jako „peer”. Aby dodać wiele urządzeń, takich jak laptop, smartfon czy tablet, wystarczy edytować plik konfiguracyjny serwera (zazwyczaj znajduje się on w /etc/wireguard/wg0.conf).

Dla każdego nowego urządzenia dodajesz nowy blok tekstu oznaczony [Peer]. W tym bloku musisz wkleić Klucz Publiczny danego urządzenia i przypisać mu unikalny wewnętrzny adres IP (na przykład 10.0.0.2 dla pierwszego urządzenia, 10.0.0.3 dla drugiego i tak dalej). Niezwykle ważne jest, aby te wewnętrzne adresy IP się nie pokrywały.

Oto prosty przykładowy blok konfiguracyjny:

[Interface]
# Server settings...
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <Server_Private_Key>

[Peer]
# Client 1 (Laptop)
PublicKey = <Laptop_Public_Key>
AllowedIPs = 10.0.0.2/32

[Peer]
# Client 2 (Phone)
PublicKey = <Phone_Public_Key>
AllowedIPs = 10.0.0.3/32

5. Jakie porty wykorzystuje WireGuard?

WireGuard domyślnie używa portu UDP 51820. Polega wyłącznie na protokole UDP, ponieważ jest on szybszy do tunelowania danych niż TCP. TCP wymaga potwierdzenia dla każdego wysłanego pakietu danych, co może znacznie spowolnić połączenie VPN. UDP po prostu wysyła dane, nie czekając na potwierdzenie, co jest idealne dla szybkiej natury WireGuard. Podczas konfiguracji zapory Ubuntu (UFW) musisz wyraźnie zezwolić na ruch na tym porcie UDP, w przeciwnym razie żądania połączeń zostaną zablokowane zanim dotrą do oprogramowania VPN.

6. Jak rozwiązywać problemy z połączeniem WireGuard?

Rozwiązywanie problemów z WireGuard zazwyczaj jest proste, ponieważ jest mniej elementów, które mogą sprawiać kłopoty. Jeśli nie możesz się połączyć, powinieneś wykonać następującą kolejność sprawdzeń:

Najpierw sprawdź status powitania, uruchamiając sudo wg show na swoim serwerze. Jeśli połączenie działa prawidłowo, zobaczysz linię z napisem latest handshake, po której następuje czas (np. „1 minutę temu”). Jeśli tej linii brakuje, urządzenia w ogóle się nie komunikują. Prawie zawsze jest to spowodowane zaporą sieciową blokującą port UDP lub niezgodnością kluczy publicznych/prywatnych.

Po drugie, jeśli połączenie (handshake) działa, ale nie możesz przeglądać internetu, problem prawdopodobnie leży w przekazywaniu IP. Musisz upewnić się, że Twój serwer Ubuntu ma pozwolenie na przekazywanie ruchu z VPN do internetu. Możesz to sprawdzić, przeglądając plik /etc/sysctl.conf i upewniając się, że linia net.ipv4.ip_forward=1 jest aktywna (nie jest zakomentowana).

7. Czy WireGuard obsługuje IPv6 na Ubuntu?

Tak, WireGuard ma doskonałe wsparcie dla IPv6. Jest bardzo elastyczny i może enkapsulować (owijać) różne typy ruchu. Na przykład możesz uzyskać dostęp do strony dostępnej tylko w IPv4 przez połączenie IPv6, lub odwrotnie. Aby to umożliwić, wystarczy umieścić w pliku konfiguracyjnym adresy IPv6 oddzielone przecinkami, obok standardowych adresów IPv4. Należy je dodać zarówno do pola Address (dla własnego IP serwera), jak i do pola AllowedIPs (dla IP klientów).

8. Jak włączyć uruchamianie WireGuard przy starcie systemu?

Aby zapewnić, że Twój VPN włączy się automatycznie za każdym razem, gdy uruchomisz ponownie serwer Ubuntu, musisz użyć systemd, który jest menedżerem systemu dla Linuksa. Używasz polecenia enable, aby poinformować system, aby szukał Twojego konkretnego pliku konfiguracyjnego (np. wg0) i ładował go podczas sekwencji startowej. Zapewnia to, że jeśli Twój serwer uruchomi się ponownie po aktualizacji, połączenie VPN zostanie przywrócone bez konieczności ręcznego jego uruchamiania.

sudo systemctl enable wg-quick@wg0

Wniosek

W tym samouczku skonfigurowałeś VPN WireGuard na serwerze Ubuntu i podłączyłeś klienta, korzystając zarówno z IPv4, jak i IPv6. W trakcie konfiguracji ustawiłeś klucze, przypisałeś adresy tunelu i włączyłeś na serwerze przekazywanie ruchu w sposób bezpieczny, uzyskując działający VPN, który jest łatwy do zrozumienia i obsługi.

Przewodnik obejmował również kilka praktycznych szczegółów, które są istotne, gdy VPN jest używany na co dzień, takich jak zarządzanie kluczami w czasie, obsługa IPv6 i sieci dwustackowych oraz poprawa niezawodności i wydajności poprzez dostosowanie MTU, keepalive i ustawienia DNS. Mając wszystko to na miejscu, powinieneś być dobrze przygotowany do uruchomienia WireGuard w rzeczywistych środowiskach lub dostosowania go w miarę zmieniających się potrzeb.

Jeśli chcesz dowiedzieć się więcej o WireGuard, w tym jak skonfigurować bardziej zaawansowane tunele lub używać WireGuard z kontenerami, odwiedź oficjalną dokumentację WireGuard. Aby zapoznać się z dodatkowymi poradnikami dotyczącymi zabezpieczania systemów Ubuntu, sprawdź następujące artykuły:

• Jak skonfigurować zaporę sieciową za pomocą UFW na Ubuntu
• UFW Essentials: Najczęstsze reguły zapory i polecenia dla bezpieczeństwa Linuksa
• VPC a VPN: Które rozwiązanie lepiej odpowiada Twoim potrzebom w zakresie bezpiecznej sieci?
• Jak skonfigurować i uruchomić serwer OpenVPN na Ubuntu

Dziękujemy za naukę z społecznością Linux-Console.net.