이제는 웬만한 작업이 완료되어 사용자가 웹사이트를 방문하는데 속도 저하가 없이 내 블로그를 빠르게 이용할 수 있게 되었다.

이를 작업하면서 추가적인 속도 개선 방법 및 보안 설정이 있나 찾아보던 도중 Cloudflare Zero Trust 를 통한 Outbound 처리를 통해 내 서버와 Cloudflare 간 통신 시 ICN(한국) 리전을 이용 및 내 서버의 IP를 Inbound 오픈 설정 하지 않아도 Client 들이 내 웹사이트에 접근할 수 있다는 내용이 있어 해당 시스템을 도입해보았다.

일반적인 서버는 Inbound 로 방화벽을 오픈해서 클라이언트가 내 서버에 직접 접근하는 방식을 쓰다보니 필연치 않은 보안 문제가 발생할 우려가 있었다. 이를 막기 위해 Cloudflare 는 Tunnels 를 생성하여 Outbound 요청으로 내 서버가 직접 Cloudflare 에 Data 를 넘겨주는 방식으로 이용하여 보안과 속도 측면에서 이점을 얻을 수 있었다.

물론, 내 블로그를 접근하는 최종 클라이언트는 무료 요금제라는 특성상 한국 리전 (ICN) 대신 KIX, HKG 등 일본이나 홍콩서버의 리전이 적용되어 미묘한 속도차이가 있다.

즉, 사용자는 다음과 같이 서버 접속이 이루워진다.

Client ↔ Cloudflare ↔ Server
KIX & HKG / ICN

즉, 사용자는 Cloudflare 를 통해 사이트가 열릴 때 일본이나 홍콩서버를 보여주지만, Cloudflare 가 내 서버와의 통신을 할 때는 한국서버를 통해 접속하기 때문에 미묘한 속도 개선이 이루워진다.

또한, 보안적인 측면에서 Inbound 정책을 열지 않아도 Outbound 만으로 처리할 수 있다는 장점이 있어 Server 의 IP 를 숨기는 데 많은 도움이 된다.

아래 내용은 실제로 서버에 Cloudflare 의 Tunnels 기능을 이용하기 위해 게시글을 작성해본다.

Cloudflare Zero Trust 를 위한 가이드

Cloudflared 설치하기

우선 Cloudflare Zero Trust 를 사용하기 위해서는 Cloudflared 라는 툴을 설치해야 한다.

Tool 설치하기 위해서는 아래 사이트를 방문해서 Server 에 맞는 Cloudflared 를 설치를 한다.

Cloudflared Pkg 설치 가이드 : https://pkg.cloudflare.com/index.html

필자는 2025년 07월 22일 기준 Ubuntu 22.04 (Jammy Jellyfish)를 사용하고 있어 다음과 같이 명령어를 사용했다.

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared jammy main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared

sudo mkdir -p --mode=0755 /usr/share/keyrings

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared jammy main' | sudo tee /etc/apt/sources.list.d/cloudflared.list

sudo apt-get update && sudo apt-get install cloudflared

설치가 다 되면 Cloudflared 명령어를 사용할 수 있게 된다.

Cloudflare Zero Trust 에 Tunnels 등록하기

★ 참고 ★

Cloudflare 사이트는 페이지가 잦은 UX 변화가 있는 편이라 2025년 07월 22일 기준의 UX 를 바탕으로 설명함을 미리 양해 부탁드린다.

생각보다 사이트가 자주 바뀌고, 구글링을 통해 찾아보았던 정보는 메뉴 변경등으로 인해 현재 내용과 다를 수 있음을 주의해야 한다.

이미지가 많고 설명이 있어 아래 “펼치기” 버튼을 눌러서 직접 열어서 볼 수 있다.

Cloudflare Zero Trust 사이트에 방문을 한다.

Cloudflare Zero Trust 사이트 : https://one.dash.cloudflare.com/

그 다음, 네트워크① → Tunnels② → 터널 생성③을 누른다.

기본적으로는 Cloudflared 를 통해 사용하므로 Cloudflared④ 를 누른다.

터널 이름을 지정⑤하고, 터널 저장⑥을 누른다.

운영체제를 선택⑦하고 명령어를 복사⑧해서 서버에 넣는다.

※ 좌측항목은 서버가 재부팅되어도 자동으로 서비스에 붙게 해주는 상시 구동형이며 일반적으로 좌측을 선택한다.

※ 다만, 현재 터미널에 한해서만 유효하게 설정하는 테스트 용도면 우측의 명령어를 이용한다.

정상적으로 연결된다면 Cloudflare Zero Trust 사이트에서는 하단의 Connectors 에 연결된 정보가 표시될 것 이다.

서버 콘솔 출력 로그는 다음과 같은 형태다.

필자는 현재 터미널 세션에만 유효한 명령어로 실행하였으므로, 실제 운영환경에서 사용할 서비스 형태랑은 약간 다른게 표시되므로 참고하자.

서브 도메인이 있다면 서브 도메인을 입력하고, 메인 도메인은 Cloudflare 에 등록된 주소를, 뒤에 특정 경로일 때만 Tunnels 연결이 필요하다면 경로 까지 함께 입력⑨한다.

서비스⑩는 사용하는 서버에 따라 다르게 지정하는데, 필자는 https 환경이므로 https 를 선택 후, 내부망 IP 주소를 입력한다.

★ 주의사항 ★

입력한 호스트 이름이 이미 CNAME 이나 A, AAAA 레코드에 등록되서 이용하고 있다면

반드시 삭제 후 등록해줘야 된다.

Cloudflared 환경을 위한 CNAME 레코드로 재등록 작업이 이루워지기 때문에

사용할 도메인을 미리 삭제해줘야 정상적인 등록이 가능함에 유의하자.

TLS 환경을 운영한다면 추가 응용 프로그램 설정⑪ 을 눌러 작업을 더 설정해야 된다.

Cloudflare 가 내 서버의 인증서에 대해 주제 대체 이름(Subject Alternative Name) 이 어떤것인지 알 수 있게 원본 서버 이름⑫을 알 수 있게 입력해줘야 되며, https2 지원 환경일 경우 HTTP2 연결⑬을 활성화 시킨다.

그리고 마지막으로 개인 네트워크⑭ 탭을 눌러 사설망 IP 및 IP 에 대한 이름을 입력⑮한 다음, “설정 완료” 를 누르면 적용이 된다.

펼치기

접기

Cloudflared 를 통한 설정의 단점?

의외로 나는 악의적인 봇의 접근을 차단하기 위해 항상 error.log 를 tail 로 걸어보면서 악의적인 접근 시도가 있으면 IP Block 처리를 하는 편인데 Cloudflared 로 적용을 하면서 부터의 약간의(?) 문제가 발생했다.

바로 모든 client 의 주소가 내부망IP 주소로 잡히는 것 이었다.

Nginx 의 설정값을 통해 $remote_attr대신에 실제 Client IP를 알아오기 위해 X-Forwarded-For 를 적용했지만, error.log 에서는 항상 $remote_attr만 찍혀서 리턴되는것으로 보인다. 이걸 수정하려면 별도의 모듈을 컴파일 해야 된다는 문제점이 확인이 되었다. 이부분은 어짜피 access.log 를 통해 시간대를 다시 보면서 처리하면 되니까 약간의 불편함은 감수해야 될 것으로 생각한다.

2025.08.07 수정

내부망 IP 주소 였던걸 고쳤다.

구글링을 통해 서치하던 도중, $remote_attr가 실제 Client 단 IP 가 아니라 내 내부망 IP 로 찍히던 현상에 대해 위에 언급한 적이 있는데 이걸 바로 해결할 수 있었던 방법이 있었다.

바로 Nginx 의 config 값 중에 set_real_ip_from을 내 내부망도 포함시키면 되었다.

    # 내부망 프록시
    set_real_ip_from 192.168.50.0/24;

    # real_ip_header X-Forwarded-For;
    real_ip_header CF-Connecting-IP;
    real_ip_recursive on; # Proxy 에서 실제 Client IP 를 가져온 다음에 더이상 Proxy Chain 을 보지 않게 함

# 내부망 프록시

set_real_ip_from 192.168.50.0/24;

# real_ip_header X-Forwarded-For;

real_ip_header CF-Connecting-IP;

real_ip_recursive on; # Proxy 에서 실제 Client IP 를 가져온 다음에 더이상 Proxy Chain 을 보지 않게 함

위와 같이 set_real_ip_from을 내 내부망 IP 도 포함해서 처리하고 systemctl restart nginx해보니 의도한대로 실제 Client IP로 전환되서 error.log 가 남게되었다.

아래 게시글을 참고하여 조치했다.

감사의 말씀을 드린다.

참고한 링크 : Nginx & Cloudflare 프록시 환경 IP 화이트리스트 적용 – hbjs97