▲

Cloudflare Zero Trust 터널을 이제야 이해했다

 (david.coffee)
2P by GN⁺ 17일전 | ★ favorite | 댓글 1개
  • 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 외의 애플리케이션 유형

원문에 추가 정보 없음

▲
GN⁺ 17일전  [-]
Hacker News 의견

  • Cloudflare는 TLS 종료 지점으로 동작하기 때문에 개인 사용에는 불리함
    Tailscale Funnel을 쓰면 인증서가 내 엔드포인트에 직접 설치되지만, Cloudflare는 트래픽을 중간에서 복호화하고 다시 암호화함
    WARP의 개인 네트워크 프라이버시 수준은 잘 모르겠지만, 인터넷 터널링 시 프라이버시 저하가 크다고 생각함
    또한 P2P 연결 + 릴레이 폴백 구조가 제3자 중계 없이도 동작하므로 훨씬 바람직하다고 봄

    • 최근에 TunnelBuddy라는 프로젝트를 직접 만들었음
      친구의 머신을 WebRTC 기반 exit node로 사용하는 구조이며, TURN/relay 서버 없이 P2P만 지원함
      NAT 환경에 따라 연결 성공률은 낮지만, 트래픽이 제3자 서버를 거치지 않아 프라이버시 보장이 확실함
    • “Zero Trust”라면서 결국 Cloudflare를 전적으로 신뢰해야 하는 구조라는 점이 아이러니함
    • 개인적으로는 Tailscale을 더 신뢰하지만, Cloudflare의 커스텀 도메인과 클라이언트 없는 접근 기능은 매력적임
      Caddy로 비슷하게 구성할 수도 있지만, 여전히 포트 포워딩이 필요함
    • awesome-tunneling 리스트에 있는 NetFoundry도 좋은 대안임
      종단 간 암호화와 100개 이상의 PoP를 통한 성능·신뢰성 확보가 장점임
    • connet은 P2P + 릴레이 폴백 구조를 목표로 함
      참여 피어만 엔드포인트를 노출하므로 보안·프라이버시 측면에서 유리함
      직접 호스팅하거나 공식 서비스를 사용할 수 있음

  • 나는 집과 개인용으로 Netbird를 사용 중임
    Synology NAS, 가족의 모든 노트북·데스크탑·모바일에 설치했고, Tmux 환경에서 원격 데스크탑처럼 활용하기 편리함

  • “모든 트래픽이 Cloudflare 네트워크를 거친다”는 문장에서 읽기를 멈췄음
    Hyprspace는 내가 만난 모든 NAT를 뚫었고, 대기업 인프라 없이도 잘 작동함

  • 글이 정말 훌륭한 구성 가이드처럼 느껴짐
    Cloudflare가 이걸 문서화해서 공식 가이드로 써도 좋을 것 같음

  • Tailscale이 NAT 환경에서 P2P 연결을 못 잡을 때 답답해서 Cloudflare Zero Trust + Warp를 배워봤다는 글을 읽었음
    그런데 Cloudflare는 애초에 P2P를 시도조차 안 하고, 결국 Cloudflare 신뢰 모델로 전환하는 셈임
    동기는 이해하기 어렵지만, 글 자체는 잘 정리되어 있음

    • Cloudflare는 전 세계에 고품질 PoP 네트워크를 갖고 있어서, 실제로는 P2P보다 품질이 더 좋았음
      우리 회사도 전면 원격인데 Tailscale에서 Cloudflare로 옮긴 뒤 성능이 향상됨
    • Cloudflare 경유 시에도 피어 간 암호화가 유지되는지가 핵심임
      유지된다면 신뢰 모델 차이는 크지 않지만, Cloudflare는 릴레이 성능이 주력이라 속도 면에서는 유리함
      그래도 Tailscale의 NAT 홀 펀칭 능력은 뛰어나서 가능하면 직접 연결을 선호함

  • 개인 서비스 노출용으로 tuns.sh를 사용 중임
    SSH 터널 기반이라 설치 없이 바로 사용 가능한 점이 마음에 듦

  • 글과 댓글 모두 유익했음
    다만 본문 이미지가 깨져서 404 오류가 남 — 예: targets-config-screen.png

  • CF의 골드 이슈에 대해 드디어 비판이 나와서 반가움
    Zero Trust 모델의 문제점을 짚어주는 논의가 필요하다고 생각함

  • 무료 Cloudflare 계정으로는 Plex 서버를 운영할 수 없다는 점이 치명적임
    관련 약관은 여기에서 확인 가능함

    • 혹시 ISP에서 IPv6를 제공받고 있는지?
      나는 IPv6 기반으로 Emby와 Jellyfin을 친구들과 잘 쓰고 있음
    • 누가 무료로 비디오 스트리밍 트래픽을 제공해주길 기대하겠음?
      단순 웹 트래픽과 달리 영화 한 편이면 수백 배의 대역폭 비용이 발생함
    • 내 무료 계정에서는 cloudflared tunnel로 Jellyfin이 잘 작동함
      여자친구의 업무용 노트북엔 Tailscale 설치가 안 돼서 이 방식이 유용했음
    • 실제로는 트래픽이 많지 않으면 약관이 엄격히 적용되지 않음
    • 나도 Jellyfin에 쓰고 있는데 몇 달째 문제없이 잘 동작 중임

  • Cloudflare 사용이 벤더 종속(vendor lock-in) 아닌가 하는 의문이 있음
    Tailscale은 적어도 그런 종속이 없다고 생각함

    • 그런데 Tailscale도 결국 상용 벤더였다는 걸 알고 놀랐음
      오픈소스 프로젝트인 줄 알았는데 아니었음
답변달기