04/26/2026
Twoje własne Cloudflare za 10 €/miesiąc: OPNsense jako reverse proxy na VPS-ie 10 Gbps
━━━━━━━━━━━━━━━━━━━━
via https://www.linkedin.com/pulse/dein-eigenes-cloudflare-f%C3%BCr-10-monat-opnsense-als-reverse-proxy-7zh5f/
━━━━━━━━━━━━━━━━━━━━
Cennik Cloudflare ustabilizował się: 20 USD miesięcznie za domenę w planie Pro (podstawowe własne reguły WAF), 200 USD miesięcznie za domenę w planie Business (dopasowanie regexów, zaawansowany WAF, SLA 100% dostępności) oraz od około 2000 USD miesięcznie wzwyż dla Enterprise. Plan darmowy oferuje wyłącznie zarządzane reguły WAF — bez możliwości definiowania własnych reguł, bez regexów i z bardzo ograniczonym rate limitingiem (jedna reguła). Dla każdego, kto utrzymuje coś więcej niż stronę hobbystyczną i więcej niż jedną domenę, Cloudflare staje się realną pozycją w budżecie.
Tymczasem VPS 10 Gbps z dedykowanymi rdzeniami, pamięcią ECC i nielimitowanym transferem można dziś wynająć za mniej niż 10 €/miesiąc. OPNsense — firewall oparty na BSD — dzięki oficjalnej wtyczce Caddy dojrzał do roli pełnoprawnej platformy reverse proxy. Te dwa fakty sprawiają, że samodzielnie hostowany stos brzegowy staje się realną cenową alternatywą dla tej części Cloudflare, z której faktycznie korzysta większość małych i średnich serwisów: terminacji TLS, reverse proxy oraz podstawowej ochrony brzegowej.
Ten artykuł dokumentuje budowę takiego rozwiązania: mały VPS z OPNsense, tunel WireGuard łączący go z prywatną siecią światłowodową oraz Caddy terminujący TLS dla backendów fizycznie działających w tej sieci — w domu, biurze, hali produkcyjnej, serwerowni klubu sportowego, racku w piwnicy kolektywu graczy, siedzibie organizacji non-profit lub w dowolnym innym miejscu z dostępem do światłowodu. Konfiguracja jest stosunkowo prosta, ale zawiera kilka punktów, w których łatwo o trudne do wykrycia błędy. Każdy z nich opisano poniżej.
━━━━━━━━━━━━━━━━━━━━
▌ Sprzęt i dostawca
Minimalne wymagania dla OPNsense to 1 rdzeń CPU i 1 GB RAM; projekt zaleca 2 rdzenie i 2 GB.
Najmniejsza oferta u the.hosting, która spełnia te zalecenia i umożliwia bootowanie własnego ISO, to plan ◆ Ruthenium-[DE] ◆: 2 dedykowane vCPU, 4 GB RAM ECC, 60 GB NVMe RAID 10, port 10 Gbps z nielimitowanym transferem — 9,77 €/miesiąc (umowa miesięczna, bez zobowiązań). Możliwość bootowania własnego ISO jest kluczowa do instalacji OPNsense; w tańszych planach u innych dostawców nie zawsze jest dostępna. Inne lokalizacje są dostępne w tej samej cenie.
━━━━━━━━━━━━━━━━━━━━
▌ Warunek łączności: światłowód po stronie prywatnej
Architektura zakłada dostęp do światłowodu po stronie prywatnej, czyli tam, gdzie działają backendy. To kluczowy warunek — warto go nazwać wprost, ponieważ wiele dyskusji o self-hostingu wciąż milcząco zakłada ADSL lub słabe VDSL, co czyni tę architekturę niepraktyczną.
Powód jest prosty i asymetryczny: VPS brzegowy ma łącze 10 Gbps bez limitu transferu, natomiast backendy są osiągane przez tunel WireGuard. Ostateczną przepustowość determinuje więc upload po stronie prywatnej.
ADSL oferuje zwykle 0,5–1 Mbps uploadu — praktycznie bezużyteczne poza blogiem osobistym. VDSL i sieci kablowe kończą się zazwyczaj na 10–40 Mbps, sporadycznie 100 Mbps — wystarczające dla małych stron, ale niewystarczające dla streamingu, gier multiplayer czy aktywnych środowisk współpracy.
Nowoczesne łącza FTTH (Fiber to the Home) w większości krajów UE, w wielu regionach Azji Wschodniej oraz części Ameryki Północnej oferują dziś prędkości symetryczne — 1 Gbps w obie strony jest standardem w ofertach konsumenckich w Niemczech, Francji, Hiszpanii, Portugalii, Rumunii, Czechach, Polsce i krajach nordyckich. Coraz częściej dostępne są również oferty 2,5 Gbps i 10 Gbps. Tam, gdzie dostępny jest światłowód, upload przestaje być wąskim gardłem.
„Prywatna sieć” może znajdować się wszędzie tam, gdzie kończy się światłowód: w domu, biurze, hali produkcyjnej, magazynie, klubie sportowym, hackerspace’ie, instytucji kultury czy siedzibie organizacji non-profit. Architektura pozostaje neutralna względem lokalizacji.
Dla miejsc bez światłowodu istnieją dwa praktyczne rozwiązania alternatywne: hosting backendu na drugim VPS-ie lub kolokacja w regionalnym data center. Oba działają, ale zmieniają założenia architektury i nie są przedmiotem tego artykułu.
━━━━━━━━━━━━━━━━━━━━
▌ Architektura
Mały VPS działa jako węzeł brzegowy z publicznym adresem IPv4. Na nim zainstalowany jest OPNsense, a Caddy obsługuje reverse proxy dla publicznego HTTPS. Tunel WireGuard łączy VPS z jedną lub wieloma maszynami w prywatnej sieci światłowodowej.
W artykule przyjęto:
▸ Podsieć: 10.0.0.0/24
▸ OPNsense: 10.0.0.1
▸ Backend (ODIN): 10.0.0.10
▸ Klient (THOR): 10.0.0.20
VPN pełni rolę sieci LAN. Z perspektywy OPNsense backend jest po prostu hostem wewnętrznym. Caddy automatycznie pobiera certyfikaty Let's Encrypt, kończy TLS na VPS-ie i przekazuje ruch HTTP przez zaszyfrowany tunel WireGuard.
Użytkownik publiczny łączy się z poprawnym certyfikatem; backend nigdy nie wystawia portów do internetu.
To nie jest zamiennik globalnej sieci anycast Cloudflare ani jego infrastruktury DDoS. To zamiennik tej części funkcjonalności, z której faktycznie korzysta większość self-hostowanych serwisów.
━━━━━━━━━━━━━━━━━━━━
▌ Kolejność instalacji
Poniższa sekwencja to ścieżka najmniejszego oporu. Każdy krok zależy od poprzedniego.
✦ Krok 1 — Instalacja OPNsense
Zainstaluj OPNsense z obrazu DVD ISO dostępnego na stronie projektu - https://opnsense.org/download/ . Obraz DVD jest właściwym wyborem dla VPS-a — uruchamia się z wirtualnego napędu CD-ROM i instaluje system bezpośrednio na dysku.
✦ Krok 2 — Konfiguracja z poziomu konsoli
Zaloguj się do konsoli (konsola webowa VNC dostawcy VPS) jako root, używając domyślnego hasła "opnsense" podczas instalacji, a następnie przejdź przez tekstowe menu konfiguracyjne.
▸ Opcja 1 — zmiana hasła roota
Ustaw silne hasło dla użytkownika root.
▸ Opcja 2 — przypisanie interfejsów
Przypisz interfejs sieciowy VPS-a do WAN. Przy pytaniu o LAN pomiń konfigurację (OPNsense na VPS-ie brzegowym nie korzysta z interfejsu LAN — pozostaw pole puste). Odrzuć konfigurację VLAN.
▸ Opcja 3 — konfiguracja adresu IP interfejsu
Skonfiguruj interfejs WAN, podając adres IPv4, prefiks oraz bramę zgodnie z danymi od dostawcy VPS-a. Nie używaj DHCP, chyba że dostawca wyraźnie tego wymaga. Pomiń konfigurację IPv6, jeśli nie został przydzielony adres.
Na pytanie „Do you want to revert to HTTP as the protocol for the web GUI” odpowiedz nie — HTTPS jest właściwym wyborem.
✦ Krok 3 — Logowanie do GUI
Zaloguj się do interfejsu WWW OPNsense, korzystając z publicznego adresu IP VPS-a przez HTTPS. Przeglądarka zgłosi ostrzeżenie o samopodpisanym certyfikacie — jest to zachowanie oczekiwane.
✦ Krok 4 — Dodanie reguł zezwalających na HTTP i HTTPS na WAN
Dodaj reguły dopuszczające ruch HTTP (80) i HTTPS (443) na interfejsie WAN przed włączeniem automatycznych reguł WAN.
Przejdź do ◆ Firewall → Rules → WAN ◆ i kliknij + Add po prawej stronie. Należy utworzyć dwie reguły.
Reguła HTTPS:
▸ Action: Pass
▸ Interface: WAN
▸ Direction: in
▸ TCP/IP Version: IPv4
▸ Protocol: TCP
▸ Source: any
▸ Destination: This Firewall
▸ Destination port range: HTTPS (443) do HTTPS (443)
▸ Description: Admin HTTPS during install
▸ Save
Reguła HTTP (dla wyzwań ACME):
Wszystkie pola jak wyżej, z wyjątkiem:
▸ Destination port range: HTTP (80) do HTTP (80)
▸ Description: ACME HTTP-01
▸ Save
Następnie kliknij ◆ Apply changes ◆ na górze listy reguł.
Kolejność ma znaczenie: podczas instalacji interfejs WAN nie ma aktywnego zestawu reguł i domyślnie przepuszcza cały ruch. Po włączeniu automatycznych reguł (krok 5) zaczyna obowiązywać domyślna polityka deny, a dopuszczany jest wyłącznie ruch zgodny z jawnie zdefiniowanymi regułami typu Pass.
Reguła HTTPS zapewnia ciągłość dostępu do GUI w tym przejściowym momencie, natomiast reguła HTTP umożliwia walidację HTTP-01 dla Let's Encrypt. Po skonfigurowaniu Caddy (krok 9) port TCP/443 na WAN zostaje przejęty przez Caddy.
✦ Krok 5 — Włączenie automatycznych reguł WAN
Włącz standardowe automatyczne reguły WAN: wyjątki anti-lockout, ochronę SSH (lockout) oraz blokowanie sieci typu bogon. Są one dostępne w ustawieniach interfejsu OPNsense i nie wymagają ręcznego definiowania.
Od tego momentu na interfejsie WAN obowiązuje domyślna polityka deny, a reguły z kroku 4 wraz z regułami automatycznymi określają, jaki ruch jest dopuszczany.
✦ Krok 6 — Konfiguracja WireGuard
Przejdź do ◆ VPN → WireGuard ◆. Wtyczka udostępnia u góry kilka zakładek:
▸ Instances — definiuje instancję WireGuard po stronie OPNsense (klucz prywatny, port nasłuchu, adres tunelu). W typowej konfiguracji używana jest jedna instancja.
▸ Peers — definiuje zdalnych klientów. Jeden wpis peer na każdego klienta (np. ODIN i THOR).
▸ Status — pokazuje stan tunelu w czasie rzeczywistym (czas od ostatniego handshake’u, liczniki RX/TX, endpointy peerów). Odpowiednik polecenia `wg show`.
▸ Diagnostics — zawiera logi oraz aktualnie załadowaną konfigurację.
▸ Settings — globalne ustawienia usługi, w tym jej włączanie i wyłączanie.
---
❖ 6a. Utworzenie instancji
Zakładka Instances → + Add:
▸ Enabled: ✓
▸ Name: wg0
▸ Listen Port: 51820
▸ Public Key / Private Key: pozostaw puste — OPNsense wygeneruje je automatycznie przy zapisie
▸ Tunnel Address: 10.0.0.1/24 (maska /24 jest kluczowa; patrz Troubleshooting 2)
▸ Peers: na tym etapie pozostaw puste
▸ Save → Apply
Po zapisaniu otwórz instancję ponownie i skopiuj wygenerowany Public Key — będzie potrzebny po stronie klientów.
---
❖ 6b. Dodanie peerów
Zakładka Peers → + Add (jeden wpis na klienta).
Dla ODIN-a:
▸ Enabled: ✓
▸ Name: ODIN
▸ Public Key: wklej klucz publiczny ODIN-a (wygenerowany poleceniem: `wg genkey | tee privatekey | wg pubkey > publickey`)
▸ Allowed IPs: 10.0.0.10/32 (adres tunelowy przypisany do ODIN-a; patrz Troubleshooting 3)
▸ Endpoint Address / Port: pozostaw puste (połączenie inicjuje klient)
▸ Keepalive: 25 s
▸ Save
Powtórz analogicznie dla THOR-a, używając adresu 10.0.0.20/32.
---
❖ 6c. Przypisanie peerów do instancji
Wróć do zakładki Instances, otwórz utworzoną instancję i w polu Peers zaznacz ODIN-a oraz THOR-a → Save → Apply.
Ten krok jest niezbędny — bez niego GUI zapisze konfigurację, ale nie zostanie ona załadowana do jądra systemu.
---
❖ 6d. Reguła Pass na WAN dla portu WireGuard
Przejdź do: Firewall → Rules → WAN → + Add:
▸ Action: Pass
▸ Interface: WAN
▸ Protocol: UDP
▸ Source: any
▸ Destination: This Firewall
▸ Destination port range: (other) 51820–51820
▸ Description: WireGuard inbound
▸ Save → Apply changes
---
❖ 6e. Przypisanie i włączenie interfejsu WireGuard
Przejdź do: Interfaces → Assignments → w wierszu „New interface” wybierz wg0 → kliknij + → Save.
Nowy interfejs pojawi się jako OPT1. Otwórz go, włącz (Enable), pozostaw konfigurację IPv4/IPv6 jako None, opcjonalnie zmień nazwę (np. na WG_FIBER) → Save → Apply changes.
(Patrz Troubleshooting 4 — wyjaśnienie, dlaczego przypisanie interfejsu jest konieczne.)
---
❖ 6f. Tymczasowa reguła Pass na interfejsie WireGuard
Przejdź do: Firewall → Rules → [WG_FIBER] → + Add:
▸ Action: Pass
▸ Interface: WG_FIBER
▸ Protocol: any
▸ Source: any
▸ Destination: any
▸ Description: WG debug allow all
▸ Save → Apply changes
Reguła jest celowo szeroka na etapie pierwszego uruchomienia. Po weryfikacji działania tunelu należy ją zawęzić.
---
❖ 6g. Konfiguracja klientów
Każdy klient (ODIN, THOR) wymaga pliku konfiguracyjnego wg-quick. Przykładowy szablon:
```
[Interface]
PrivateKey =
Address = 10.0.0.10/24
[Peer]
PublicKey =
PresharedKey =
Endpoint = :51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
```
W systemie Linux zapisz plik jako `/etc/wireguard/wg0.conf` i uruchom poleceniem:
```
wg-quick up wg0
```
W systemie Windows wklej konfigurację w kliencie WireGuard przez opcję Add Tunnel → Add empty tunnel.
Oto poprawiona stylistycznie i językowo wersja:
---
✦ Krok 7 — Test tunelu
Na kliencie (THOR) uruchom tunel. Następnie wykonaj polecenie:
```
ping 10.0.0.1
```
Jeśli ping działa, tunel funkcjonuje poprawnie. W przeciwnym razie przejdź do diagnostyki po stronie OPNsense.
▸ Stan tunelu w czasie rzeczywistym:
VPN → WireGuard → Status
Każdy peer powinien mieć aktualny znacznik „latest handshake” (nie starszy niż ~2 minuty) oraz niezerowe liczniki RX/TX.
Odpowiednik w powłoce: `wg show` (konsola OPNsense, opcja 8).
▸ Ping peera z OPNsense:
Interfaces → Diagnostics → Ping
Wpisz adres tunelowy peera (np. 10.0.0.20) w polu Hostname.
Ustaw Source address na przypisany interfejs WireGuard (WG_FIBER) — to kluczowe, ponieważ domyślna wartość może wskazać adres WAN, który nie ma trasy do tunelu — i kliknij Ping.
▸ Podgląd pakietów na interfejsie wg:
Interfaces → Diagnostics → Packet Capture
Ustaw: Interface = wg0, Address family = IPv4, Protocol = ICMP → Start.
Następnie wykonaj ping z klienta. Powinny być widoczne zarówno echo request, jak i echo reply. Jeśli widoczny jest tylko request, odpowiedź jest blokowana — najczęściej przez firewall lub błędne powiązanie adresu po stronie OPNsense.
▸ Log firewalla na żywo:
Firewall → Log Files → Live View
Filtruj po adresie źródłowym lub docelowym i sprawdzaj, które pakiety są oznaczane jako pass lub block.
▸ Stan routingu i interfejsu:
Interfaces → Diagnostics → Routes
Tablica routingu powinna zawierać podsieć 10.0.0.0/24 przypisaną do interfejsu wg.
Z poziomu powłoki polecenie:
```
ifconfig wg0
```
powinno zwrócić dokładnie jedną linię `inet` z adresem 10.0.0.1 i maską 0xffffff00.
Gdy ping 10.0.0.1 z klienta działa, otwórz w przeglądarce:
```
https://10.0.0.1
```
i zaloguj się do GUI OPNsense przez tunel.
---
✦ Krok 8 — Przeniesienie GUI OPNsense z WAN na interfejs WG
Przejdź do: System → Settings → Administration i znajdź sekcję Web GUI.
▸ Listen Interfaces: usuń wszystkie zaznaczenia i wybierz wyłącznie interfejs WireGuard (WG_FIBER)
▸ TCP port: pozostaw 443
▸ HTTP Redirect: może pozostać włączony — będzie działał wyłącznie wewnątrz tunelu
▸ Save
Po zapisaniu GUI zostanie przypisane wyłącznie do interfejsu WireGuard. Bieżąca sesja może zostać przerwana — odśwież stronę `https://10.0.0.1`, aby potwierdzić dostęp.
Adres WAN przestaje obsługiwać GUI; port TCP/443 na WAN jest dostępny dla Caddy.
Regułę Pass HTTPS z kroku 4 (Admin HTTPS during install) można usunąć lub pozostawić — po instalacji Caddy może z niej skorzystać.
---
✦ Krok 9 — Włączenie Caddy
Włącz wtyczkę Caddy i skonfiguruj ją. Usługa zwiąże się z interfejsem WAN na portach TCP/80 oraz TCP/443.
---
✦ Krok 10 — Domena i reverse proxy
Skieruj domenę na adres IP WAN VPS-a i skonfiguruj wpis reverse proxy w Caddy, np.:
```
app.example.com → http://10.0.0.10:9000
```
Zastosuj zmiany (Apply) i monitoruj logi pod kątem uzyskania certyfikatu TLS. Po poprawnej konfiguracji usługa powinna być dostępna publicznie.
Sekcje troubleshootingu poniżej odnoszą się głównie do kroku 6 i dalszych.
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 1: Generowanie pary kluczy
Każdy endpoint WireGuard — zarówno instancja OPNsense, jak i każdy klient — posiada własną parę kluczy. Klucz publiczny służy do identyfikacji drugiej strony: OPNsense identyfikuje peera po jego kluczu publicznym, a peer identyfikuje OPNsense w analogiczny sposób.
✦ Para kluczy instancji OPNsense jest generowana automatycznie podczas tworzenia instancji w GUI. Klucz publiczny jest następnie dostępny do skopiowania i użycia w konfiguracji klientów. Na OPNsense nie ma potrzeby ręcznego wywoływania `wg genkey`.
✦ Klienci (peerzy) muszą wygenerować klucze ręcznie. Na każdym kliencie wykonaj:
```
wg genkey | tee privatekey | wg pubkey > publickey
```
Powstaną dwa pliki:
▸ privatekey — używany w sekcji `[Interface]` jako `PrivateKey` w konfiguracji klienta
▸ publickey — wklejany do OPNsense w polu Public Key danego peera
Pre-Shared Key (PSK) jest opcjonalny (generowany poleceniem `wg genpsk`) i musi być identyczny po obu stronach tunelu. Zapewnia dodatkową warstwę bezpieczeństwa (w tym odporność na potencjalne zagrożenia post-kwantowe) i jest zalecany.
Oto poprawiona, spójna stylistycznie i językowo wersja:
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 2: Semantyka AllowedIPs
Parametr AllowedIPs ma tę samą definicję po obu stronach połączenia:
> Pakiety, których adres docelowy znajduje się w AllowedIPs, są szyfrowane kluczem danego peera i wysyłane do niego. Pakiety przychodzące od tego peera są akceptowane tylko wtedy, gdy ich adres źródłowy znajduje się na tej liście.
Pełni on jednocześnie rolę wpisu routingu wychodzącego oraz listy kontroli dostępu (ACL) dla adresów źródłowych. Wartości po obu stronach różnią się, ponieważ każda ze stron pełni inną rolę w topologii.
---
❖ Po stronie instancji OPNsense (10.0.0.1)
Instancja posiada adres tunelowy (swoje IP w obrębie tunelu) oraz port nasłuchu. Adres tunelu musi mieć postać 10.0.0.1/24.
Maska ma kluczowe znaczenie: przy /24 jądro systemu instaluje trasę podsieciową dla 10.0.0.0/24 na interfejsie wg, co umożliwia adresowanie wszystkich peerów. Przy /32 OPNsense wiąże wyłącznie własny adres — handshake działa, ale ruch do innych peerów (np. 10.0.0.10 czy 10.0.0.20) kończy się błędami:
„Network unreachable” po stronie OPNsense
„Required key not available” po stronie klienta
Oba wynikają z braku odpowiedniego wpisu w mechanizmie cryptokey routing.
---
❖ Konfiguracja peerów po stronie serwera (OPNsense)
Każdy peer powinien mieć przypisany dokładnie jeden adres w postaci /32:
▸ ODIN: `AllowedIPs = 10.0.0.10/32`
▸ THOR: `AllowedIPs = 10.0.0.20/32`
Jeśli oba wpisy zostaną ustawione jako 10.0.0.0/24, będą się nakładać. Jądro załaduje wpis tylko dla jednego peera, a drugi zostanie po cichu odrzucony (GUI nie zgłasza błędu). Efekt: działa tylko jeden peer.
Stan można zweryfikować poleceniem:
```
wg show
```
Każdy peer powinien mieć widoczne swoje /32 w sekcji allowed ips. Wartość (none) oznacza, że wpis nie został załadowany.
Jeśli peer udostępnia dodatkową sieć (np. LAN za routerem), należy ją dodać:
```
AllowedIPs = 10.0.0.10/32, 192.168.50.0/24
```
---
❖ Po stronie klienta
Klient posiada jeden wpis peera — instancję OPNsense. Przez nią musi osiągnąć zarówno serwer, jak i innych peerów. Dlatego zakres AllowedIPs jest szeroki:
```
[Peer]
PublicKey =
Endpoint = :51820
AllowedIPs = 10.0.0.0/24
```
Maska /24 jest poprawna, ponieważ obejmuje całą podsieć tunelu. Użycie /32 ograniczyłoby komunikację wyłącznie do OPNsense i uniemożliwiło ruch peer-to-peer.
Dla pełnego tunelowania (cały ruch przez VPS):
```
AllowedIPs = 0.0.0.0/0
```
---
❖ Maska Address po stronie klienta
Użyj:
```
Address = 10.0.0.10/24
```
a nie /32. Dzięki temu system klienta instaluje trasę do całej podsieci tunelu. Przy /32 klient zna jedynie własny adres, co uniemożliwia komunikację z innymi peerami.
---
❖ Weryfikacja
Najważniejszym narzędziem diagnostycznym jest:
```
wg show
```
Pokazuje ono rzeczywisty stan konfiguracji w jądrze: handshake, liczniki ruchu oraz faktycznie załadowane allowed ips. Konfiguracja w GUI i stan jądra mogą się rozjechać — wiarygodny jest stan jądra.
W razie potrzeby przeładuj konfigurację:
```
configctl wireguard restart
```
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 3: Maska adresu tunelu i nadmiarowe adresy
Dwa częste błędy:
▸ Adres tunelu ustawiony jako 10.0.0.1/32 zamiast /24
Interfejs otrzymuje adres, ale brak trasy podsieciowej. Handshake działa, lecz ruch do peerów kończy się błędami routingu.
▸ Dodanie adresów peerów do pola Tunnel Address
Jeśli dodasz np. 10.0.0.10 do Tunnel Address, OPNsense uzna ten adres za własny. W efekcie pakiety ICMP mogą być lokalnie konsumowane zamiast przekazywane.
Weryfikacja:
```
ifconfig wg0
```
Poprawny wynik powinien zawierać dokładnie jedną linię `inet`:
```
inet 10.0.0.1 netmask 0xffffff00
```
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 4: Przypisanie interfejsu vs grupa WireGuard
Po włączeniu WireGuard OPNsense tworzy pseudo-interfejs „WireGuard (Group)”, agregujący ruch. Reguły firewalla na tej grupie nie zawsze poprawnie dopasowują ruch kierowany do samego firewalla (np. ICMP do adresu tunelu).
Poprawna konfiguracja:
▸ Interfaces → Assignments → wybierz wg0 → kliknij + → Save
▸ Interfejs pojawi się jako OPT1 — włącz go, pozostaw IPv4/IPv6 jako None, opcjonalnie zmień nazwę → Save → Apply
▸ Reguły firewalla definiuj na tym interfejsie, nie na grupie
Na początek zastosuj regułę:
Action: Pass
Protocol: any
Source: any
Destination: any
Po weryfikacji działania zawęź ją.
Objaw problemu: pakiety ICMP docierają do interfejsu (widoczne w `tcpdump`), firewall raportuje pass, ale brak odpowiedzi. Rozwiązaniem jest przypisanie interfejsu i przeniesienie reguł.
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 5: Domyślna polityka deny
OPNsense ma domyślnie:
LAN — tryb permisywny
wszystkie inne interfejsy — deny all
Oznacza to, że WAN, WireGuard i każdy dodatkowy interfejs blokują cały ruch, dopóki nie zostanie dodana reguła Pass.
Widoczne reguły (np. blokowanie portu 0, bogonów czy SSH lockout) są warunkowe i rzadko stanowią przyczynę problemów. Najczęściej winna jest domyślna polityka deny.
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 6: DNS w konfiguracji WireGuard
Ustawienie:
```
DNS = 10.0.0.1
```
powoduje, że klient kieruje zapytania DNS do OPNsense. Działa to tylko wtedy, gdy resolver (np. Unbound) nasłuchuje na interfejsie WireGuard i firewall dopuszcza ruch na UDP/53.
W typowym scenariuszu reverse proxy nie jest to konieczne — klienci mogą korzystać z własnych resolverów. Zaleca się pominięcie tej opcji.
━━━━━━━━━━━━━━━━━━━━
▌ Troubleshooting 7: Firewall hosta i routing po stronie klienta
Aktywny tunel nie gwarantuje poprawnej komunikacji. Ruch może zostać zablokowany po stronie klienta:
▸ Linux (firewalld) — interfejs wg trafia do strefy public, która blokuje ruch przychodzący
→ przenieś do strefy trusted
▸ Debian/Ubuntu — zwykle brak blokad, ale sprawdź `iptables` lub `nftables`, jeśli używasz dodatkowych narzędzi
▸ Windows — zazwyczaj działa bez zmian, ale może wymagać reguły dla ICMP lub zmiany profilu sieci
▸ Wiele tuneli WireGuard — nakładające się zakresy AllowedIPs mogą powodować błędne trasy
---
Diagnostyka:
```
wg show transfer
```
Interpretacja:
▸ TX rośnie, RX = 0 → brak odpowiedzi (problem po stronie serwera)
▸ TX = 0 → pakiety nie trafiają do tunelu (problem routingu po stronie klienta)
▸ TX i RX rosną, ping nie działa → ruch blokowany lokalnie (firewall hosta)
Poniżej masz wersję poprawioną stylistycznie i językowo — zachowuję techniczną precyzję, ale upraszczam składnię, eliminuję kalki i wygładzam rytm:
━━━━━━━━━━━━━━━━━━━━
▌ Konfiguracja Caddy
Po zweryfikowaniu działania WireGuard end-to-end oraz związaniu GUI OPNsense wyłącznie z tunelem konfiguracja Caddy jest prosta.
Services → Caddy Web Server → General Settings:
▸ Włącz Caddy.
▸ ACME → Email Address: podaj prawidłowy adres e-mail (wymagany przez Let’s Encrypt).
Services → Caddy Web Server → Reverse Proxy → Domains → Add:
▸ Domain: `app.example.com`
▸ Port: 443
▸ Save.
Services → Caddy Web Server → Reverse Proxy → Handlers → Add:
▸ Domain: wybierz skonfigurowaną wcześniej domenę
▸ Handle path: `/`
▸ Upstream: `10.0.0.10`, port `9000`, transport HTTP
▸ Save.
Kliknij Apply u góry strony. Caddy uruchomi się, uzyska certyfikat przez ACME i rozpocznie działanie jako reverse proxy.
Services → Caddy Web Server → Diagnostics → Logs pozwala śledzić proces wystawiania certyfikatu i ewentualne błędy.
Pre-flight z powłoki OPNsense (przed konfiguracją Caddy):
```
curl -v http://10.0.0.10:9000
```
Jeśli to polecenie nie działa, oznacza to, że tunel WireGuard nie przenosi ruchu do backendu — najpierw napraw ten problem.
Usługa backendowa powinna nasłuchiwać na adresie tunelowym lub `0.0.0.0`, a nie wyłącznie na `127.0.0.1`. Backend otrzymuje żądania jako czysty HTTP od adresu tunelu OPNsense (`10.0.0.1`). Caddy automatycznie ustawia nagłówki `X-Forwarded-For`, `X-Forwarded-Proto` i `X-Forwarded-Host`; backendy wymagające oryginalnego adresu IP klienta powinny ufać tym nagłówkom.
━━━━━━━━━━━━━━━━━━━━
▌ Co ten setup zastępuje — a czego nie
Ten setup zastępuje:
▸ terminację TLS (jak w Cloudflare)
▸ reverse proxy
▸ obsługę HTTP/2 do backendu
Nie zastępuje natomiast:
▸ globalnego routingu anycast — VPS działa w jednej lokalizacji
▸ wieloterabitowej ochrony przed DDoS wolumetrycznym
▸ zarządzanej biblioteki reguł WAF (OWASP CRS, bot management, kuratorowane reguły Cloudflare, zaawansowane dopasowania regex)
Pierwsze dwa wymagają infrastruktury o rzędy wielkości droższej niż 10 €/miesiąc. Mają znaczenie głównie dla systemów stale narażonych na ataki dużej skali; dla większości wdrożeń self-hosted nie są krytyczne.
Trzeci element — reguły WAF — można w dużej mierze odtworzyć przy użyciu komponentów open source w OPNsense:
▸ CrowdSec — plugin (os-crowdsec) łączący analizę behawioralną z community-kuratorowaną blocklistą. Wykrywa m.in. credential stuffing, scraping i skanowanie, przekazując adresy IP do aliasów OPNsense, gdzie są blokowane przez pf.
▸ System aliasów i reguł OPNsense — natywne wsparcie dla rate limiting, geoblokowania i ACL opartych o adres IP.
▸ Matchery Caddy — reguły na poziomie reverse proxy (ścieżka, nagłówki, metody, regex), umożliwiające filtrację ruchu per endpoint.
▸ Współczesne LLM — mogą generować zestawy reguł firewalli i matcherów Caddy na podstawie opisu powierzchni ataku. Koszt ręcznego pisania reguł znacząco spadł — dziś to często kwestia dobrze sformułowanego promptu.
Największa różnica względem zarządzanego WAF to utrzymanie reguł w czasie. Wartość Cloudflare leży nie tylko w samych regułach, ale w ich ciągłej aktualizacji. CrowdSec częściowo tę lukę wypełnia.
━━━━━━━━━━━━━━━━━━━━
▌ Podsumowanie
Konfiguracja zajmuje około pół dnia uważnej pracy. Kluczowe obserwacje:
▸ Para kluczy instancji OPNsense jest generowana automatycznie — ręcznie generuje się je tylko po stronie klientów.
▸ Semantyka `AllowedIPs` jest asymetryczna: po stronie serwera — wąskie `/32`, po stronie klienta — szerokie `/24` lub `0.0.0.0/0`.
▸ `Tunnel Address` zawiera wyłącznie adres OPNsense, z maską `/24`.
▸ Interfejs `wg` należy przypisać jako osobny interfejs — nie polegać na grupie WireGuard dla reguł firewalla.
▸ `wg show` odzwierciedla rzeczywisty stan — GUI może wprowadzać w błąd.
▸ GUI należy przenieść z WAN przed wdrożeniem Caddy.
▸ Każdy interfejs poza LAN działa w trybie default-deny — wymagane są jawne reguły Pass.
Efektem jest prosty i przejrzysty stos brzegowy: jeden VPS, jeden tunel, jedno reverse proxy. Każdy element jest w pełni kontrolowalny, a koszt utrzymania pozostaje na poziomie jednocyfrowych euro miesięcznie — zamiast 20–200 USD za domenę w płatnych planach Cloudflare.
━━━━━━━━━━━━━━━━━━━━
▌ Coda: multiwersum materializujące się w obwodach sieci
Manifest XCDR — Travelers Through Multiverses — opisuje współczesne subkultury jako dynamiczne, sieciowe „multiwersa”, które okresowo materializują się w realnej, współdzielonej obecności.
Koncert na Stadionie Narodowym, bal steampunkowy na opuszczonym dworcu, liturgia w cyfrowej katedrze — każde z tych wydarzeń staje się chwilowym, konkretnym światem, współtworzonym przez uczestników. Cyfrowy rój dąży do ucieleśnienia — a w momencie jego osiągnięcia znaczenie staje się namacalne.
Opisany tu setup to infrastrukturalny odpowiednik takiego „lądowania”.
Technicznie: tunel WireGuard między VPS-em za 10 € a prywatną siecią.
Praktycznie: prywatny, zaszyfrowany, niskolatencyjny LAN rozciągnięty ponad granicami.
To, co umożliwia:
▸ Serwery gier multiplayer — https://NewVegas.XCDR.online - hostowane lokalnie, dostępne globalnie, bez pośredników.
▸ Prywatna komunikacja głosowa i wideo — Teamspeak, Jitsi Meet, Mumble - bez przechodzenia przez publiczne usługi.
▸ Trwałe światy wirtualne — fizycznie ulokowane, lecz globalnie dostępne.
▸ Streaming średniej skali — https://XCDR.tv - setki użytkowników przy 10 Gbps.
▸ Współdzielone przestrzenie pracy — dostępne wyłącznie przez tunel.
Ekonomia ma tu znaczenie: koszt na poziomie subskrypcji streamingowej daje dostęp do infrastruktury, która jeszcze niedawno wymagała budżetu korporacyjnego.
W świecie płynnej nowoczesności (Bauman) i heterotopii (Foucault) taki prywatny LAN staje się przestrzenią autonomii — miejscem, gdzie reguły ustalają uczestnicy, nie algorytmy.
To nie jest już ciekawostka. To praktyczny, dostępny sposób budowania własnych środowisk cyfrowych.
Nie jesteśmy konsumentami.
Jesteśmy uczestnikami.
---
✅ Jeśli ta perspektywa była dla Ciebie wartościowa — udostępnij, skomentuj lub obserwuj.
https://opnsense.org/
https://the.hosting/
https://www.wireguard.com/
https://caddyserver.com/
https://letsencrypt.org/
https://crowdsec.net/
https://www.freebsd.org/
https://www.unbound.net/
https://www.openbsd.org/faq/pf/ (pf firewall documentation)
https://datatracker.ietf.org/doc/html/rfc7858 (DNS over TLS / context DNS modern stack)
https://www.facebook.com/photo.php?fbid=1301229018439870&set=pb.100056583529916.-2207520000&type=3 Travelers Through Multiverses
via https://www.linkedin.com/pulse/dein-eigenes-cloudflare-f%C3%BCr-10-monat-opnsense-als-reverse-proxy-7zh5f/
