What is a Cloudflare Tunnel and why would I use it on my ZimaCube 2?

A Cloudflare Tunnel creates an outbound-only encrypted connection from your ZimaCube 2 to Cloudflare edge network. Instead of opening ports on your router (which exposes your infrastructure to the internet), all traffic flows through this encrypted tunnel. Your origin server — the ZimaCube 2 — remains completely hidden from public view.

Do I need to open any ports on my router for this setup?

No. That is the point. Cloudflare Tunnel only makes outbound connections. Your router does not need a single port forward rule. This eliminates the most common attack vector in [homelab networking](https://shop.zimaspace.com/blogs/zima-campaign-hub/ultimate-homelab-hardware-guide-self-hosting "Building a Homelab: Top Hardware Picks for Beginners to Pros").

Can the ZimaCube 2 handle running a reverse proxy and all my services at the same time?

Yes. Michael ZC2 runs Cloudflare Tunnel, Nginx Proxy Manager, and 10+ Docker containers simultaneously — all while maintaining quiet, cool operation. The dual 2.5GbE ports and NVMe storage ensure networking and container I/O do not become bottlenecks.

Why does Docker network segmentation matter?

If every container shares the same network, one compromised service gives an attacker a path to everything else. By placing only Cloudflare Tunnel and Nginx Proxy Manager on an "edge" network (and keeping applications on separate internal networks), you create a controlled boundary between public-facing traffic and your private services.

What was the TLS hostname mismatch issue?

When Cloudflare Tunnel connected to Nginx Proxy Manager internally using a Docker hostname like reverse-proxy, the TLS certificate — which was issued for a public domain like example.com — did not match. The fix was configuring Cloudflare Tunnel to use the correct Origin Server Name while still routing to the internal Docker hostname. This preserved full encryption without disabling validation.

How does the ZimaCube 2 networking hardware compare to a standard NAS for this use case?

Most consumer NAS devices ship with a single gigabit Ethernet port. The ZimaCube 2 has dual 2.5GbE — which means you can dedicate one interface to edge traffic (Cloudflare + reverse proxy) and the other to internal services. This physical-layer separation is something you cannot achieve on single-NIC hardware.

Jak przekształciłem ZimaCube 2 w kontroler wejścia Zero-Trust dla całego mojego homelabu

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How I Turned the ZimaCube 2 Into a Zero-Trust Ingress Controller for My Entire Homelab - Zima Store Online

💡

Społeczność w centrum uwagi: Michael Luckenbill, Program Pionierów ZimaCube 2

Twój homelab ma frontowe drzwi. Jeśli jesteś jak większość self-hosterów, te drzwi to przekierowanie portu na routerze — i są szeroko otwarte.

Spędziłem tygodnie na przebudowie mojego systemu. Efekt: warstwa ingress klasy produkcyjnej działająca całkowicie na ZimaCube 2. Brak otwartych portów na moim routerze. Brak publicznie dostępnych serwerów źródłowych. Szyfrowanie end-to-end TLS na każdym połączeniu. Wszystko to działa cicho obok mojego telewizora.

Oto dokładnie jak to zbudowałem, co się zepsuło po drodze i dlaczego ZimaCube 2 okazał się idealną platformą do tego zadania.

Problem z tradycyjnym ingress w homelabie

Wiele homelabów nadal wygląda tak:

Port 443 przekierowany na routerze → wskazuje na reverse proxy
Port 80 przekierowany → przekierowuje na 443
Usługi są bezpośrednio dostępne, jeśli znasz IP
Infrastruktura źródłowa jest o jedno skanowanie portów od wykrycia

To tworzy prawdziwe problemy. Publicznie otwarte porty ingress. Bezpośrednio dostępne serwery źródłowe. Interfejsy administracyjne odpowiadające przed uwierzytelnieniem. Nawet z HTTPS infrastruktura pozostaje widoczna — a widoczność zaprasza do rozpoznania.

Chciałem zupełnie innego modelu. Czegoś bliższego temu, jak nowoczesna infrastruktura chmurowa obsługuje ingress: zaufanie tylko do ruchu wychodzącego, brak ekspozycji przychodzącej i zaszyfrowane tunele ukrywające źródło.

Tradycyjny schemat architektury Homelab pokazujący przepływ port forwarding: Internet, router, reverse proxy i kontenery Docker

Dlaczego ZimaCube 2

Taka architektura wymaga specyficznych cech sprzętu. Nie surowej mocy — niezawodności, elastyczności i ciszy.

ZimaCube 2 spełnił wszystkie wymagania:

Zawsze włączony: Cicha praca 24/7.
Warstwa ingress musi działać nieprzerwanie — projekt termiczny ZC2 pozwala na to bez dominacji w pomieszczeniu.

Podwójne 2,5GbE: Jeden interfejs dla sieci brzegowej, drugi dla sieci wewnętrznej. Segmentacja ruchu zaczyna się na warstwie fizycznej, nie tylko w Dockerze.

Docker natywny: pamięć NVMe dla szybkiego I/O kontenerów. Wiele sieci mostkowych nie obciąża systemu. Platforma została do tego stworzona.

W tym momencie ZimaCube 2 stał się w praktyce czterema urządzeniami w jednej maszynie: hostem Dockera, platformą reverse proxy, warstwą ingress oraz scentralizowanym urządzeniem infrastrukturalnym. Dla nowoczesnego self-hostingu takie połączenie jest niezwykle praktyczne.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Nowa architektura

Zamiast otwierać porty na routerze, nowy projekt działa tak:

Cloudflare Tunnel tworzy tylko wychodzące, szyfrowane połączenia do krawędzi Cloudflare
Nginx Proxy Manager obsługuje routing, terminację SSL i ACL
Mostkowe sieci Docker segmentują ruch brzegowy od wewnętrznych obciążeń
Zero reguł NAT przychodzących — router nie ma pojęcia, że coś jest serwowane

🔒 Infrastruktura źródłowa jest całkowicie ukryta. Cloudflare stoi przed całym ruchem publicznym. ZimaCube 2 nawiązuje tylko połączenia wychodzące. Nic nie nasłuchuje na publicznym porcie.

Od razu poczułem, że to bliższe nowoczesnej architekturze chmurowej niż tradycyjnemu samodzielnemu hostowaniu z przekierowaniem portów.

Ostateczny diagram bezpiecznej architektury homelab działającej na ZimaCube 2 z Cloudflare Tunnel, Nginx Proxy Manager i szyfrowaniem TLS end-to-end

Segmentacja sieci Docker: Edge ≠ Wewnętrzna

Jedną z najważniejszych zmian było oddzielenie ruchu za pomocą mostkowych sieci Docker.

docker network create \

--subnet 172.x.x.x/24 \

edge

Sieć brzegowa obsługuje dokładnie dwa kontenery: Cloudflare Tunnel i Nginx Proxy Manager. Tylko tyle. Aplikacje działają na oddzielnych wewnętrznych sieciach Docker — całkowicie izolowanych od warstwy wejściowej.

🎁 Nie każdy kontener powinien być dostępny z internetu. Jeśli twój serwer Plex, instancja Vaultwarden lub runner CI/CD dzieli sieć z twoim reverse proxy, jedno naruszone usługi dają atakującemu dostęp do wszystkiego innego.

ZimaCube 2 radzi sobie z tym segmentowaniem bez problemu. Wiele sieci mostkowych nie powoduje obciążenia wydajnościowego na platformie, a pamięć NVMe zapewnia szybkie uruchamianie kontenerów i operacje sieciowe nawet gdy topologia sieci staje się bardziej złożona.

Problem z TLS, który prawie mnie złamał

To okazało się najciekawszą lekcją inżynierską w całym projekcie.

Konfiguracja na początku wydawała się prosta. HTTP między Cloudflare Tunnel a Nginx Proxy Manager działało od razu:

http://reverse-proxy → ✅ Działa

Więc włączyłem HTTPS.

https://reverse-proxy → ❌ Nie działa

Certyfikat był ważny. Data ważności była poprawna. Łańcuch zaufania był prawidłowy. Wszystko wyglądało dobrze — a mimo to HTTPS odmawiał połączenia.

Prawdziwym problemem była walidacja nazwy hosta TLS.

Certyfikat został wydany dla moich publicznych domen (example.com, app.example.com). Ale Cloudflare Tunnel łączył się wewnętrznie z reverse-proxy — nazwą hosta Dockera, która nie pasowała do niczego na certyfikacie. Niezgodność nazwy hosta spowodowała ciche niepowodzenie walidacji TLS.

💡 Walidacja TLS to nie tylko zaufanie do certyfikatu i jego ważność. Sprawdza także tożsamość nazwy hosta i oczekiwania SNI. Jeśli nazwa w URL nie zgadza się z nazwą na certyfikacie, połączenie nie powiedzie się — nawet jeśli wszystko inne jest w porządku.

Naprawa: skonfigurować Cloudflare Tunnel z nazwą serwera źródłowego: example.com, jednocześnie kierując ruch wewnętrznie do https://reverse-proxy:443. Zachowano zaszyfrowany transport, właściwą walidację nazwy hosta i pełną weryfikację TLS — bez wyłączania żadnych kontroli bezpieczeństwa.

To jest rodzaj lekcji, której uczysz się tylko przez praktykę.

Panel administracyjny Cloudflare SSL/TLS z trybem pełnego ścisłego szyfrowania, diagram szyfrowania ruchu przeglądarka → serwer źródłowy

ACL i lekcja o ścieżkach ruchu infrastruktury

Jedna z lekcji operacyjnych, którą szybko przyswoiłem: reverse proxy często widzą adresy IP mostka Docker, tunelu i wewnętrznych proxy zamiast oryginalnego adresu IP klienta.

Nauczyłem się tego na własnej skórze, gdy przypadkowo zablokowałem sobie dostęp do Nginx Proxy Manager.

Skonfigurowałem ACL, aby zezwalać tylko na moją podsieć LAN (192.168.x.x/24). Logika wydawała się słuszna — tylko urządzenia w mojej sieci domowej powinny mieć dostęp do panelu administracyjnego.

NPM faktycznie widział ruch z sieci mostka Docker. Nie z mojej sieci LAN. Kontrola dostępu blokowała wszystko, włącznie ze mną.

Dodanie podsieci Docker do listy dozwolonych rozwiązało problem natychmiast. Było to jednak bardzo realne przypomnienie, że ścieżki ruchu infrastruktury często różnią się od tych, które zakładamy na papierze.

🔄 W środowisku konteneryzowanym oryginalny adres IP klienta jest przepisywany na wielu etapach: krawędź Cloudflare → tunel → mostek Docker → reverse proxy. Każdy etap zmienia adres źródłowy. Twoje reguły zapory muszą uwzględniać faktyczną ścieżkę ruchu, a nie tę, którą sobie wyobrażasz.

Dlaczego ta architektura ma znaczenie na ZimaCube 2

Jest powód, dla którego ten stos działa tak dobrze właśnie na ZC2:

Podwójne 2,5GbE oznacza, że warstwa ingress ma dedykowaną przepustowość — ruch wewnętrzny nie konkuruje z usługami dostępnymi z internetu
Pamięć NVMe zapewnia szybkie sieciowanie kontenerów — przepustowość sieci mostkowej nie jest ograniczona przez wolne operacje dyskowe
Cicha praca 24/7 oznacza, że warstwa ingress działa całą dobę w przestrzeni mieszkalnej — nie w piwnicznym racku
Platforma natywna dla Dockera z wystarczającą rezerwą mocy, by jednocześnie uruchomić tunel, reverse proxy, silnik ACL i wszystkie Twoje usługi
Rozszerzalność oznacza, że możesz później dodać dedykowaną kartę sieciową lub akcelerator, jeśli Twoje potrzeby sieciowe wzrosną

ZimaCube 2 nie tylko hostuje te usługi. To właściwa platforma dla nich.

Ostateczny stos

Co teraz działa na ZimaCube 2:

Tunel Cloudflare — tylko wychodzące, szyfrowane połączenia, zero otwartych portów
Nginx Proxy Manager — reverse proxy, SSL, ACL
Sieci mostkowe Dockera — segmentacja ruchu brzegowego i wewnętrznego
End-to-end TLS — szyfrowanie od klienta do źródła, bez tekstu jawnego nigdzie
Ukryte źródło — nic nie odpowiada na publicznym IP

To nadal homelab. Ale model operacyjny teraz znacznie bardziej przypomina nowoczesne inżynierstwo ingress niż tradycyjny self-hosting z przekierowaniem portów.

Najważniejsze spostrzeżenie z tego projektu: nowoczesny self-hosting coraz częściej wymaga takiego samego podejścia do ingress, sieci i granic zaufania, jakie stosuje się w infrastrukturze produkcyjnej. A sprzęt musi nadążać — cichy, niezawodny, sieciowy i zawsze włączony.

Diagram nowoczesnej architektury homelab ingress porównujący tunel Cloudflare tylko do wychodzących połączeń z ryzykowną tradycyjną konfiguracją przekierowania portów

ZimaCube 2 dostarcza dokładnie to.

Zbuduj własny homelab zero-trust z ZimaCube 2 →

Najczęściej zadawane pytania

Czym jest tunel Cloudflare i dlaczego warto go używać na ZimaCube 2?

Cloudflare Tunnel tworzy szyfrowane połączenie wychodzące z ZimaCube 2 do sieci brzegowej Cloudflare. Zamiast otwierać porty na routerze (co naraża infrastrukturę na dostęp z internetu), cały ruch przepływa przez ten zaszyfrowany tunel. Twój serwer źródłowy — ZimaCube 2 — pozostaje całkowicie ukryty przed publicznym widokiem.

Czy muszę otwierać jakieś porty na moim routerze dla tego ustawienia?

Nie. I o to właśnie chodzi. Cloudflare Tunnel nawiązuje tylko połączenia wychodzące. Twój router nie potrzebuje żadnej reguły przekierowania portów. To eliminuje najczęstszy wektor ataku w sieciach homelab.

Czy ZimaCube 2 poradzi sobie z uruchomieniem reverse proxy i wszystkich moich usług jednocześnie?

Tak. Michael ZC2 uruchamia jednocześnie Cloudflare Tunnel, Nginx Proxy Manager i ponad 10 kontenerów Docker — wszystko to przy cichej i chłodnej pracy. Podwójne porty 2,5GbE i pamięć NVMe zapewniają, że sieć i operacje I/O kontenerów nie stanowią wąskiego gardła.

Dlaczego segmentacja sieci Docker ma znaczenie?

Jeśli wszystkie kontenery korzystają z tej samej sieci, skompromitowana usługa daje atakującemu dostęp do wszystkiego innego. Umieszczając tylko Cloudflare Tunnel i Nginx Proxy Manager w sieci „brzegowej” (a aplikacje na oddzielnych sieciach wewnętrznych), tworzysz kontrolowaną granicę między ruchem publicznym a prywatnymi usługami.

Na czym polegał problem z niezgodnością nazwy hosta TLS?

Gdy Cloudflare Tunnel łączył się z Nginx Proxy Manager wewnętrznie, używając nazwy hosta Dockera, takiej jak reverse-proxy, certyfikat TLS — wydany dla publicznej domeny, np. example.com — nie pasował. Rozwiązaniem było skonfigurowanie Cloudflare Tunnel tak, aby używał poprawnej nazwy serwera źródłowego (Origin Server Name), jednocześnie kierując ruch do wewnętrznej nazwy hosta Dockera. Zachowało to pełne szyfrowanie bez wyłączania walidacji.

Jak sprzęt sieciowy ZimaCube 2 wypada w porównaniu do standardowego NAS w tym zastosowaniu?

Większość konsumenckich urządzeń NAS jest wyposażona w pojedynczy port Ethernet gigabitowy. ZimaCube 2 ma podwójne porty 2,5GbE — co oznacza, że możesz przeznaczyć jeden interfejs na ruch brzegowy (Cloudflare + reverse proxy), a drugi na usługi wewnętrzne. Takie rozdzielenie na poziomie warstwy fizycznej jest niemożliwe do osiągnięcia na sprzęcie z pojedynczą kartą sieciową.