# Cloudflare Zero Trust 터널을 이제야 이해했다 > Clean Markdown view of GeekNews topic #24429. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24429](https://news.hada.io/topic?id=24429) - GeekNews Markdown: [https://news.hada.io/topic/24429.md](https://news.hada.io/topic/24429.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-17T22:33:31+09:00 - Updated: 2025-11-17T22:33:31+09:00 - Original source: [david.coffee](https://david.coffee/cloudflare-zero-trust-tunnels) - Points: 2 - Comments: 1 ## Topic Body - **Cloudflare Zero Trust와 Warp**를 활용해 NAT·방화벽 문제 없이 사설 네트워크를 연결하고 서비스 접근을 제어하는 구조 설명 - **Argo 터널**을 통해 사설 네트워크나 로컬 서비스를 공용 도메인으로 노출하거나, Warp 연결 시에만 접근 가능한 **비공개 네트워크** 구성 가능 - **Tailscale**은 P2P 기반으로 빠르지만 NAT 환경에서 제약이 있고, Cloudflare는 모든 트래픽을 **엣지 네트워크**를 통해 라우팅해 안정적 연결 제공 - **Cloudflared**는 터널 생성, **Warp Client**는 네트워크 접속 및 정책 적용을 담당하며, **Tunnels·Routes·Targets**로 트래픽 흐름과 접근 제어를 구성 - 이메일·GitHub 로그인 등으로 세밀한 **Access Policy**를 설정해, Warp 연결 여부에 따라 로그인 절차를 생략하거나 제한하는 **보안 네트워크 환경** 구축 --- ### Cloudflare Zero Trust와 Warp 개요 - Tailscale의 NAT 관통 실패로 인해 **Cloudflare Zero Trust + Warp** 학습을 시작 - Zero Trust 터널을 통해 사설 네트워크 연결, 서비스 공개, 사설 IP 네트워크 구성, 로컬 서비스 임시 공개 등 다양한 기능 활용 가능 - NAT 문제 없이 Cloudflare 네트워크를 통해 모든 트래픽이 전달되며, **세분화된 접근 정책**으로 사용자·봇·서버 간 접근 제어 가능 - SSH 접속 시 공개 포트 없이 **Zero Trust 인증 기반 로그인** 지원 ### Cloudflare Zero Trust vs Tailscale - **Tailscale**은 NAT·방화벽을 우회해 P2P 연결을 시도하며, 불가능할 경우 중계 서버 사용 - **Cloudflare**는 Warp-to-Warp를 제외한 모든 트래픽이 **Cloudflare 엣지 서버**를 거쳐 전달되어 NAT 문제는 없지만 약간의 지연 발생 ### Cloudflared와 Warp의 차이 - **Warp Client**: 클라이언트를 Cloudflare 네트워크에 연결하고 정책을 적용하는 도구 - 주로 클라이언트에서 실행되며, 서버에서도 사용 가능 - Warp-to-Warp 라우팅으로 P2P 연결 지원 - **Cloudflared**: 터널을 생성해 Zero Trust 네트워크에 추가하는 도구 - 서버에서 실행해 네트워크 진입점을 제공 - `cloudflared access` 명령으로 다른 Zero Trust 리소스에 연결 가능 - 일회성 테스트용 터널 생성 가능 ### Tunnels, Routes, Targets 구조 - **Tunnels**: `cloudflared`로 배포되는 트래픽 출구 지점 - 예: 홈 네트워크(192.168.1.1/24)에 항상 켜진 장비에 설치 - 설정 파일(`/etc/cloudflared/config.yml`)에서 요청 도착 시 라우팅 대상 지정 - 예시: `gitlab.widgetcorp.tech` → `localhost:80`, `gitlab-ssh` → `localhost:22` - **공용 노출 예시**: - `homeassistant.mydomain.com` → `192.168.1.3`으로 라우팅 - Cloudflare DNS에서 `CNAME`을 터널 주소로 지정하면 Warp 없이도 접근 가능 - **Routes**: 특정 IP 범위를 어떤 터널로 보낼지 정의 - 예: `192.168.1.1/24` 전체 또는 `192.168.1.3/32` 단일 IP 지정 - Warp 연결 시 해당 IP 요청이 Cloudflare 네트워크를 통해 터널로 전달 - 존재하지 않는 가상 IP(예: 10.128.1.1)도 라우팅 가능 - **Targets**: 보호할 인프라 단위를 정의 - 예: `homeassistant.mydomain.com` → `192.168.1.3/32` - 대상에 접근 정책을 부여해 특정 사용자만 접근 가능 ### Access Policies: 접근 제어 - 터널, 라우트, 타깃을 구성한 후 **Access Policy**로 접근 권한 설정 - 정책 구성 요소 - **Include**: 접근 허용 조건(OR) - **Require**: 반드시 충족해야 하는 조건(AND) - **Action**: Allow / Deny / Bypass / Service Auth - **예시 1 – 이메일 기반 접근 제어** - 특정 이메일 주소만 접근 허용 - GitHub 로그인 방식으로 인증 제한 가능 - **예시 2 – Warp 연결 시 로그인 생략** - Gateway 선택자를 사용해 Zero Trust Warp 연결 시 로그인 화면 생략 - Warp 미연결 시에는 GitHub 로그인 요구 ### Warp 클라이언트 배포 및 등록 - **Settings → Warp Client**에서 등록 정책 설정 - GitHub 인증 및 특정 이메일만 등록 허용 - WARP 인증 ID 설정 시 Gateway 선택자 사용 가능 - **Profile Settings**에서 클라이언트 동작 정의 - 프로토콜(MASQUE/WireGuard), 서비스 모드, 라우팅 제외 IP 등 설정 - Cloudflare CA 자동 설치, 고유 CGNAT IP 할당, 디바이스 상태 점검(Device Posture) 설정 가능 - Warp 클라이언트 로그인 후 Zero Trust 네트워크 연결 완료 - 이후 `192.168.1.3` 요청이 터널을 통해 라우팅됨 ### 구축 결과 요약 - GitHub 및 이메일 기반 로그인 정책으로 Warp 클라이언트 등록 - 사설 네트워크 내 터널이 `homeassistant.mydomain.com` 요청을 `192.168.1.3`으로 전달 - `192.168.1.3` 트래픽은 Warp 연결 시에만 터널을 통해 접근 가능 - DNS 기반 공개 접근과 Warp 기반 비공개 접근 두 가지 방식 제공 - Warp 연결 시 로그인 생략, 미연결 시 GitHub 인증 요구 ### 추가로 다루지 않은 항목 - Warp-to-Warp 라우팅 - Zero Trust 내부 전용 사설 IP 생성 - SSH 인증 정책 구성 - Self-Hosted 외의 애플리케이션 유형 원문에 추가 정보 없음 ## Comments ### Comment 46457 - Author: neo - Created: 2025-11-17T22:33:32+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45946865) - Cloudflare는 **TLS 종료 지점**으로 동작하기 때문에 개인 사용에는 불리함 Tailscale Funnel을 쓰면 인증서가 내 엔드포인트에 직접 설치되지만, Cloudflare는 트래픽을 중간에서 복호화하고 다시 암호화함 WARP의 개인 네트워크 프라이버시 수준은 잘 모르겠지만, 인터넷 터널링 시 **프라이버시 저하**가 크다고 생각함 또한 **P2P 연결 + 릴레이 폴백** 구조가 제3자 중계 없이도 동작하므로 훨씬 바람직하다고 봄 - 최근에 [TunnelBuddy](https://www.tunnelbuddy.net)라는 프로젝트를 직접 만들었음 친구의 머신을 **WebRTC 기반 exit node**로 사용하는 구조이며, TURN/relay 서버 없이 P2P만 지원함 NAT 환경에 따라 연결 성공률은 낮지만, 트래픽이 제3자 서버를 거치지 않아 **프라이버시 보장**이 확실함 - “Zero Trust”라면서 결국 **Cloudflare를 전적으로 신뢰**해야 하는 구조라는 점이 아이러니함 - 개인적으로는 Tailscale을 더 신뢰하지만, Cloudflare의 **커스텀 도메인**과 **클라이언트 없는 접근** 기능은 매력적임 Caddy로 비슷하게 구성할 수도 있지만, 여전히 포트 포워딩이 필요함 - [awesome-tunneling 리스트](https://github.com/anderspitman/awesome-tunneling)에 있는 **NetFoundry**도 좋은 대안임 종단 간 암호화와 100개 이상의 PoP를 통한 **성능·신뢰성** 확보가 장점임 - [connet](https://github.com/connet-dev/connet)은 **P2P + 릴레이 폴백** 구조를 목표로 함 참여 피어만 엔드포인트를 노출하므로 보안·프라이버시 측면에서 유리함 직접 호스팅하거나 [공식 서비스](https://connet.dev)를 사용할 수 있음 - 나는 집과 개인용으로 [Netbird](https://netbird.io/)를 사용 중임 Synology NAS, 가족의 모든 노트북·데스크탑·모바일에 설치했고, **Tmux 환경**에서 원격 데스크탑처럼 활용하기 편리함 - “모든 트래픽이 Cloudflare 네트워크를 거친다”는 문장에서 읽기를 멈췄음 [Hyprspace](https://github.com/alecbcs/hyprspace)는 내가 만난 모든 NAT를 뚫었고, **대기업 인프라 없이도** 잘 작동함 - 글이 정말 훌륭한 **구성 가이드**처럼 느껴짐 Cloudflare가 이걸 문서화해서 공식 가이드로 써도 좋을 것 같음 - Tailscale이 NAT 환경에서 P2P 연결을 못 잡을 때 답답해서 Cloudflare Zero Trust + Warp를 배워봤다는 글을 읽었음 그런데 Cloudflare는 애초에 P2P를 시도조차 안 하고, 결국 **Cloudflare 신뢰 모델**로 전환하는 셈임 동기는 이해하기 어렵지만, 글 자체는 잘 정리되어 있음 - Cloudflare는 전 세계에 **고품질 PoP 네트워크**를 갖고 있어서, 실제로는 P2P보다 품질이 더 좋았음 우리 회사도 전면 원격인데 Tailscale에서 Cloudflare로 옮긴 뒤 성능이 향상됨 - Cloudflare 경유 시에도 피어 간 암호화가 유지되는지가 핵심임 유지된다면 신뢰 모델 차이는 크지 않지만, Cloudflare는 **릴레이 성능**이 주력이라 속도 면에서는 유리함 그래도 Tailscale의 **NAT 홀 펀칭** 능력은 뛰어나서 가능하면 직접 연결을 선호함 - 개인 서비스 노출용으로 [tuns.sh](https://tuns.sh)를 사용 중임 SSH 터널 기반이라 **설치 없이 바로 사용** 가능한 점이 마음에 듦 - 글과 댓글 모두 유익했음 다만 본문 이미지가 깨져서 404 오류가 남 — 예: [targets-config-screen.png](https://david.coffee/targets-config-screen.png) - CF의 **골드 이슈**에 대해 드디어 비판이 나와서 반가움 Zero Trust 모델의 문제점을 짚어주는 논의가 필요하다고 생각함 - 무료 Cloudflare 계정으로는 **Plex 서버**를 운영할 수 없다는 점이 치명적임 관련 약관은 [여기](https://www.cloudflare.com/service-specific-terms-application-services/#content-delivery-network-terms)에서 확인 가능함 - 혹시 ISP에서 **IPv6**를 제공받고 있는지? 나는 IPv6 기반으로 Emby와 Jellyfin을 친구들과 잘 쓰고 있음 - 누가 무료로 **비디오 스트리밍 트래픽**을 제공해주길 기대하겠음? 단순 웹 트래픽과 달리 영화 한 편이면 수백 배의 대역폭 비용이 발생함 - 내 무료 계정에서는 **cloudflared tunnel**로 Jellyfin이 잘 작동함 여자친구의 업무용 노트북엔 Tailscale 설치가 안 돼서 이 방식이 유용했음 - 실제로는 트래픽이 많지 않으면 **약관이 엄격히 적용되지 않음** - 나도 Jellyfin에 쓰고 있는데 몇 달째 문제없이 잘 동작 중임 - Cloudflare 사용이 **벤더 종속(vendor lock-in)** 아닌가 하는 의문이 있음 Tailscale은 적어도 그런 종속이 없다고 생각함 - 그런데 Tailscale도 결국 **상용 벤더**였다는 걸 알고 놀랐음 오픈소스 프로젝트인 줄 알았는데 아니었음