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.

"Dual monitor home lab workstation showing Lucky in Prod blog page, mini server tower, keyboard and coding setup on office desk

💡

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

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

Spędziłem tygodnie na przebudowie mojego. Efekt: warstwa ingress klasy produkcyjnej działająca całkowicie na ZimaCube 2. Żadne otwarte porty na moim routerze. Żadne publicznie dostępne serwery źródłowe. 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 homelabów

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 jeden skan portów od odkrycia

To tworzy prawdziwe problemy. Publicznie wystawione 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 wychodzące, zerowa ekspozycja przychodząca i szyfrowane tunele ukrywające źródło.

Dlaczego ZimaCube 2

Tego typu architektura wymaga specyficznych cech sprzętowych. 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 dominowania w pomieszczeniu.

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

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

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

Featured

ZimaCube 2 Osobista Chmura Domowy NAS

ZimaCube2

Nowa architektura

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

Cloudflare Tunnel tworzy tylko wychodzące, szyfrowane połączenia do krawędzi Cloudflare
Nginx Proxy Manager obsługuje trasowanie, zakończenie SSL i listy kontroli dostępu (ACL)
Sieci mostkowe Docker segmentują ruch krawędziowy 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 chmury niż tradycyjnemu samodzielnemu hostowaniu z przekierowaniem portów.

Segmentacja sieci Docker: Edge ≠ Internal

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

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 daje atakującemu dostęp do wszystkiego innego.

ZimaCube 2 radzi sobie z tym segmentowaniem bardzo dobrze. Wiele sieci mostkowych nie powoduje spadku wydajności na platformie, a pamięć NVMe zapewnia szybkie uruchamianie kontenerów i operacje sieciowe nawet przy rosnącej złożoności topologii sieci.

Problem 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 wygaśnięcia 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). Jednak Cloudflare Tunnel łączył się wewnętrznie z reverse-proxy — nazwą hosta Dockera, która nie odpowiadała żadnej nazwie 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 zostanie nawiązane — nawet jeśli wszystko inne jest poprawne.

Rozwiązanie: skonfiguruj 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 oraz pełną weryfikację TLS — bez wyłączania jakichkolwiek kontroli bezpieczeństwa.

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

ACL i lekcja o ścieżkach ruchu infrastruktury

Jedna operacyjna lekcja, którą szybko przyswoiłem: reverse proxy często widzą IP mostka Docker, IP tunelu i IP wewnętrznego proxy zamiast oryginalnego 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, by 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 mostkowej Dockera. Nie z mojej sieci LAN. Kontrola dostępu blokowała wszystko, włącznie ze mną.

Dodanie podsieci Dockera do listy dozwolonych rozwiązało problem natychmiast. Ale to była bardzo realna lekcja, że ścieżki ruchu infrastruktury często różnią się od tych, które zakładamy na papierze.

🔄 W środowisku kontenerowym oryginalne IP klienta jest przepisywane 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ść — twój wewnętrzny ruch sieciowy nie konkuruje z usługami skierowanymi do 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 non-stop w przestrzeni mieszkalnej — nie w piwnicznym racku
Platforma natywna dla Dockera z wystarczającą rezerwą, 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:

Cloudflare Tunnel — tylko wychodzące zaszyfrowane połączenia, zero otwartych portów
Nginx Proxy Manager — reverse proxy, SSL, ACL
Sieci mostkowe Dockera — segmentowany ruch brzegowy vs. wewnętrzny
End-to-end TLS — szyfrowanie od klienta do źródła, brak tekstu jawnego gdziekolwiek
Ukryte źródło — nic nie odpowiada na publicznym IP

To nadal homelab. Ale model operacyjny teraz znacznie bardziej przypomina nowoczesne inżynierię ingress niż tradycyjne samodzielne hostowanie z przekierowaniem portów.

Najważniejsze wnioski z tego projektu: nowoczesne self-hosting coraz częściej wymaga takiego samego podejścia do ingressu, sieci i granic zaufania, jakie stosuje się w infrastrukturze produkcyjnej. A sprzęt musi nadążać — być cichy, niezawodny, sieciowy i zawsze gotowy do pracy.

ZimaCube 2 dostarcza dokładnie to.

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

Najczęściej zadawane pytania

Czym jest Cloudflare Tunnel i dlaczego miałbym 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 internet), cały ruch przepływa przez ten zaszyfrowany tunel. Twój serwer źródłowy — ZimaCube 2 — pozostaje całkowicie ukryty przed publicznym dostępem.

Czy muszę otwierać jakieś porty na moim routerze dla tego rozwiązania?

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 w 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 warstwie fizycznej jest niemożliwe do osiągnięcia na sprzęcie z pojedynczą kartą sieciową.