Dostęp do sieci domowej przez WireGuard: Raspberry Pi jako brama VPN

Raspberry Pi może zapewnić dostęp WireGuard do sieci domowej. Przy dzielonym tunelowaniu tylko wybrane sieci docelowe korzystają z tunelu; pozostały ruch internetowy nadal używa lokalnego łącza klienta. Instrukcja ogranicza dostęp VPN do domowej sieci IPv4 i dodaje rzeczywiste reguły filtrowania. Masquerading zastępuje adres źródłowy klienta adresem Pi podczas przekazywania pakietów. Ułatwia to powrót odpowiedzi, lecz samo nie ogranicza dostępu.

WireGuard jest zintegrowany z jądrem Linux. Nie oznacza to stałej przepustowości: wynik zależy od modelu Pi, CPU, sieci, drugiej strony i łącza. IPsec w Linuksie również zwykle przetwarza dane w jądrze, a OpenVPN może korzystać z Data Channel Offload. Twierdzenia o ponad 800 Mb/s, minimalnym obciążeniu CPU czy dostępie bez opóźnień wymagają pomiarów.

1. Ustalenie sieci i granic dostępu

• Sieć domowa: 192.168.10.0/24; Pi pod stałym adresem 192.168.10.2 na eth0.
• Serwer WireGuard: 10.100.0.1; jeden klient z własną tożsamością i adresem 10.100.0.2.
• Dozwolone: połączenia klienta do celów IPv4 w sieci domowej oraz powiązane odpowiedzi.
• Zablokowane: przekazywanie do innych sieci, nowe połączenia z LAN do klienta i dostęp z wg0 do usług samego Pi.

Przykładowe sieci nie mogą nakładać się wzajemnie ani z aktualną siecią lokalną klienta. eth0 musi odpowiadać rzeczywistemu interfejsowi LAN. Przy dostępie IPv4 router wymaga przekierowania wybranego portu UDP 51820 na Pi, a istniejący firewall hosta musi dopuszczać ten zewnętrzny ruch UDP. Poszczególne porty usług WWW lub dysków w LAN nie wymagają publicznego przekierowania. Przy Carrier-Grade NAT dostawca internetu współdzieli publiczny adres IPv4 między kilkoma łączami. Lokalne przekierowanie często wtedy nie wystarcza; potrzebna jest inna osiągalna droga dostępu.

2. Przygotowanie narzędzi i kluczy

W aktualnym Raspberry Pi OS narzędzia instaluje się poleceniami sudo apt update i sudo apt install wireguard-tools nftables. Poniższe tworzenie kluczy odbywa się w powłoce Bash konta root. Ograniczająca umask obowiązuje już podczas tworzenia, a set -C zapobiega nadpisaniu istniejących plików kluczy.

# In a root Bash shell, on the server:
set -euo pipefail
umask 077
install -d -m 700 /etc/wireguard
cd /etc/wireguard
set -C
wg genkey > server_private.key
wg pubkey < server_private.key > server_public.key

Klient tworzy oddzielną parę kluczy lokalnie. Między urządzeniami wymieniane są wyłącznie klucze publiczne. Klucze prywatne nie powinny trafiać do wspólnych notatek ani zrzutów ekranu. Pliki konfiguracyjne także zawierają klucze prywatne i wymagają trybu 600: odczyt i zapis są dozwolone tylko dla właściciela pliku, a grupa i pozostałe konta nie otrzymują uprawnień.

3. Ograniczenie przekazywania za pomocą filtrów

Poniższa zawartość należy do /etc/nftables.d/wireguard.nft. Nazwy tabel wg_guard i wg_nat muszą być zarezerwowane dla tej konfiguracji. Ponowne wczytanie zastępuje tylko własne tabele, a nie cały zestaw reguł. Przed aktywacją składnię sprawdza sudo nft -c -f /etc/nftables.d/wireguard.nft.

# Owned tables only; repeated loads replace these rules atomically.
add table inet wg_guard
flush table inet wg_guard
table inet wg_guard {
  chain input {
    type filter hook input priority -10; policy accept;
    iifname "wg0" counter drop
  }
  chain forward {
    type filter hook forward priority -10; policy accept;
    iifname "wg0" ct state invalid counter drop
    iifname "wg0" oifname "eth0" ip saddr 10.100.0.2 ip daddr 192.168.10.0/24 ct state { new, established, related } counter accept
    iifname "eth0" oifname "wg0" ip saddr 192.168.10.0/24 ip daddr 10.100.0.2 ct state { established, related } counter accept
    iifname "wg0" counter drop
    oifname "wg0" counter drop
  }
}
add table ip wg_nat
flush table ip wg_nat
table ip wg_nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    iifname "wg0" oifname "eth0" ip saddr 10.100.0.2 ip daddr 192.168.10.0/24 counter masquerade
  }
}

Filtr dopuszcza tylko ustalone źródło tunelowe i sieć domową jako cel. NAT maskuje dokładnie ten ruch adresem LAN Raspberry Pi. Urządzenia LAN odpowiadają wtedy bezpośrednio do Pi, bez dodatkowej trasy do sieci tunelowej. Wadą jest widoczny w logach LAN adres Pi zamiast pierwotnego adresu klienta.

Polityka accept pozostawia niezwiązany ruch bez zmian w tych dodatkowych tabelach. Inne istniejące łańcuchy bazowe nadal mogą odrzucać dozwolone pakiety, dlatego potrzebna jest integracja z obecnym firewallem. UFW, firewalld i Docker nie mogą niezauważenie zastępować ani omijać reguł; przyspieszone flowtables muszą wykluczać ruch VPN z ewentualnego obejścia filtrów. Na Pi zarządzanym wyłącznie przez nftables wpis include "/etc/nftables.d/wireguard.nft" może włączyć plik do utrzymywanego trwałego zestawu reguł. Późniejsze przeładowanie firewalla musi zachowywać te reguły.

4. Przekazywanie IPv4 i konfiguracja serwera

Przykład obsługuje cele IPv4. Przekazywanie IPv6 nie jest wymagane i nie jest włączane zbiorczo. Dodatkowy filtr inet odrzuca także przekazywanie IPv6 przez wg0, jeśli IPv6 jest już aktywne w innej części konfiguracji.

# /etc/sysctl.d/99-wireguard-forwarding.conf
net.ipv4.ip_forward = 1

Polecenie sudo sysctl -p /etc/sysctl.d/99-wireguard-forwarding.conf stosuje konkretny plik. Przykład nie narzuca globalnej wartości filtra ścieżki zwrotnej. Zmiana ip_forward może przywrócić parametrom IPv4 domyślne wartości routera; istniejące ustawienia ochrony wymagają późniejszej kontroli. Ścisłe rp_filter=1 może odrzucać poprawne trasy asymetryczne lub złożony policy routing, dlatego ustawienie musi odpowiadać topologii.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PreUp = /usr/sbin/nft -f /etc/nftables.d/wireguard.nft

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.100.0.2/32

Placeholdery wymagają zastąpienia rzeczywistymi kluczami. PreUp wczytuje filtry przed utworzeniem interfejsu; błąd ładowania zatrzymuje uruchomienie. Reguły pozostają po wyłączeniu i są zastępowane przy kolejnym starcie. Pozwala to uniknąć częściowo wykonanej sekwencji samych poleceń NAT w PostUp. UDP 51820 jest tu świadomym wyborem; bez ustawionego portu nasłuchu WireGuard może wybrać port losowy.

Po sprawdzeniu integracji z firewallem i uprawnień plików usługę uruchamia sudo systemctl enable --now wg-quick@wg0. Utwardzenie dotyczy opisanej ścieżki VPN. Aktualizacje systemu, SSH, pozostałe usługi hosta i prawa dostępu LAN nadal wymagają oddzielnego utrzymania.

5. Konfiguracja klienta z dzielonym tunelowaniem

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.100.0.2/32

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.example.net:51820
AllowedIPs = 192.168.10.0/24
# Optional for a client behind NAT:
PersistentKeepalive = 25

vpn.example.net jest placeholderem rzeczywistego, osiągalnego punktu końcowego. Aplikacja kliencka lub wg-quick tworzy trasy na podstawie AllowedIPs. Sam WireGuard używa prefiksów do wyboru peera dla wychodzących celów oraz do kontroli adresów źródłowych odebranych pakietów. Dlatego serwerowe AllowedIPs = 10.100.0.2/32 nie zastępuje filtrowania celów ani portów.

Zmiana klienta na 0.0.0.0/0 nie otwiera dostępu do internetu przez Pi przy pokazanych filtrach. Kolejne peery wymagają osobnych kluczy, unikalnych adresów tunelowych i odpowiednich reguł firewalla. PersistentKeepalive = 25 może podtrzymywać mapowania NAT; bez takiej potrzeby wiersz można pominąć.

6. Oddzielna kontrola działania i blokad

1. Podczas aktywnego ruchu testowego sudo wg show wg0 pokazuje handshake i liczniki transferu. Stary znacznik czasu bezczynnego peera sam w sobie nie dowodzi awarii. wg show ... dump i showconf mogą ujawniać prywatne informacje i nie powinny trafiać do publicznych logów diagnostycznych.
2. Na kliencie Linux ip route get 192.168.10.10 sprawdza trasę do domu. Przy tej konfiguracji ip route get 1.1.1.1 powinno nadal wskazywać lokalną drogę internetową. Inne systemy wymagają odpowiedniej diagnostyki routingu.
3. Dozwolona usługa LAN musi być osiągalna. Cele internetowe przez celowo zmienionego testowego klienta pełnego tunelu oraz usługi Pi pod adresem tunelowym muszą pozostać zablokowane. Liczniki w sudo nft list table inet wg_guard pomagają wskazać pasujące reguły.
4. Autoryzowany test iperf3 mierzy rzeczywistą przepustowość. Wynik ograniczają obciążenie CPU, upload domowy, druga strona i MTU; wysoka wartość sama nie dowodzi pełnego wykorzystania łącza ani braku fragmentacji.