Krótki opis (meta description): Praktyczny przewodnik krok po kroku, jak od zera skonfigurować tunel WireGuard między zewnętrznym serwerem VPS a domową lub firmową siecią LAN opartą na Proxmove i pfSense. Tworzenie tunelu, kluczy, peerów, reguł firewalla oraz rozwiązywanie najczęstszych problemów z handshake.
Spis treści
- Wprowadzenie — po co łączyć VPS z siecią Proxmox
- Jak działa WireGuard — krótkie wyjaśnienie
- Wymagania wstępne
- Krok 1: Instalacja pakietu WireGuard na pfSense
- Krok 2: Tworzenie nowego tunelu WireGuard na pfSense
- Krok 3: Generowanie kluczy na VPS
- Krok 4: Dodanie peera VPS na pfSense
- Krok 5: Przypisanie interfejsu tunelu (Interface Assignment)
- Krok 6: Plik konfiguracyjny wg0.conf na VPS
- Krok 7: Reguły firewalla — pfSense oraz VPS
- Krok 8: Port forwarding na routerze ISP
- Krok 9: Uruchomienie tunelu i autostart
- Krok 10: Testowanie połączenia
- Integracja z kontenerami Docker (np. n8n)
- Najczęstsze błędy i ich rozwiązania
- Które klucze gdzie wkleić — ściągawka
- FAQ — najczęściej zadawane pytania
- Podsumowanie
1. Wprowadzenie — po co łączyć VPS z siecią Proxmox
Coraz więcej firm i entuzjastów home-labów uruchamia usługi takie jak n8n, Nextcloud czy własne API na zewnętrznym serwerze VPS, jednocześnie trzymając bazy danych, systemy plików czy inne zasoby wewnątrz prywatnej sieci LAN opartej na Proxmove. Problem pojawia się, gdy VPS musi komunikować się z hostami znajdującymi się w tej wewnętrznej sieci — bez publicznego adresu IP i bez otwierania niebezpiecznych portów na zewnątrz.
Rozwiązaniem jest tunel VPN typu site-to-site oparty na WireGuard, który tworzy bezpieczny, szyfrowany „most” między VPS-em a siecią LAN, tak jakby serwer VPS fizycznie stał w tej samej serwerowni co reszta infrastruktury. Dzięki temu:
- Kontenery Docker na VPS (np. n8n) mogą pingować i łączyć się z hostami w LAN po adresach wewnętrznych (np.
192.168.1.50), - Nie trzeba otwierać portów baz danych, SSH czy paneli administracyjnych na cały internet,
- Cały ruch jest szyfrowany end-to-end,
- Konfiguracja jest lekka i wydajna (WireGuard działa w warstwie jądra, w przeciwieństwie do OpenVPN).
Ten przewodnik zakłada, że zaczynasz od zera — na pfSense nie istnieje jeszcze żaden tunel WireGuard, a na VPS-ie WireGuard nie jest jeszcze zainstalowany.
2. Jak działa WireGuard — krótkie wyjaśnienie
WireGuard to nowoczesny protokół VPN oparty na kryptografii klucza publicznego. Każda strona tunelu (peer) posiada parę kluczy: prywatny (nigdy nie opuszcza urządzenia, na którym powstał) oraz publiczny (przekazywany drugiej stronie). Nie ma tu certyfikatów ani skomplikowanej infrastruktury PKI — cała autoryzacja opiera się na wymianie kluczy publicznych.
W scenariuszu opisanym w tym artykule mamy:
- pfSense jako bramę sieci LAN (host nasłuchujący, ze stałym publicznym adresem IP dostępnym przez router ISP),
- VPS jako inicjatora połączenia (peer z dynamicznym adresem, oznaczony na pfSense jako Dynamic Endpoint),
- Ruch pomiędzy nimi ograniczony wyłącznie do zdefiniowanych podsieci (
AllowedIPs), a nie do całego internetu.
3. Wymagania wstępne
Przed rozpoczęciem upewnij się, że posiadasz:
- Dostęp root/sudo do VPS (Ubuntu/Debian w przykładach),
- Dostęp administracyjny do pfSense,
- Stały publiczny adres IP po stronie sieci, w której stoi pfSense (lub DDNS, jeśli adres jest dynamiczny),
- Dostęp do panelu routera ISP, jeśli pfSense nie posiada bezpośrednio publicznego adresu WAN (co jest częste, gdy router operatora robi NAT przed pfSense),
- Wolną podsieć wewnętrzną do wykorzystania jako sieć tunelu, np.
10.0.0.0/24(nie może kolidować z istniejącą siecią LAN Proxmox, np.192.168.1.0/24).
4. Krok 1: Instalacja pakietu WireGuard na pfSense
Domyślnie pfSense (w wersji CE) nie ma aktywnego modułu WireGuard — trzeba go dodać:
- Przejdź do System → Package Manager → Available Packages.
- Wyszukaj
WireGuardi kliknij Install. - Po instalacji w menu VPN pojawi się nowa pozycja WireGuard.
W nowszych wersjach pfSense (2.7+) WireGuard jest wbudowany domyślnie i ten krok można pominąć — sprawdź od razu w menu VPN → WireGuard.
5. Krok 2: Tworzenie nowego tunelu WireGuard na pfSense
Przejdź do VPN → WireGuard → Tunnels → Add Tunnel i utwórz nowy interfejs tunelu:
| Pole | Wartość |
|---|---|
| Description | np. tun_wg0 |
| Listen Port | 51820 (domyślny port WireGuard) |
| Interface Keys | pfSense wygeneruje automatycznie parę kluczy — kliknij Generate |
| Address / Assignment | adres pfSense w sieci tunelu, np. 10.0.0.1/24 |
Po zapisaniu tunelu koniecznie skopiuj i zapisz sobie wygenerowany Public Key — będzie potrzebny w konfiguracji VPS-a (krok 6). Klucz prywatny zostaje zarządzany przez pfSense i nigdzie go ręcznie nie kopiujesz.
Wybór adresacji sieci tunelu: 10.0.0.0/24 to tylko przykład — możesz użyć dowolnej prywatnej podsieci (np. 10.10.0.0/24), pod warunkiem że nie pokrywa się z żadną już istniejącą siecią w Twojej infrastrukturze (LAN, inne VPN-y itd.).
6. Krok 3: Generowanie kluczy na VPS
Na serwerze VPS zainstaluj WireGuard i wygeneruj własną parę kluczy:
sudo apt update
sudo apt install wireguard -y
wg genkey | sudo tee /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key
sudo chmod 600 /etc/wireguard/private.key
Wyświetl i zapisz zawartość klucza publicznego — będzie potrzebna w następnym kroku:
cat /etc/wireguard/public.key
Ważne: plik private.key nigdy nie powinien opuszczać tego serwera — nie wysyłaj go mailem, nie wklejaj nigdzie poza plikiem konfiguracyjnym na tej samej maszynie.
7. Krok 4: Dodanie peera VPS na pfSense
Wróć do VPN → WireGuard → Tunnels, otwórz utworzony w kroku 2 tunel (np. tun_wg0) i w sekcji Peers kliknij Add Peer:
| Pole | Wartość |
|---|---|
| Description | VPS Proxmox |
| Dynamic Endpoint | zaznaczone (VPS ma dynamiczny/nieznany z góry adres) |
| Public Key | klucz publiczny z VPS (z kroku 3) |
| Allowed IPs | wolny adres z podsieci tunelu, np. 10.0.0.20/32 |
| Tunnel | upewnij się, że wybrany jest właściwy tunel (np. tun_wg0), nie zostawiaj Unassigned |
Dlaczego /32, a nie cała podsieć? Każdy peer musi mieć unikalny, niekolidujący zakres Allowed IPs. Jeśli w przyszłości dodasz kolejnych peerów (np. tunel z prywatnego komputera), a ich zakresy będą się nakładać, ruch trafi tylko do ostatniego z nich na liście — pozostałe przestaną działać poprawnie.
8. Krok 5: Przypisanie interfejsu tunelu (Interface Assignment)
Aby móc tworzyć reguły firewalla bezpośrednio dla ruchu WireGuard (a nie tylko traktować go jako część WAN), przypisz utworzony tunel jako osobny interfejs:
- Przejdź do Interfaces → Assignments.
- W liście dostępnych portów wybierz interfejs tunelu (np.
tun_wg0) i kliknij Add. - Wejdź w nowo utworzony interfejs (np.
OPT1), zaznacz Enable interface, opcjonalnie zmień nazwę na bardziej czytelną, np.WireGuard. - Zapisz i zastosuj zmiany (Apply Changes).
Dzięki temu krokowi w Firewall → Rules pojawi się osobna zakładka WireGuard, w której zdefiniujesz reguły dla ruchu wewnątrz tunelu (krok 7).
9. Krok 6: Plik konfiguracyjny wg0.conf na VPS
Utwórz plik konfiguracyjny na VPS:
sudo nano /etc/wireguard/wg0.conf
Wklej poniższą zawartość, podmieniając wartości na własne:
[Interface]
PrivateKey = <zawartość private.key z VPS>
Address = 10.0.0.20/24
[Peer]
PublicKey = <Public Key interfejsu pfSense wygenerowany w kroku 2>
Endpoint = <publiczny adres IP sieci z pfSense>:51820
AllowedIPs = 192.168.1.0/24, 10.0.0.0/24
PersistentKeepalive = 25
Krytyczna uwaga dotycząca AllowedIPs
AllowedIPs na VPS nigdy nie powinno być 0.0.0.0/0. Taka wartość (tzw. „full tunnel”) jest typowa dla klientów Windows/mobilnych, ale na serwerze VPS przekierowałaby cały ruch wychodzący przez tunel — łącznie z połączeniem SSH, którym akurat administrujesz serwerem. Skutkiem byłaby utrata dostępu do własnego VPS-a. Ogranicz AllowedIPs wyłącznie do podsieci LAN oraz podsieci tunelu.
Skąd biorą się poszczególne klucze — najczęstszy błąd
Bardzo częstym błędem (opisanym szerzej w sekcji FAQ) jest wklejenie w plik konfiguracyjny dosłownego tekstu z przykładu (np. <zawartość private.key>) zamiast realnej wartości klucza. WireGuard zwróci wtedy błąd:
Key is not the correct length or format
Configuration parsing error
Zawsze podmieniaj placeholdery na rzeczywistą zawartość plików private.key i kluczy publicznych skopiowanych z panelu pfSense.
10. Krok 7: Reguły firewalla — pfSense oraz VPS
10.1 Reguła na zakładce WireGuard (pfSense)
Ta reguła kontroluje ruch już wewnątrz nawiązanego tunelu (dostępna dzięki przypisaniu interfejsu w kroku 5):
| Pole | Wartość |
|---|---|
| Protocol | any |
| Source | WireGuard net |
| Destination | LAN net |
| Action | Pass |
10.2 Reguła na interfejsie WAN (pfSense) — najczęściej pomijany krok
To jest reguła, bez której handshake nigdy się nie nawiąże, ponieważ dotyczy surowego ruchu UDP przychodzącego z internetu, zanim jeszcze tunel zostanie zestawiony:
| Pole | Wartość |
|---|---|
| Interface | WAN |
| Protocol | UDP |
| Source | any |
| Destination | WAN address |
| Destination port | 51820 |
| Action | Pass |
10.3 Firewall na samym VPS
Jeśli VPS korzysta z ufw:
sudo ufw allow 51820/udp
sudo ufw reload
Jeśli VPS korzysta z firewalla chmurowego providera (Hetzner Cloud Firewall, AWS Security Groups, OVH, DigitalOcean Cloud Firewall) — to jest osobna, zewnętrzna warstwa niezależna od systemu operacyjnego. Otwórz tam:
| Pole | Wartość |
|---|---|
| Akceptuję | Tak |
| Protokół | UDP |
| Port | 51820 |
| Źródło | Gdziekolwiek |
11. Krok 8: Port forwarding na routerze ISP
Jeśli pfSense nie posiada bezpośrednio publicznego adresu IP na interfejsie WAN (co można sprawdzić w Status → Interfaces → WAN — adres z puli prywatnej, np. 192.168.1.16, oznacza, że przed pfSense stoi jeszcze router dostawcy internetu), konieczne jest przekierowanie portu na tym routerze:
| Pole | Wartość |
|---|---|
| Protokół | UDP |
| Port zewnętrzny (WAN) | 51820 |
| Port wewnętrzny (LAN) | 51820 |
| Adres docelowy | adres WAN pfSense w sieci lokalnej (np. 192.168.1.16) |
Bez tego kroku pakiety z VPS-a zatrzymają się na routerze ISP i nigdy nie dotrą do pfSense — co w praktyce objawia się jako 0 B received w statystykach tunelu (wg show), mimo że VPS wysyła dane poprawnie.
Jeśli masz już inny działający tunel WireGuard (np. z prywatnego komputera) przechodzący przez ten sam router ISP, port forwarding najprawdopodobniej już istnieje i możesz pominąć ten krok — wystarczy dodać nowego peera na tym samym, już otwartym porcie.
12. Krok 9: Uruchomienie tunelu i autostart
Na VPS uruchom i włącz tunel jako usługę systemową:
sudo systemctl enable --now wg-quick@wg0
enablezapewnia automatyczne uruchomienie tunelu po każdym restarcie serwera — nie trzeba nic dodatkowo konfigurować,--nowuruchamia usługę natychmiast, bez czekania na reboot.
Sprawdź, czy autostart jest aktywny:
systemctl is-enabled wg-quick@wg0
Wynik powinien brzmieć: enabled.
Dzięki PersistentKeepalive = 25 w konfiguracji, tunel utrzymuje aktywność nawet przez NAT po stronie hostingu VPS, automatycznie odnawiając połączenie bez ręcznej interwencji.
13. Krok 10: Testowanie połączenia
Sprawdź status tunelu:
sudo wg show
Kluczowa linia to latest handshake — jeśli widnieje tam wartość czasu (np. „8 seconds ago”), połączenie działa poprawnie. Jeśli widzisz tylko transfer: 0 B received, X KiB sent bez handshake, oznacza to, że pakiety wychodzą z VPS-a, ale odpowiedź nie wraca — patrz sekcja z rozwiązywaniem problemów.
Przetestuj łączność do hostów w sieci LAN:
ping -c2 10.0.0.1 # adres pfSense wewnątrz tunelu
ping -c2 192.168.1.50 # przykładowy host w LAN Proxmox
14. Integracja z kontenerami Docker (np. n8n)
Jeśli usługa którą chcesz połączyć z LAN (np. workflow automation n8n) działa w kontenerze Docker na tym samym VPS-ie, nie musisz zmieniać żadnej konfiguracji docker-compose.yml. Docker maskaruje ruch wychodzący z kontenera adresem hosta, więc pakiety z kontenera automatycznie skorzystają z tunelu WireGuard skonfigurowanego na poziomie systemu.
Sprawdź to bezpośrednio z kontenera:
docker exec -it n8n ping -c2 192.168.1.50
docker exec -it n8n nc -zv 192.168.1.65 22
Jeśli oba testy przechodzą, Twoje workflowy w n8n mogą normalnie odwoływać się do adresów wewnętrznych sieci LAN — tak jak wcześniej, zanim usługa trafiła na zewnętrzny VPS.
15. Najczęstsze błędy i ich rozwiązania
Błąd: „Key is not the correct length or format”
Przyczyna: w pliku wg0.conf wkleiłeś dosłowny placeholder (np. <zawartość private.key>) zamiast rzeczywistej wartości klucza.
Rozwiązanie: podmień na realną zawartość klucza pobraną komendą cat /etc/wireguard/private.key.
Błąd: transfer „0 B received” mimo poprawnej konfiguracji kluczy
Najczęstsze przyczyny, w kolejności prawdopodobieństwa:
- Brak reguły firewalla na interfejsie WAN pfSense dopuszczającej UDP 51820 — reguła na zakładce WireGuard nie wystarczy, bo dotyczy wyłącznie ruchu już wewnątrz tunelu.
- Brak port forwardingu na routerze ISP, jeśli WAN pfSense ma adres z puli prywatnej (np.
192.168.1.x). - Pomylony adres w polu
Endpoint— powinien tam być publiczny adres sieci, w której stoi pfSense, a nie adres samego VPS-a. - Firewall chmurowy providera VPS (Hetzner, OVH, AWS itd.) blokujący port 51820 na poziomie infrastruktury, niezależnie od
ufw/iptablesw systemie.
Błąd: konflikt AllowedIPs między peerami
Jeśli dwa peery na tym samym tunelu mają nakładające się zakresy AllowedIPs, ruch trafi tylko do ostatniego z nich na liście. Zawsze przypisuj unikalny adres /32 każdemu peerowi.
Błąd: brak zakładki WireGuard w Firewall → Rules
Przyczyna: pominięty krok 5 (Interface Assignment) — bez przypisania tunelu jako osobnego interfejsu, pfSense nie utworzy dedykowanej zakładki reguł dla tego ruchu.
Rozwiązanie: wróć do Interfaces → Assignments i dodaj interfejs tunelu, zgodnie z krokiem 5.
16. Które klucze gdzie wkleić — ściągawka
W całej konfiguracji występują dwie pary kluczy (VPS i pfSense). Prosta zasada: klucz prywatny zawsze zostaje tam, gdzie powstał. Klucz publiczny zawsze trafia na drugą stronę.
| Klucz | Pochodzenie | Miejsce docelowe |
|---|---|---|
| Private Key VPS | /etc/wireguard/private.key na VPS | wg0.conf na VPS, sekcja [Interface] |
| Public Key VPS | /etc/wireguard/public.key na VPS | Panel pfSense, pole Public Key peera (krok 7) |
| Public Key interfejsu pfSense | Wygenerowany automatycznie przy tworzeniu tunelu (krok 2) | wg0.conf na VPS, sekcja [Peer] |
| Private Key interfejsu pfSense | Wygenerowany automatycznie przy tworzeniu tunelu (krok 2) | Zostaje na pfSense, nie kopiuje się ręcznie |
17. FAQ — najczęściej zadawane pytania
Czy muszę znać publiczny adres IP samego VPS-a, żeby skonfigurować tunel?
Nie. Jeśli na pfSense peer ma zaznaczoną opcję Dynamic Endpoint, pfSense akceptuje połączenie od dowolnego adresu, o ile klucz publiczny się zgadza. Adres VPS-a nie musi być nigdzie jawnie wpisywany.
Dlaczego w polu Endpoint na VPS nie mogę wpisać adresu samego VPS-a?
Pole Endpoint określa adres drugiej strony tunelu, do której VPS ma się łączyć — czyli publiczny adres sieci, w której stoi pfSense. Wpisanie tam adresu własnego serwera powoduje, że VPS próbuje połączyć się sam ze sobą, co nigdy nie zestawi handshake’u.
Czy trzeba tworzyć nowy tunel dla każdego VPS-a?
Nie. Jeden tunel (interfejs) na pfSense, np. tun_wg0, może obsługiwać wielu peerów jednocześnie (kolejne VPS-y, komputery, telefony) — wystarczy dodawać kolejnych peerów w ramach tego samego tunelu, pamiętając o unikalnych adresach Allowed IPs dla każdego z nich.
Czy po restarcie VPS-a tunel wstanie automatycznie? T
ak, pod warunkiem wykonania sudo systemctl enable --now wg-quick@wg0. Flaga enable rejestruje usługę do autostartu przy każdym uruchomieniu systemu — nie jest wymagana żadna dodatkowa konfiguracja.
Czy AllowedIPs na VPS może być ustawione na 0.0.0.0/0?
Nie zaleca się tego na serwerze VPS. Taka wartość przekierowałaby cały ruch wychodzący (w tym własne połączenie SSH administratora) przez tunel, co może spowodować utratę dostępu do serwera. Ogranicz AllowedIPs do konkretnych podsieci LAN i tunelu.
18. Podsumowanie
Połączenie VPS-a z siecią LAN Proxmox przez WireGuard, budowane od podstaw, sprowadza się do kilkunastu logicznych kroków: instalacji pakietu WireGuard na pfSense, utworzenia nowego tunelu z własną parą kluczy, wygenerowania kluczy na VPS, dodania peera po obu stronach, przypisania interfejsu tunelu do firewalla, a następnie otwarcia właściwych portów na wszystkich warstwach (pfSense WAN, system VPS, firewall chmurowy providera, router ISP). Najczęstsze problemy nie wynikają z samego WireGuard, lecz z pominięcia jednej z wielu warstw firewalla stojących między VPS-em a siecią docelową. Po poprawnym skonfigurowaniu, tunel działa stabilnie, automatycznie odnawia się po restarcie serwera i pozwala kontenerom Docker (np. n8n) na transparentną komunikację z zasobami wewnątrz sieci LAN, tak jakby stały w tej samej serwerowni.
Promocja na kursy n8n i AI dla Administratora