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 컨테이너 마스터링까지.

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

💡

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

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

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

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

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

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

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

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

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

전통적인 홈랩 아키텍처 다이어그램: 포트 포워딩 워크플로우 — 인터넷, 라우터, 리버스 프록시, 도커 컨테이너

왜 ZimaCube 2인가

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

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

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

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

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

이 시점에서 ZimaCube 2는 사실상 하나의 기계에 네 가지 기능이 결합된 형태가 되었습니다: 도커 호스트, 리버스 프록시 플랫폼, 인그레스 레이어, 그리고 중앙 집중식 인프라 장치. 현대적인 셀프 호스팅에 이 조합은 매우 실용적입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

새 아키텍처

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

Cloudflare Tunnel은 Cloudflare 엣지로의 아웃바운드 전용 암호화 연결을 생성합니다.
Nginx Proxy Manager가 라우팅, SSL 종료 및 ACL을 처리합니다.
Docker 브리지 네트워크가 엣지 트래픽과 내부 워크로드를 분리합니다.
인바운드 NAT 규칙 0개 — 라우터는 어떤 서비스도 제공되고 있는지 전혀 모릅니다.

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

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

Cloudflare Tunnel, Nginx Proxy Manager 및 종단 간 TLS 암호화를 사용하는 ZimaCube 2에서 실행되는 최종 보안 홈랩 아키텍처 다이어그램

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

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

docker network create \

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

엣지

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

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

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

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

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

설정은 처음에는 간단해 보였습니다. Cloudflare Tunnel과 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 터널을 오리진 서버 이름: example.com으로 구성하되 내부적으로는 계속 라우팅하도록 설정 https://reverse-proxy:443. 이는 암호화된 전송을 유지하고, 올바른 호스트명 검증과 완전한 TLS 검증을 제공하며 — 어떤 보안 검사도 비활성화하지 않았습니다.

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

Cloudflare SSL/TLS 개요 관리자 패널, 전체 엄격 암호화 모드, 브라우저에서 오리진 서버로의 트래픽 암호화 다이어그램

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

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

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

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

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

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

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

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

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

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

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

최종 스택

현재 ZimaCube 2에서 실행 중인 것:

Cloudflare 터널 — 아웃바운드 전용 암호화 연결, 포트 전혀 개방하지 않음
Nginx Proxy Manager — 리버스 프록시, SSL, ACL 관리
도커 브리지 네트워크 — 엣지 트래픽과 내부 트래픽 분리
종단 간 TLS — 클라이언트에서 오리진까지 암호화, 어디에도 평문 없음
숨겨진 오리진 — 공개 IP에서 응답하지 않음

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

이 프로젝트에서 얻은 가장 큰 깨달음: 현대적 셀프 호스팅은 점점 더 프로덕션 인프라에서 사용하는 인그레스, 네트워킹, 신뢰 경계 개념을 요구합니다. 그리고 하드웨어도 이에 맞춰 조용하고, 신뢰할 수 있으며, 네트워크 연결이 항상 유지되어야 합니다.

현대 홈랩 인그레스 아키텍처 다이어그램: 아웃바운드 전용 Cloudflare 터널 설계와 위험한 전통적 포트 포워딩 설정 비교

ZimaCube 2가 바로 그 역할을 완벽히 수행합니다.

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

자주 묻는 질문

Cloudflare 터널이란 무엇이며 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 하드웨어에서는 불가능한 기능입니다.