Cloudflare One 이해하기 시리즈 (8편 중 3편)
- 전체 구조와 연결 방식
- Cloudflare One Client와 Device Posture
- Tunnel, Mesh, Cloudflare WAN 비교와 적용 시나리오 (현재 글)
- Access 인증·인가와 접근 정책
- Gateway DNS·Network·HTTP 정책
- TLS Decryption과 HTTP 정책
- Browser Isolation 구조와 적용 시나리오
- DLP, Data Classification, CASB
이전 글에서 사용자 디바이스를 Cloudflare에 연결하는 Cloudflare One Client를 살펴봤습니다. 이번에는 반대편, 즉 애플리케이션과 네트워크 쪽을 Cloudflare에 연결하는 세 가지 커넥터인 Cloudflare Tunnel, Cloudflare Mesh, Cloudflare WAN을 비교합니다.
세 제품 모두 “사설 리소스를 Cloudflare에 연결한다”는 점은 같지만, 연결하는 단위 (애플리케이션, 호스트, 사이트 전체)와 트래픽 방향, 배포 방식이 다릅니다.
Cloudflare Tunnel: 아웃바운드 연결로 애플리케이션을 공개
Cloudflare Tunnel은 공인 IP (publicly routable IP) 없이 리소스를 Cloudflare에 연결합니다. 인프라에 설치한 경량 데몬 cloudflared가 Cloudflare 글로벌 네트워크로 아웃바운드 연결만 생성하고, 연결이 수립되면 그 터널을 통해 양쪽으로 트래픽이 흐릅니다.
구조
- 터널 (Tunnel): 오리진과 Cloudflare를 잇는 논리적 연결로, 이름과 UUID로 식별되는 영구 객체입니다. 하나의 터널로 여러 서비스를 프록시할 수 있습니다.
- 커넥터 (Connector): 실제로 연결을 만드는
cloudflared프로세스입니다. 각 인스턴스는 최소 두 곳 이상의 Cloudflare 데이터센터로 4개의 장기 연결을 만들어, 개별 연결이나 데이터센터에 장애가 나도 오리진이 계속 연결되도록 합니다. - 복제본 (Replica): 같은 터널을 다른 호스트에서 실행하는 추가
cloudflared인스턴스입니다. Cloudflare가 가장 가까운 복제본으로 트래픽을 보내며, 호스트 장애에 대비한 이중화 용도로 사용합니다. 특정 복제본이 선택된다는 보장은 없으므로 로드 밸런싱 용도로는 적합하지 않습니다. - 관리 방식: 대시보드나 API로 만드는 원격 관리형 (remotely-managed) 터널은 설정이 Cloudflare에 저장되고, CLI로 만드는 로컬 관리형 (locally-managed) 터널은 설정이 서버의 로컬 파일에 저장됩니다. 신규 배포에는 토큰 기반의 원격 관리형 터널이 권장됩니다.
트래픽을 보내는 방식
Tunnel로 연결한 리소스는 크게 세 가지 방식으로 사용자에게 제공됩니다.
| 방식 | 사용자 접근 형태 | 예시 |
|---|---|---|
| 공개 호스트네임 (Published application) | 브라우저로 공개 호스트네임에 접속. Access를 적용하면 로그인 후 사용 (Client 불필요) | wiki.company.com → 내부 위키 서버 |
| 사설 IP·CIDR 경로 (Private network) | Cloudflare One Client가 사설 IP로 보낸 트래픽을 터널로 전달 | 10.10.0.0/16 대역의 SSH, RDP, DB |
| 사설 호스트네임 경로 (Private hostname) | Client에서 내부 호스트네임으로 접근 | erp.internal |
특징과 제약
- 인바운드 포트가 필요 없음: 방화벽에서 모든 인바운드 트래픽을 막고
cloudflared의 아웃바운드 연결만 허용하면, Cloudflare를 거치지 않은 오리진 직접 접근을 원천 차단할 수 있습니다. - 서버 시작 (server-initiated) 트래픽 미지원: 오리진이 먼저 사용자 쪽으로 연결을 시작해야 하는 VoIP, SIP 같은 프로토콜은 사용할 수 없습니다.
- 출발지 IP 비보존: 오리진에는
cloudflared의 IP가 보입니다. HTTP는CF-Connecting-IP헤더로 클라이언트 IP를 확인할 수 있지만, SSH·RDP 같은 비 HTTP 트래픽은 원래 IP를 알 수 없습니다. - 플랫폼:
cloudflared는 VM, 컨테이너, Kubernetes, 베어메탈 등 대부분의 환경에서 실행되며 모든 요금제에서 사용할 수 있습니다.
Cloudflare Mesh: 모든 참여자에게 사설 IP를 부여하는 양방향 네트워크
Cloudflare Mesh는 등록된 서버, 노트북, 스마트폰 모두에게 사설 Mesh IP를 부여하고, 참여자끼리 TCP, UDP, ICMP로 통신하게 합니다. 이전에는 WARP Connector와 피어 투 피어 (peer-to-peer) 연결로 불리던 기능이며, 기존 WARP Connector는 이제 Mesh 노드라고 부릅니다.
구조
| 구분 | Mesh 노드 (Mesh node) | 클라이언트 디바이스 (Client device) |
|---|---|---|
| 실행 환경 | Linux 서버, VM, 컨테이너 | 노트북, 스마트폰, 데스크톱 |
| 클라이언트 | Cloudflare One Client (warp-cli), 헤드리스 모드 | Cloudflare One Client (UI 포함) |
| Mesh IP | 등록 시 할당 | 등록 시 할당 |
| 서브넷 라우팅 | CIDR 경로 광고 (advertise) 가능 | 불가 (노드를 통해 서브넷에 접근) |
| 고가용성 | Active-Passive 복제본 지원 | 해당 없음 |
- Mesh IP: 기본적으로
100.96.0.0/12대역에서 할당됩니다. CGNAT 주소 공간을 사용하므로 RFC 1918 사설 대역 (10.x,172.16.x,192.168.x)과 충돌하지 않으며, 필요하면 다른 서브넷으로 바꿀 수 있습니다. - 경로 (Routes): Mesh 노드가 CIDR 경로나 호스트네임 경로를 광고하면, 클라이언트를 설치할 수 없는 IoT 기기, 프린터, 레거시 서버가 있는 서브넷에도 다른 참여자가 접근할 수 있습니다.
- 디바이스 간 연결: 클라이언트 디바이스끼리는 Mesh 노드 없이도 Mesh IP로 서로 연결됩니다.
- 정책 적용: 모든 트래픽은 참여자 간에 직접 흐르지 않고 가장 가까운 Cloudflare 데이터센터를 거치므로, Gateway Network 정책과 Device Posture 검사가 모든 연결에 적용됩니다.
특징과 제약
- 양방향과 출발지 IP 보존: 어느 참여자든 먼저 연결을 시작할 수 있고 출발지 IP가 종단 간 보존되므로, VoIP·SIP, AD (Active Directory) 업데이트, SCCM (System Center Configuration Manager, Microsoft의 기업용 IT 자산·소프트웨어 관리 솔루션)처럼 서버가 클라이언트로 연결하는 트래픽을 처리할 수 있습니다.
- 장기 연결에 적합: L3/L4에서 동작하며 연결을 종단 간 유지하므로, SAP, DB 복제, ERP, RDP 세션처럼 연결 끊김에 민감한 트래픽의 소프트웨어 On-ramp로 권장됩니다.
- MASQUE 필요: Mesh 노드의 Device Profile이 WireGuard를 사용하면 호스트네임 경로, IPv6 CIDR 경로, 고가용성이 동작하지 않습니다.
- 플랫폼과 상태: Mesh 노드는 Linux (x86_64, ARM64)에서만 동작하며 현재 beta입니다. Docker나 Kubernetes 컨테이너로도 배포할 수 있습니다.
Cloudflare WAN: 사이트 전체를 연결하는 클라우드 WAN
Cloudflare WAN (이전 이름: Magic WAN)은 데이터센터, 사무실, 클라우드 리소스를 Cloudflare 글로벌 네트워크로 연결해, MPLS (Multiprotocol Label Switching) 회선과 허브 앤 스포크 (hub-and-spoke) 라우팅을 클라우드 네이티브 네트워킹으로 대체합니다. 트래픽을 중앙 데이터센터로 되돌려 보내는 백홀 (backhaul) 대신, 가장 가까운 Cloudflare 데이터센터에서 보안 정책을 인라인으로 적용합니다. Enterprise 전용 제품입니다.
사이트를 연결하는 방식 (On-ramp)
| 방식 | 설명 |
|---|---|
| GRE / IPsec 터널 | 기존 라우터·방화벽에서 Anycast GRE 또는 IPsec 터널로 연결. GRE는 암호화하지 않으므로 공용 인터넷에서 암호화가 필요하면 IPsec 사용 |
| Cloudflare One Appliance | Cloudflare가 관리하는 하드웨어·가상 어플라이언스로 IPsec 터널 생성과 트래픽 조정 (traffic steering)을 자동화. 제로 터치 지점 (Branch) 배포에 적합 |
| Cloudflare Network Interconnect (CNI) | 공용 인터넷 대신 전용 회선으로 직접 연결 |
| Multi-Cloud Networking | AWS, Azure, GCP의 네이티브 VPN을 이용해 VPC와의 IPsec 터널과 경로를 자동 생성 |
WAN은 Cloudflare Tunnel, Cloudflare One Client와도 함께 동작합니다. 예를 들어 Client 사용자가 WAN으로 연결된 지점 (Branch)의 리소스에 접근하거나, 반대로 지점에서 Client 디바이스의 가상 IP로 연결을 시작할 수 있습니다.
특징과 제약
- 연결 서비스이지 보안 서비스가 아님: WAN 자체는 라우팅을 담당합니다. L3/L4 필터링은 WAN에 포함된 FWaaS인 Cloudflare Network Firewall로, 사용자·애플리케이션 단위의 검사는 Gateway로 적용합니다.
- 라우팅: 정적 경로 외에 BGP 피어링 (beta)으로 경로를 자동 광고·철회할 수 있으며, 가상 네트워크 (Virtual networks)로 환경이나 파트너별로 라우팅을 분리할 수 있습니다.
- MTU 계획: GRE는 유효 MTU가 1,476바이트, IPsec은 암호화 방식에 따라 1,400~1,436바이트이므로 엣지 장비에서 MSS 클램핑 (MSS clamping)을 설정해야 합니다.
세 가지 커넥터 한눈에 비교
| 구분 | Cloudflare Tunnel | Cloudflare Mesh | Cloudflare WAN |
|---|---|---|---|
| 연결 단위 | 애플리케이션, 호스트네임, IP 경로 | 디바이스, 서버, 서브넷 | 사이트·데이터센터·클라우드 네트워크 전체 |
| 커넥터 | cloudflared | warp-cli (헤드리스) | 라우터·방화벽, Appliance, CNI |
| 방향 | Off-ramp 전용 (클라이언트 → 오리진) | 양방향 | 양방향 |
| 서버 시작 트래픽 | 미지원 | 지원 | 지원 |
| 출발지 IP | 비보존 (cloudflared IP) | 종단 간 보존 | 터널 내에서 보존 |
| 프로토콜 | HTTP/S, TCP, SSH, RDP, SMB 등 | TCP, UDP, ICMP | 모든 IP 트래픽 |
| 플랫폼 | 대부분의 OS·컨테이너 | Linux (beta) | 네트워크 장비, 전용 어플라이언스 |
| 이중화 | 여러 복제본 | Active-Passive 복제본 | 터널 이중화, 사이트별 여러 커넥터 |
| 이용 조건 | 모든 요금제 | 모든 요금제 (beta) | Enterprise |
| 주로 담당하는 팀 | 보안팀, DevOps | DevOps, 플랫폼 엔지니어링 | 네트워크 운영팀 |
간단히 정리하면 다음과 같습니다.
- 특정 애플리케이션을 공개하고 싶다면 → Tunnel
- 디바이스와 서버가 사설 IP로 서로 통신해야 한다면 → Mesh
- 사이트 전체의 네트워크를 연결해야 한다면 → WAN
요구 사항별 적용 시나리오
| 요구 사항 | 권장 커넥터 | 이유 |
|---|---|---|
| 사내 위키·대시보드를 협력사에 브라우저로 제공 | Tunnel (공개 호스트네임) + Access | Client 설치 없이 Access 로그인만으로 접근. 인바운드 포트 불필요 |
| 원격 근무자 (Remote worker)의 VPN 대체 (SSH, RDP, 내부 웹) | Tunnel (사설 네트워크) + Client | 필요한 대역만 터널로 노출하고 Access·Gateway로 제어 |
| 내부 서버가 사용자 PC로 연결 (SCCM 배포, AD, VoIP 콜백) | Mesh | 서버 시작 트래픽과 출발지 IP 보존이 필요 |
| DB 복제, SAP·ERP처럼 장시간 유지되는 연결 | Mesh | L3/L4에서 연결을 종단 간 유지 |
| 클라이언트 설치가 불가능한 IoT·프린터 서브넷 | Mesh 노드의 CIDR 경로 또는 WAN | 서브넷 단위 라우팅 |
| 여러 지점 (Branch)·데이터센터의 MPLS 대체 | WAN (IPsec/GRE, Appliance) | 기존 네트워크 장비로 사이트 전체를 연결 |
| 공용 인터넷을 거치면 안 되는 규제 환경 | WAN + CNI | 전용 회선 연결, IPsec을 백업 경로로 사용 |
| Kubernetes 서비스를 내부 사용자에게 제공 | Tunnel (또는 컨테이너형 Mesh 노드) | 클러스터 내부에서 아웃바운드로 연결 |
여러 VPC가 같은 사설 대역 (10.0.0.0/8)을 사용 | Tunnel·WAN + 가상 네트워크 | 가상 네트워크로 중복 대역을 분리 |
함께 사용할 때 고려 사항
세 커넥터는 한 계정에서 함께 사용할 수 있으며, Client + Tunnel + Mesh 조합은 사설 애플리케이션 원격 접근의 일반적인 패턴입니다. 다만 다음 사항을 확인해야 합니다.
- CIDR 중복 시 우선순위: 같은 대역을 Tunnel과 WAN에 모두 설정하면 Tunnel 경로가 우선합니다. 가능하면 대역이 겹치지 않도록 설계합니다.
- 커넥터 간 자동 장애 조치 없음: Tunnel이 장애 나도 WAN 경로로 자동 전환되지 않습니다. 이중화는 각 커넥터 안에서 구성합니다 (Tunnel 복제본, Mesh 복제본, WAN 터널 이중화).
- Mesh와 WAN 동시 사용: 레거시 라우팅 모드 계정에서는 WAN이 활성화된 상태로 Mesh를 사용할 수 없으며, Cloudflare One Unified Routing이 필요합니다.
- CNI와 Tunnel:
cloudflared는 이중화를 위해 여러 Cloudflare 리전에 연결하므로, CNI가 한 리전만 광고하는 환경에서는 Tunnel의 이중화가 줄어듭니다. CNI로 이미 사설 연결이 있다면 Tunnel이 꼭 필요한지 검토합니다. - 정상 상태 ≠ 접근 가능: Tunnel이나 Mesh 노드가 정상 (healthy)이라는 것은 Cloudflare와 연결되었다는 뜻일 뿐입니다. 사용자가 실제로 접근하려면 경로 설정, Client의 Split Tunnels, DNS 해석, 그리고 Access·Gateway 허용 정책이 모두 맞아야 합니다.
마치며
Cloudflare Tunnel은 애플리케이션 단위의 아웃바운드 Off-ramp, Cloudflare Mesh는 참여자 간 양방향 사설 IP 네트워크, Cloudflare WAN은 사이트 단위의 네트워크 연결입니다. 연결 단위와 트래픽 방향, 출발지 IP 보존 필요 여부를 기준으로 고르고, 필요하면 여러 커넥터를 조합해 사용합니다.
다음 글에서는 이렇게 연결된 애플리케이션에 누가, 어떤 조건에서 접근할 수 있는지를 결정하는 Cloudflare Access의 인증·인가와 접근 정책을 살펴봅니다.