포트포워딩을 버리고 Cloudflare Tunnel로 갈아탄 이유
AI 요약
홈서버가 다운되면서 포트포워딩의 문제점을 직접 경험하게 되었고, Cloudflare Tunnel을 통해 서버와 Cloudflare 간의 안정적인 연결을 구축할 수 있었습니다. Cloudflare Tunnel은 공인 IP 노출 없이, IP 변경 시도에도 장애가 발생하지 않으며, DDoS 방어 및 네트워크 관리에 대한 편리성을 제공합니다. 터널 생성과 DNS 라우팅 설정만으로도 포트포워딩의 필요를 줄이고 안정적인 서비스 운영을 가능하게 합니다.
포트포워딩을 버리고 Cloudflare Tunnel로 갈아탄 이유
홈서버가 다운된 후 복구 과정에서 포트포워딩이 가지는 문제점을 알게 되었고 대안을 찾았습니다. Cloudflare Tunnel로 전환하니 포트포워딩 불필요, 공인 IP 비노출, IP 변경 무관, 무료. 설치부터 systemd 등록까지 10분이면 끝납니다.
배경: 포트포워딩의 한계
홈서버에 블로그(Next.js)을 운영하고 있고 아래와 같은 구조로 블로그 서비스를 운영했습니다.
Cloudflare DNS (A 레코드: 공인 IP)
→ 공유기 포트포워딩 (80, 443)
→ Nginx Proxy Manager (리버스 프록시)
→ Docker 컨테이너들
잘 돌아가던 구조였는데, 서버가 다운되고 복구한 후 522 에러가 발생했습니다. 원인을 찾아보니 공유기 포트포워딩이 풀려 있었습니다.
이 사건을 계기로 포트포워딩 방식의 문제점이 눈에 들어왔습니다.
| 문제 | 설명 |
|---|---|
| 공인 IP 노출 | A 레코드에 집 IP가 그대로 박혀 있음 |
| IP 변경 시 장애 | ISP가 IP를 바꾸면 DDNS 없이는 접속 불가 |
| 포트포워딩 의존 | 공유기 재시작, 펌웨어 업데이트 시 설정이 날아갈 수 있음 |
| 방화벽 구멍 | 외부에서 직접 접근 가능한 포트가 열려 있음 |
Cloudflare Tunnel이란
Cloudflare Tunnel(구 Argo Tunnel)은 서버에서 Cloudflare로 아웃바운드 연결을 맺는 방식입니다.
Cloudflare Edge (HTTPS 종료)
← QUIC 터널 (아웃바운드)
← cloudflared (서버에서 실행)
→ Nginx Proxy Manager → Docker 컨테이너
핵심은 인바운드 포트를 열 필요가 없다는 점입니다. 서버가 Cloudflare에 먼저 연결하기 때문에 공유기 포트포워딩이 필요 없고, 공인 IP도 노출되지 않습니다.
포트포워딩 vs Cloudflare Tunnel
| 항목 | 포트포워딩 | Cloudflare Tunnel |
|---|---|---|
| 포트 개방 | 80, 443 필수 | 불필요 |
| 공인 IP 노출 | O (A 레코드) | X (CNAME) |
| IP 변경 대응 | DDNS 필요 | 자동 (아웃바운드) |
| 공유기 의존 | 높음 | 없음 |
| DDoS 방어 | 직접 노출 | Cloudflare 프록시 |
| 비용 | 무료 | 무료 |
| 레이턴시 | 직접 연결 | +약간 (Cloudflare 경유) |
설치 과정
1. cloudflared 설치
# Debian/Ubuntu
curl -L -o cloudflared.deb \
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
2. Cloudflare 인증
cloudflared tunnel login
브라우저가 열리면 도메인을 선택하고 승인합니다. 인증서가 ~/.cloudflared/cert.pem에 저장됩니다.
3. 터널 생성
cloudflared tunnel create gats-homelab
터널 ID와 credential 파일이 생성됩니다.
4. config.yml 작성
# ~/.cloudflared/config.yml
tunnel: <터널-ID>
credentials-file: /home/<user>/.cloudflared/<터널-ID>.json
ingress:
- hostname: blog.gatslee.com
service: http://localhost:80
- hostname: cs.handbook.gatslee.com
service: http://localhost:80
- service: http_status:404
기존 Nginx Proxy Manager(80번 포트)로 트래픽을 보내면 NPM이 호스트명 기반으로 라우팅합니다. 기존 NPM 설정을 그대로 활용할 수 있어서 마이그레이션이 간단합니다.
5. DNS 라우팅
# 기존 A 레코드 삭제 후 CNAME 등록
cloudflared tunnel route dns gats-homelab blog.gatslee.com
cloudflared tunnel route dns gats-homelab cs.handbook.gatslee.com
Cloudflare DNS에 <터널-ID>.cfargotunnel.com을 가리키는 CNAME이 자동 생성됩니다.
6. systemd 등록 (영구 실행)
sudo mkdir -p /etc/cloudflared
sudo cp ~/.cloudflared/config.yml /etc/cloudflared/
sudo cp ~/.cloudflared/<터널-ID>.json /etc/cloudflared/
sudo cloudflared service install
sudo systemctl enable --now cloudflared
전환 후 확인
# 서비스 상태
systemctl status cloudflared
# 외부 접속 테스트
curl -s -o /dev/null -w "%{http_code}" https://blog.gatslee.com
# 200
정리
| Before | After |
|---|---|
| A 레코드 (공인 IP 노출) | CNAME (터널 경유) |
| 공유기 포트포워딩 80, 443 | 포트 개방 없음 |
| IP 변경 시 수동 대응 필요 | 자동 (아웃바운드 연결) |
| DDNS 서비스 필요 | 불필요 |
서버가 다운되는 사고가 없었으면 아마 포트포워딩으로 계속 운영했을 겁니다. 문제가 터져야 더 나은 구조를 찾게 되는 건 좀 아이러니하지만, 결과적으로 인프라가 훨씬 견고해졌습니다. 홈서버를 운영하시고 있다면 Cloudflare Tunnel은 무조건 추천합니다.
댓글 (0)
아직 댓글이 없습니다.