Konfiguracja serwera WireGuard w systemie Linux (wg0, NAT, Peers)

Uruchom serwer WireGuard, jeśli chcesz uzyskać prywatny dostęp do hostowanej infrastruktury bez udostępniania portów administracyjnych w publicznej sieci internetowej. Wykorzystuje on uwierzytelnianie kluczem publicznym, działa w jądrach systemu Linux od wersji 5.6 i po uruchomieniu nie przeszkadza w pracy. W tym poście omówiono, kiedy należy używać serwera WireGuard, jak go uruchomić wg0oraz jak zapewnić sprawne działanie węzłów w codziennej eksploatacji.

Kiedy należy korzystać z serwera WireGuard

Większość konfiguracji można podzielić na trzy scenariusze: dostęp zdalny, połączenia między serwerami oraz routing między lokalizacjami.

W przypadku dostępu zdalnego uruchom serwer na VPS lub serwerze dedykowanym i przekieruj ruch administracyjny przez tunel. Skonfiguruj AllowedIPs na każdym węźle na prywatną podsieć zarządzania (na przykład 10.0.0.0/24), aby tylko ruch przeznaczony dla systemów wewnętrznych korzystał z tunelu. Cała pozostała komunikacja odbywa się przez lokalne połączenie użytkownika. Jeśli użytkownicy łączą się z sieci domowych lub komórkowych, należy dodać PersistentKeepalive = 25 po stronie klienta, aby zapobiec zerwaniu sesji NAT.

W przypadku połączeń między serwerami należy ustawić AllowedIPs wąskie. Zazwyczaj wystarcza pojedyncza /32 lub niewielką podsiecią zaplecza. Pozwala to uniknąć wprowadzania do tunelu niepowiązanego ruchu i zapewnia przewidywalność routingu.

W przypadku połączeń typu „site-to-site” sytuacja wygląda inaczej. Host WireGuard pełni rolę bramy między podsieciami, więc należy włączyć przekazywanie adresów IP, a reguły NAT muszą kierować ruch zwrotny przez właściwy interfejs.

Konfiguracja serwera

Serwer przechowuje klucz prywatny, domyślnie nasłuchuje na porcie UDP 51820 i kończy tunel. Ta sama podstawowa konfiguracja działa dla wszystkich trzech powyższych schematów.

Klucze i plik wg0.conf

Wygeneruj parę kluczy serwera:

wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

Zabezpiecz klucz prywatny:

sudo chmod 600 /etc/wireguard/server_private.key

Klucz prywatny pozostaje na serwerze. Klucz publiczny jest tym, który przekazujesz innym użytkownikom.

Utwórz /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
 
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

Znajdź interfejs wychodzący, do którego należy umieścić plik <PUBLIC_IFACE> :

ip -o -4 route show to default | awk '{print $5}'

Przekierowanie, zapora sieciowa i NAT

Otwórz port nasłuchujący:

sudo ufw allow 51820/udp

Włącz przekierowanie IP, dodając ten wiersz do pliku /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Zastosuj bez ponownego uruchamiania:

sudo sysctl -p

Plik PostUp oraz PostDown w wg0.conf dodają i usuwają regułę maskowania NAT, gdy interfejs zostaje uruchomiony lub wyłączony. Bez nich ruch zwrotny z sieci LAN nigdy nie dotrze z powrotem do partnera.

Uruchomienie tunelu

wg-quick obsługuje interfejs, routing oraz PostUp/PostDown haki w jednym poleceniu:

sudo wg-quick up wg0

Aby zapewnić automatyczne uruchamianie po ponownym uruchomieniu systemu, włącz jednostkę systemd:

sudo systemctl enable --now wg-quick@wg0

Sprawdź stan za pomocą:

sudo wg show

Najnowsza latest handshake potwierdza, że tunel działa. Jeśli wygląda na nieaktualny lub pusty, sprawdź zaporę sieciową, klucze po obu stronach oraz AllowedIPs.

Dodawanie i usuwanie partnerów

Każdy partner wymaga własnej pary kluczy. Należy ją wygenerować na kliencie, a następnie dodać klucz publiczny partnera do wg0.conf w nowym [Peer] bloku z AllowedIPs wpisem przypisującym jego adres IP tunelu.

Użyj /32 w przypadku pojedynczego urządzenia:

AllowedIPs = 10.8.0.3/32

Zapobiega to przejmowaniu przez jeden węzeł adresów przypisanych innemu. W przypadku dostępu z podziałem tunelu należy wymienić tylko te prywatne podsieci, które powinny przechodzić przez tunel, na przykład AllowedIPs = 10.8.0.0/24.

Zastosuj zmiany w konfiguracji bez przerywania aktywnych sesji:

sudo wg syncconf wg0 <(wg-quick strip wg0)

Usunięcie węzła partnera odbywa się w ten sam sposób. Należy usunąć jego [Peer] blok z wg0.conf i uruchom syncconf ponownie.

Rozwiązywanie problemów

Jeśli węzeł łączy się, ale nie może uzyskać dostępu do żadnych zasobów po drugiej stronie, przyczyną jest zazwyczaj jedna z czterech następujących sytuacji:

• Przekierowanie IP jest wyłączone
• Brakuje reguły maskowania NAT
• Nieprawidłowy interfejs wychodzący w regule NAT
• AllowedIPs nie zawiera adresu docelowego

Sprawdź przekazywanie:

cat /proc/sys/net/ipv4/ip_forward

Powinno zwrócić 1. Jeśli zwraca 0, zmiana w sysctl nie została zastosowana lub nie została zapisana.

Sprawdź regułę NAT i interfejs wychodzący:

sudo iptables -t nat -L POSTROUTING
ip route get 1.1.1.1

Drugie polecenie pokazuje rzeczywistą nazwę interfejsu wychodzącego, np. ens3, enp1s0lub eth0. Musi ona odpowiadać interfejsowi w regule MASQUERADE.

Jeśli brakuje samego uzgodnienia, sprawdź, czy port UDP 51820 jest otwarty w zaporze sieciowej i u każdego dostawcy usług internetowych wyższego szczebla oraz czy obie strony posiadają właściwy klucz publiczny drugiej strony.

W przypadku peerów znajdujących się za domowym lub mobilnym NAT-em, który przerywa nieaktywne sesje UDP, należy ustawić PersistentKeepalive = 25 na kliencie.

Rotacja kluczy i klucze wstępnie udostępnione

W przypadku tuneli działających przez miesiące klucze należy rotować mniej więcej raz w roku. Należy wygenerować nową parę kluczy, zaktualizować oba końce i zastosować za pomocą wg syncconf. Nie należy ponownie wykorzystywać klucza prywatnego w dwóch węzłach. Powoduje to konflikty routingu i zakłóca przesyłanie danych między nimi.

Aby zapewnić dodatkową warstwę bezpieczeństwa oprócz uwierzytelniania kluczem publicznym, należy dodać klucz wstępnie uzgodniony dla każdego węzła:

wg genpsk

Dodaj wynik jako PresharedKey = <PSK> w [Peer] bloku po obu stronach. WireGuard włącza klucz PSK do procesu nawiązywania połączenia, więc osoba atakująca, która w jakiś sposób przejmie jeden z kluczy asymetrycznych, nadal nie będzie w stanie odszyfrować ruchu bez niego.

Przydatne polecenia do codziennego użytku:

Jeśli potrzebujesz stabilnego, publicznie dostępnego serwera do zakończenia tuneli WireGuard i kierowania prywatnego ruchu do swojej infrastruktury, zapoznaj się z planami VPS bez limitów transferu danych oferowanymi przez FDC.