Cloudflare Tunnel 학습 시리즈 1단계

 

Cloudflare Tunnel 학습 시리즈 1단계

Cloudflare Tunnel이란? 초보자를 위한 가장 쉬운 설명

서버나 Kubernetes를 운영하다 보면 종종 이런 용어를 접하게 됩니다.

Cloudflare Tunnel
cloudflared
Zero Trust
Inbound
Outbound

처음 접하면 상당히 복잡해 보입니다.

하지만 Cloudflare Tunnel의 핵심 개념은 생각보다 단순합니다.

이번 1단계에서는 설치 방법이나 복잡한 네트워크 설정에 들어가기 전에,

“Cloudflare Tunnel이 무엇이고 왜 사용하는가?”

부터 아주 쉽게 알아보겠습니다.

📚 앞으로 진행할 Cloudflare Tunnel 학습 시리즈

1단계. Cloudflare Tunnel이란?

- Tunnel의 기본 개념과 사용하는 이유

2단계. cloudflared란?

- 서버에 설치되는 cloudflared의 역할

3단계. Cloudflare Tunnel 통신 구조

- 사용자 → Cloudflare → 서버까지 통신 흐름

4단계. 기존 공인 IP 방식과 Tunnel 방식 비교

- 공인 IP, NAT, 방화벽, Port Forwarding과 차이점

5단계. Cloudflare Tunnel 직접 만들어보기

- 간단한 테스트 환경 구축

6단계. Kubernetes에서 Cloudflare Tunnel 사용하기

- Pod, Service, cloudflared 연결 구조

7단계. Cloudflare Zero Trust와 Tunnel

- 인증받은 사용자만 내부 서비스에 접근시키는 방법

8단계. 방화벽과 네트워크 포트 이해하기

- Inbound, Outbound, QUIC 등의 기본 개념

9단계. Cloudflare Tunnel 이중화와 장애 대응

- Replica와 고가용성 구성 이해

10단계. 운영자가 알아야 할 점검 방법

- 서버와 Kubernetes에서 Tunnel 사용 여부 확인하기



1. 먼저 Tunnel이란?

Tunnel은 우리말로 하면 말 그대로

“터널”

입니다.

IT에서도 의미는 비슷합니다.

인터넷이라는 공개된 네트워크를 사용하지만, 특정 시스템 사이에 별도의 논리적인 통신 경로를 만들어 사용하는 방식입니다.

쉽게 비유해보겠습니다.

일반 인터넷 통신이 여러 차량이 함께 다니는 일반 도로라면,

Tunnel은

“두 장소를 연결해 놓은 전용 통로”

정도로 이해하면 됩니다.

즉, 특정 시스템끼리 통신하기 위한 연결 경로를 만드는 것입니다.



2. Cloudflare는 무엇일까?

Cloudflare는 인터넷 사용자와 서버 사이에서 트래픽을 전달하고 보호하는 다양한 네트워크 서비스를 제공합니다.

예를 들어 일반적인 웹서비스라면 다음처럼 구성할 수 있습니다.

사용자
↓
Internet
↓
공인 IP
↓
Firewall
↓
Web Server

Cloudflare를 사용하는 환경에서는 중간에 Cloudflare가 위치할 수 있습니다.

사용자
↓
Cloudflare
↓
Web Server

Cloudflare는 이런 구조에서 CDN, WAF, DDoS 방어, 접근제어 등 다양한 기능을 제공합니다.



3. Cloudflare Tunnel이란?

이제 두 단어를 합쳐보겠습니다.

Cloudflare + Tunnel

즉,

“Cloudflare와 내부 서버 사이에 통신 통로를 만들어주는 기술”

이라고 이해하면 됩니다.

조금 더 정확하게 설명하면,

내부 서버에서 Cloudflare 쪽으로 먼저 연결을 생성해 놓고, 그 연결을 통해 외부 사용자가 내부 서비스에 접근할 수 있도록 하는 방식입니다.

구조를 단순화하면 다음과 같습니다.

외부 사용자
↓
Internet
↓
Cloudflare
↓
Cloudflare Tunnel
↓
cloudflared
↓
내부 Server
↓
Application

POINT.

Cloudflare Tunnel을 이해할 때 가장 중요한 것은

“내부 서버가 Cloudflare 쪽으로 먼저 연결한다.”

라는 점입니다.



4. cloudflared는 무엇일까?

Cloudflare Tunnel을 이해하려면 반드시 알아야 하는 프로그램이 있습니다.

바로

cloudflared

입니다.

cloudflared는 서버와 Cloudflare 사이에서 Tunnel 연결을 만들어주는 프로그램입니다.

예를 들어 서버에 cloudflared가 실행되고 있다면 다음과 같은 구조가 만들어질 수 있습니다.

Server
↓
cloudflared
↓
Cloudflare

여기서 중요한 것은 연결 방향입니다.

Cloudflare가 먼저 서버로 접속하는 것이 아니라,

서버에 설치된 cloudflared가 Cloudflare 쪽으로 먼저 연결을 생성합니다.



5. 왜 서버가 먼저 연결하는 것이 중요할까?

기존에 서버를 인터넷에 공개하려면 외부에서 서버까지 접근할 수 있는 경로를 만들어야 하는 경우가 많습니다.

예를 들어 웹서버라면 이런 구조를 생각할 수 있습니다.

Internet
↓
Public IP
↓
Firewall
↓
443 Port
↓
Web Server

이 경우 외부에서 서버로 들어오는 Inbound 경로가 존재합니다.

따라서 운영자는 다음과 같은 것들을 관리해야 합니다.

공인 IP
방화벽 정책
NAT
Port Forwarding
접근제어

Cloudflare Tunnel은 구조가 조금 다릅니다.

내부 서버가 먼저 Cloudflare 쪽으로 연결합니다.

내부 Server
↓
cloudflared
↓
Outbound Connection
↓
Cloudflare

이미 연결이 만들어져 있기 때문에 외부 사용자의 요청은 이 Tunnel을 통해 전달될 수 있습니다.

 

6. 건물로 비유하면 더 쉽다

일반적인 서버 공개 방식을 건물에 비유해보겠습니다.

회사 건물 안에 서버가 있다고 가정하겠습니다.

기존 방식은 외부 사람이 정문을 통해 회사로 들어오는 것과 비슷합니다.

외부 사용자
↓
회사 정문
↓
경비원
↓
내부 서버

여기서 정문은 공인 IP나 개방된 Port에 해당하고,

경비원은 Firewall 역할을 한다고 볼 수 있습니다.

Cloudflare Tunnel은 조금 다릅니다.

회사 내부에서 Cloudflare라는 안내센터까지 전용 통로를 먼저 만들어 놓습니다.

외부 사용자
↓
Cloudflare
↓
이미 만들어진 Tunnel
↓
내부 서버

즉 외부 사용자가 내부 서버에 직접 찾아오는 구조와 차이가 있습니다.

 

7. Cloudflare Tunnel을 왜 사용할까?

대표적인 이유는 크게 세 가지로 이해하면 됩니다.

첫 번째.

서버를 인터넷에 직접 노출하는 범위를 줄일 수 있습니다.

서비스 구성에 따라 Origin Server의 공인 IP를 직접 노출하지 않는 형태로 구성할 수 있습니다.

두 번째.

외부에서 내부 서버로 들어오는 Inbound 구성을 줄일 수 있습니다.

cloudflared가 Cloudflare 방향으로 먼저 연결하기 때문입니다.

세 번째.

Cloudflare의 여러 보안 기능과 결합할 수 있습니다.

예를 들면 다음과 같습니다.

WAF
DDoS Protection
Cloudflare Access
Zero Trust

즉 단순히 Tunnel만 만드는 것이 아니라, 접근제어와 보안을 함께 구성할 수 있습니다.

 

8. 실제 서비스로 예를 들어보자

내부 서버에 다음과 같은 웹서비스가 있다고 가정해보겠습니다.

http://localhost:8080

현재 이 서비스는 서버 내부에서만 접속할 수 있다고 가정하겠습니다.

Cloudflare Tunnel을 사용하면 예를 들어 다음과 같은 도메인과 연결할 수 있습니다.

app.example.com

통신 구조는 다음처럼 볼 수 있습니다.

사용자
↓
app.example.com
↓
Cloudflare
↓
Cloudflare Tunnel
↓
cloudflared
↓
localhost:8080

사용자는 Cloudflare를 통해 내부 서비스를 이용하게 됩니다.

 

9. Kubernetes에서는 어떻게 사용할까?

Cloudflare Tunnel은 일반 Linux 서버뿐 아니라 Kubernetes에서도 사용할 수 있습니다.

예를 들어 다음과 같은 구조입니다.

Internet
↓
Cloudflare
↓
Cloudflare Tunnel
↓
cloudflared Pod
↓
Kubernetes Service
↓
Application Pod

여기서 cloudflared가 Pod 형태로 동작할 수 있습니다.

예를 들어 Kubernetes 내부에 Grafana나 사내 웹서비스가 있다고 가정하겠습니다.

기존 방식에서는 상황에 따라 다음과 같은 구성이 필요할 수 있습니다.

Ingress
LoadBalancer
Public IP
Firewall

Cloudflare Tunnel을 사용하면 cloudflared를 통해 Cloudflare와 내부 Service를 연결하는 방식도 사용할 수 있습니다.

 

10. Cloudflare Tunnel을 쓰면 모든 인터넷 통신이 Cloudflare를 통할까?

이 부분은 초보자가 가장 많이 오해할 수 있습니다.

결론부터 말하면

그렇지 않습니다.

Cloudflare Tunnel이 설치되어 있다고 해서 서버에서 발생하는 모든 인터넷 통신이 자동으로 Cloudflare Tunnel을 통과하는 것은 아닙니다.

예를 들어 서버에서 다음과 같은 통신을 한다고 가정하겠습니다.

Server
↓
Google
↓
Internet

일반적인 서버의 외부 인터넷 통신은 기존 네트워크 Routing을 통해 나갈 수 있습니다.

즉,

Server
↓
Gateway
↓
Internet

형태입니다.

Cloudflare Tunnel은 기본적으로 설정된 서비스와 Cloudflare 사이의 연결에 사용됩니다.

POINT.

Cloudflare Tunnel을

“서버의 모든 인터넷 통신을 Cloudflare로 보내는 기술”

이라고 이해하면 안 됩니다.

보다 정확하게는

“Cloudflare와 특정 내부 서비스 사이에 연결 경로를 만들어주는 기술”

이라고 이해하는 것이 좋습니다.

 

11. Inbound와 Outbound도 같이 알아두자

Cloudflare Tunnel을 공부하다 보면 Inbound와 Outbound라는 단어를 자주 만나게 됩니다.

초보자는 이렇게 이해하면 됩니다.

Inbound

외부 → 내부

예를 들어

Internet
↓
Server

외부에서 서버로 들어오는 통신입니다.

Outbound

내부 → 외부

예를 들어

Server
↓
Internet

서버에서 외부로 나가는 통신입니다.

Cloudflare Tunnel에서는 cloudflared가 Cloudflare 방향으로 Outbound 연결을 생성한다는 점이 중요합니다.

Server
↓
cloudflared
↓
Cloudflare

 

12. 운영 환경에서는 무엇을 확인하면 될까?

Cloudflare Tunnel을 공부하다 보면 실제 서버나 Kubernetes 환경에서

“현재 이 시스템에서 Cloudflare Tunnel을 사용하고 있는지 어떻게 확인할까?”

라는 궁금증이 생길 수 있습니다.

운영 환경에서는 먼저 다음과 같은 구조가 존재하는지 확인하면 됩니다.

외부 사용자
↓
Cloudflare
↓
Cloudflare Tunnel
↓
cloudflared
↓
Server / Kubernetes
↓
Application Service

여기서 가장 중요한 것은 두 가지입니다.

cloudflared가 실행되고 있는가?

그리고

cloudflared가 어떤 내부 서비스와 연결되어 있는가?

입니다.

예를 들어 일반 서버라면 다음과 같은 구조가 있을 수 있습니다.

Cloudflare
↓
Tunnel
↓
cloudflared
↓
Web Service

Kubernetes 환경이라면 다음처럼 구성될 수도 있습니다.

Cloudflare
↓
Tunnel
↓
cloudflared Pod
↓
Kubernetes Service
↓
Application Pod

POINT.

Cloudflare Tunnel 사용 여부를 확인한다고 해서 서버의 모든 외부 통신을 조사하는 것은 아닙니다.

우선적으로 확인해야 하는 것은

“cloudflared가 존재하는가?”

그리고

“cloudflared가 어떤 서비스와 연결되어 있는가?”

입니다.

운영자가 기본적으로 확인할 항목은 다음과 같습니다.

① cloudflared가 설치되어 있는가?

② cloudflared 프로세스가 실행 중인가?

③ Kubernetes에 cloudflared Pod 또는 Deployment가 존재하는가?

④ Tunnel 설정이 어떤 내부 서비스와 연결되어 있는가?

⑤ 현재 사용 중인 Tunnel이 존재하는가?

 

13. Linux 서버에서는 어떻게 확인할까?

Linux 서버에서는 다음과 같은 명령으로 확인할 수 있습니다.

cloudflared 프로세스 확인
ps -ef | grep cloudflared

서비스 확인
systemctl status cloudflared

프로그램 설치 여부 확인
which cloudflared

예를 들어 프로세스가 정상적으로 실행 중이라면 cloudflared 관련 프로세스가 표시될 수 있습니다.

 

14. Kubernetes에서는 어떻게 확인할까?

Kubernetes에서는 다음과 같이 확인할 수 있습니다.
kubectl get pods -A | grep -i cloudflared

또는

kubectl get pods -A | grep -i cloudflare

관련 Pod가 발견된다면 다음 단계에서 해당 Namespace와 Deployment를 추가로 확인할 수 있습니다.

예를 들면,

kubectl get deploy -A | grep -i cloudflared

같은 방식입니다.

 

15. 기존 방식과 Cloudflare Tunnel 비교

기존 방식

사용자
↓
공인 IP
↓
Firewall
↓
Open Port
↓
Server

Cloudflare Tunnel 방식

사용자
↓
Cloudflare
↓
Tunnel
↓
cloudflared
↓
Server

가장 중요한 차이는

“연결을 누가 먼저 만드는가?”

라고 이해하면 쉽습니다.

기존 방식은 외부에서 내부 서버로 접근할 수 있는 경로를 구성하는 경우가 많습니다.

Cloudflare Tunnel에서는 내부의 cloudflared가 Cloudflare 방향으로 먼저 연결을 생성합니다.

 

16. 오늘 꼭 기억해야 할 핵심 5가지

① Cloudflare Tunnel은 Cloudflare와 내부 서비스를 연결하는 통신 경로다.

② 내부 서버에서는 cloudflared가 핵심 역할을 한다.

③ cloudflared가 Cloudflare 방향으로 먼저 Outbound 연결을 생성한다.

④ 공인 IP나 Inbound Port의 직접적인 외부 노출을 줄이는 구조를 만들 수 있다.

⑤ Cloudflare Tunnel을 사용한다고 서버의 모든 인터넷 통신이 Tunnel을 통과하는 것은 아니다.

한 줄 요약

Cloudflare Tunnel은
“내부 서버가 Cloudflare와 먼저 연결 통로를 만들어 놓고, 외부 사용자가 그 통로를 통해 내부 서비스에 접근할 수 있도록 하는 기술”

이라고 이해하면 됩니다.

초보자는 여기까지만 기억하면 됩니다

아직

QUIC
WARP
Zero Trust
Access
Private Network Routing

같은 용어까지 모두 이해할 필요는 없습니다.

1단계에서는 아래 흐름만 기억하면 충분합니다.

Cloudflare
↓
Tunnel
↓
cloudflared
↓
내부 Service

그리고 가장 중요한 한 문장.

“cloudflared가 Cloudflare 쪽으로 먼저 연결한다.”

이 개념을 이해하면 앞으로 Cloudflare Tunnel의 동작 원리를 훨씬 쉽게 이해할 수 있습니다.

다음 2단계에서는

“cloudflared가 정확히 무엇이고 서버에서 어떤 역할을 하는가?”

를 Linux 서버와 Kubernetes 환경을 기준으로 자세히 알아보겠습니다.