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.

내 전체 홈랩을 위한 제로 트러스트 인그레스 컨트롤러로 ZimaCube 2를 변환한 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

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

💡

커뮤니티 스포트라이트: Michael Luckenbill, ZimaCube 2 파이오니어 프로그램

당신의 홈랩에는 정문이 있습니다. 대부분의 셀프 호스팅 사용자처럼, 그 정문은 라우터의 포트 포워드이며 — 완전히 열려 있습니다.

나는 몇 주간 내 시스템을 재구축했습니다. 결과는: ZimaCube 2에서 완전히 실행되는 프로덕션급 인그레스 레이어. 라우터에 열린 포트 없음. 공개적으로 접근 가능한 출처 서버 없음. 모든 연결에 종단 간 TLS 적용. 모든 것이 내 TV 옆에서 조용히 작동합니다.

내가 정확히 어떻게 구축했는지, 중간에 무엇이 고장 났는지, 그리고 왜 ZimaCube 2가 이 작업에 완벽한 플랫폼이 되었는지 설명합니다.

전통적인 홈랩 인그레스의 문제점

많은 홈랩이 여전히 이렇게 생겼습니다:

라우터에서 포트 443 포워딩 → 리버스 프록시로 연결
포트 80 포워딩 → 443으로 리디렉션
IP만 알면 서비스에 직접 접근할 수 있습니다
출처 인프라는 포트 스캔 한 번으로 발견될 수 있습니다

이것은 실제 문제를 만듭니다. 공개된 인그레스 포트, 직접 접근 가능한 출처 서버, 인증 전에 응답하는 관리자 인터페이스. HTTPS를 사용해도 인프라 자체는 여전히 노출되어 있으며 — 노출은 정찰을 초대합니다.

나는 완전히 다른 모델을 원했습니다. 현대 클라우드 인프라가 인그레스를 처리하는 방식에 더 가까운 것: 아웃바운드 전용 신뢰, 인바운드 노출 제로, 그리고 출처를 숨기는 암호화 터널.

왜 ZimaCube 2인가

이런 종류의 아키텍처는 특정 하드웨어 특성을 요구합니다. 단순한 성능이 아니라 — 신뢰성, 유연성, 그리고 무소음.

ZimaCube 2는 모든 조건을 충족했습니다:

항상 켜짐: 조용한 24시간 연속 작동.
인그레스 레이어는 계속 실행되어야 합니다 — ZC2의 열 설계 덕분에 방을 지배하지 않고도 가능합니다.

듀얼 2.5GbE: 하나는 엣지 네트워크용, 하나는 내부용 인터페이스. 트래픽 세분화는 도커뿐 아니라 물리 계층에서 시작됩니다.

도커 네이티브: 빠른 컨테이너 I/O를 위한 NVMe 스토리지. 여러 브리지 네트워크가 시스템을 막지 않습니다. 이 플랫폼은 이를 위해 설계되었습니다.

이 시점에서 ZimaCube 2는 사실상 하나의 기기에서 네 가지 역할을 수행합니다: 도커 호스트, 리버스 프록시 플랫폼, 인그레스 레이어, 중앙 집중식 인프라 장치. 현대적인 셀프 호스팅에 이 조합은 매우 실용적입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

새로운 아키텍처

라우터에서 포트를 여는 대신, 새로운 설계는 이렇게 작동합니다:

Cloudflare 터널은 Cloudflare 엣지로 향하는 아웃바운드 전용 암호화 연결을 생성합니다
Nginx 프록시 매니저는 라우팅, SSL 종료 및 ACL을 처리합니다
도커 브리지 네트워크는 내부 워크로드의 세그먼트 엣지 트래픽을 분리합니다
인바운드 NAT 규칙 0개 — 라우터는 어떤 서비스도 제공되고 있는지 전혀 알지 못합니다

🔒 오리진 인프라는 완전히 숨겨져 있습니다. Cloudflare가 모든 공개 트래픽 앞에 위치합니다. ZimaCube 2는 오직 아웃바운드 연결만 합니다. 공개 포트에서 아무것도 수신하지 않습니다.

이것은 즉시 전통적인 포트 포워딩 셀프호스팅보다 현대 클라우드 인그레스 아키텍처에 더 가까운 느낌이 들었습니다.

Docker 네트워크 분할: 엣지 ≠ 내부

가장 중요한 변경 사항 중 하나는 Docker 브리지 네트워크를 사용해 트래픽을 분리한 것입니다.

docker network create \

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

엣지

엣지 네트워크에는 정확히 두 개의 컨테이너만 있습니다: Cloudflare 터널과 Nginx Proxy Manager. 그게 전부입니다. 애플리케이션은 별도의 내부 Docker 네트워크에 존재하며, 인그레스 계층과 완전히 격리되어 있습니다.

🎁 모든 컨테이너가 인터넷에 직접 연결되어 있어서는 안 됩니다. Plex 서버, Vaultwarden 인스턴스, 또는 CI/CD 러너가 리버스 프록시와 같은 네트워크를 공유하면, 하나의 서비스가 침해될 경우 공격자가 모든 서비스에 접근할 수 있습니다.

ZimaCube 2는 이 분할을 깔끔하게 처리합니다. 여러 브리지 네트워크가 플랫폼 성능에 부담을 주지 않으며, NVMe 스토리지는 네트워크 토폴로지가 복잡해져도 컨테이너 시작과 네트워크 I/O를 빠르게 유지합니다.

나를 거의 무너뜨릴 뻔한 TLS 문제

이것이 전체 프로젝트에서 가장 흥미로운 엔지니어링 교훈이 되었습니다.

처음에는 설정이 간단해 보였습니다. Cloudflare 터널과 Nginx Proxy Manager 간 HTTP는 즉시 작동했습니다:

http://reverse-proxy → ✅ 작동함

그래서 HTTPS를 활성화했습니다.

https://reverse-proxy → ❌ 실패

인증서는 유효했습니다. 만료일도 문제없었고, 신뢰 체인도 확인되었습니다. 모든 것이 올바른 것처럼 보였지만 HTTPS 연결은 거부되었습니다.

진짜 문제는 TLS 호스트명 검증이었습니다.

인증서는 내 공개 도메인(example.com, app.example.com)에 발급되었습니다. 하지만 Cloudflare 터널은 내부적으로 인증서와 일치하지 않는 Docker 호스트명인 리버스 프록시에 연결하고 있었습니다. 호스트명 불일치로 인해 TLS 검증이 조용히 실패했습니다.

💡 TLS 검증은 단순히 인증서 신뢰와 만료일만을 확인하는 것이 아닙니다. 호스트명 신원과 SNI 기대치도 검증합니다. URL의 이름이 인증서의 이름과 일치하지 않으면, 다른 모든 것이 완벽해도 연결이 실패합니다.

해결 방법: Cloudflare 터널을 Origin Server Name: example.com으로 구성하되 내부적으로는 계속 라우팅합니다 https://reverse-proxy:443. 암호화된 전송을 유지하고, 적절한 호스트명 검증과 완전한 TLS 검증을 수행하면서도 보안 검사를 비활성화하지 않았습니다.

이런 교훈은 직접 구축해 봐야만 배울 수 있습니다.

ACL과 인프라 트래픽 경로에 관한 교훈

내가 매우 빨리 배운 운영 교훈 하나: 리버스 프록시는 종종 원래 클라이언트 IP 대신 도커 브리지 IP, 터널 IP, 내부 프록시 IP를 봅니다.

내가 실수로 Nginx Proxy Manager에서 스스로를 차단했을 때 이 사실을 뼈저리게 배웠습니다.

관리자 패널에 내 홈 네트워크의 장치만 접근하도록 LAN 서브넷(192.168.x.x/24)만 허용하는 ACL을 설정했습니다. 논리는 타당해 보였습니다.

NPM은 실제로 도커 브리지 네트워크에서 오는 트래픽을 보고 있었습니다. 내 LAN에서 오는 것이 아니었습니다. 접근 제어가 나를 포함한 모든 것을 차단했습니다.

도커 서브넷을 허용 목록에 추가하자 즉시 해결되었습니다. 하지만 인프라 트래픽 경로가 종종 우리가 종이에 그린 것과 다르다는 매우 현실적인 교훈이었습니다.

🔄 컨테이너화된 환경에서는 원래 클라이언트 IP가 여러 홉에서 재작성됩니다: 클라우드플레어 엣지 → 터널 → 도커 브리지 → 리버스 프록시. 각 홉마다 출발지 주소가 변경됩니다. 방화벽 규칙은 상상하는 경로가 아니라 실제 트래픽 경로를 고려해야 합니다.

ZimaCube 2에서 이 아키텍처가 중요한 이유

이 스택이 특히 ZC2에서 잘 작동하는 이유가 있습니다:

듀얼 2.5GbE는 인그레스 레이어에 전용 대역폭을 제공하여 내부 네트워크 트래픽이 인터넷 서비스와 경쟁하지 않습니다
NVMe 스토리지는 빠른 컨테이너 네트워킹을 보장하며, 브리지 네트워크 처리량이 느린 디스크 I/O에 병목 현상을 일으키지 않습니다
항상 조용한 상시 작동으로 인그레스 레이어가 지하실 랙이 아닌 생활 공간에서 24시간 7일 작동합니다
도커 네이티브 플랫폼으로 터널, 리버스 프록시, ACL 엔진, 모든 서비스를 동시에 실행할 충분한 여유 공간을 제공합니다
확장성은 네트워킹 요구가 커질 경우 전용 NIC나 가속기 카드를 나중에 추가할 수 있음을 의미합니다

ZimaCube 2는 단순히 이 서비스들을 호스팅하는 것뿐만 아니라, 이들을 위한 최적의 플랫폼입니다.

최종 스택

지금 ZimaCube 2에서 실행 중인 것:

클라우드플레어 터널 — 아웃바운드 전용 암호화 연결, 열린 포트 없음
엔진엑스 프록시 매니저 — 리버스 프록시, SSL, ACL
도커 브리지 네트워크 — 엣지 트래픽과 내부 트래픽 분리
종단 간 TLS — 클라이언트에서 출처까지 암호화되어 어디에도 평문이 없습니다
숨겨진 출처 — 공용 IP에서는 아무 응답도 없습니다

여전히 홈랩입니다. 하지만 운영 모델은 이제 전통적인 포트 포워딩 셀프 호스팅보다 현대적인 인그레스 엔지니어링과 훨씬 더 유사합니다.

이 프로젝트에서 얻은 가장 큰 깨달음은: 현대의 셀프 호스팅은 점점 더 프로덕션 인프라에서 찾을 수 있는 동일한 인그레스, 네트워킹, 신뢰 경계 사고를 필요로 한다는 점입니다. 그리고 하드웨어는 조용하고, 신뢰할 수 있으며, 네트워크에 연결되어 항상 켜져 있어야 합니다.

ZimaCube 2가 바로 그 요구를 충족합니다.

ZimaCube 2로 나만의 제로 트러스트 홈랩을 구축하세요 →

자주 묻는 질문

Cloudflare Tunnel이란 무엇이며, 왜 ZimaCube 2에서 사용하나요?

Cloudflare Tunnel은 ZimaCube 2에서 Cloudflare 엣지 네트워크로 향하는 아웃바운드 전용 암호화 연결을 만듭니다. 라우터에서 포트를 열어 인프라를 인터넷에 노출하는 대신, 모든 트래픽은 이 암호화된 터널을 통해 흐릅니다. 원본 서버인 ZimaCube 2는 완전히 공개 시야에서 숨겨집니다.

이 설정을 위해 라우터에서 포트를 열어야 하나요?

아니요. 그게 핵심입니다. Cloudflare Tunnel은 오직 아웃바운드 연결만 만듭니다. 라우터에 단일 포트 포워드 규칙이 필요 없습니다. 이는 홈랩 네트워킹에서 가장 흔한 공격 경로를 제거합니다.

ZimaCube 2가 리버스 프록시와 모든 서비스를 동시에 실행할 수 있나요?

네. Michael ZC2는 Cloudflare Tunnel, Nginx Proxy Manager, 10개 이상의 Docker 컨테이너를 동시에 실행하면서도 조용하고 시원한 작동을 유지합니다. 듀얼 2.5GbE 포트와 NVMe 저장장치는 네트워킹과 컨테이너 I/O 병목 현상을 방지합니다.

Docker 네트워크 분할이 왜 중요한가요?

모든 컨테이너가 동일한 네트워크를 공유하면, 하나의 서비스가 침해될 경우 공격자가 모든 서비스에 접근할 수 있습니다. Cloudflare Tunnel과 Nginx Proxy Manager만 "엣지" 네트워크에 두고 애플리케이션은 별도의 내부 네트워크에 유지함으로써, 공개 트래픽과 개인 서비스 간에 제어된 경계가 만들어집니다.

TLS 호스트명 불일치 문제란 무엇이었나요?

Cloudflare Tunnel이 내부에서 Docker 호스트명인 reverse-proxy를 사용해 Nginx Proxy Manager에 연결할 때, example.com 같은 공개 도메인용으로 발급된 TLS 인증서가 일치하지 않았습니다. 해결책은 Cloudflare Tunnel을 올바른 Origin Server Name으로 구성하면서도 내부 Docker 호스트명으로 라우팅하는 것이었습니다. 이를 통해 검증을 비활성화하지 않고도 완전한 암호화를 유지할 수 있었습니다.

이 사용 사례에서 ZimaCube 2의 네트워킹 하드웨어는 일반 NAS와 어떻게 비교되나요?

대부분의 소비자용 NAS 장치는 단일 기가비트 이더넷 포트 하나만 제공합니다. ZimaCube 2는 듀얼 2.5GbE 포트를 갖추고 있어, 하나의 인터페이스는 엣지 트래픽(Cloudflare + 리버스 프록시)에, 다른 하나는 내부 서비스에 전용할 수 있습니다. 이러한 물리적 계층 분리는 단일 NIC 하드웨어에서는 불가능한 기능입니다.