당연하지만, warp도 여럿 연결 가능하고, tunnel도 여럿 연결 가능합니다.
tunnel에 집의 nas, 집의 데스크탑, Oracle Cloud Infrastructure, AWS, azure등을 전부 zero trust에 넣어버리면
단말에서는 warp 하나 연결하여 모든 머신에 privateIP로 접근 가능합니다.

VPN은 각 네트워크마다 VPN 서버를 따로 만들어야 했지만
zero trust는 하나로 해결됩니다.

tunnel 적용 전의 구성도

일반적인 웹서버

서버와 클라이언트가 직접 연결되는 웹서버

일반적인 웹서버 구성도입니다.
client는 DNS 서버로부터 server의 ip를 가져오고, 그 IP로 접속합니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(123.123.123.123)으로 연결

reverse proxy를 활용한 웹서버

일반적인 서버 구성도에서 중간에 reverse proxy가 추가되었습니다.
도메인이나 여러가지 조건에 따라 backend 서버를 선택하여 연결하고
그 결과를 반환하여 클라이언트에게 전달됩니다.
하나의 IP, 하나의 포트(80, 443)로 여러가지 서비스를 제공할 때 매우 유리합니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(123.123.123.123)으로 연결
server(123.123.123.123)은 private IP를 사용하는 backend 서버로 연결

docker로 reverse proxy를 활용한 웹서버

reverse proxy가 docker로 사용했을 때의 구성도입니다.
도메인이나 여러가지 조건에 따라 backend docker를 선택하여 연결하고
그 결과를 반환합니다.
하나의 IP, 하나의 포트(80, 443), 하나의 서버로 여러가지 서비스를 제공할 때 매우 유리합니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(123.123.123.123)으로 연결
server(123.123.123.123)은 npm docker 컨테이너로 port forwarding
npm 컨테이너는 다른 컨테이너에 연결

Cloudflare proxied name server를 활용한 웹서버

cloudflare proxied 웹서버

reverse proxy가 하나가 추가된다고 보면 이해하기 쉽습니다.
이 때 revers proxy를 내가 구성하는 것이 아니라 클라우드 플레어가 구성해주는 것이죠.
내 서버에서는 cloudflare를 지나지 않은 모든 패킷에 대해서 차단하여 보안을 향상시킬 수 있습니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(103.21.245.198)으로 연결
Cloudflare 나리타 CDN은 server에 연결

cloudflare proxied + reverse proxy를 활용한 웹서버

cloudflare가 구성한 reverse proxy와 내 서버에 구성한 reverse proxy를 이중으로 사용합니다.
보안과 함께 하나의 IP, 하나의 포트(80, 443), 하나의 서버로 여러가지 서비스를 제공할 때 매우 유리합니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(103.21.245.198)으로 연결
Cloudflare 나리타 CDN은 server에 연결
server(123.123.123.123)은 private IP를 사용하는 backend 서버로 연결

Cloudflare tunnel을 활용한 웹서버

tunnel이란?

VPN을 생각해보면 vpn 서버는 포트를 열지만, 클라이언트는 port를 열지 않습니다.
cloudflare tunnel은 cloudflare cdn이 vpn 서버가 되고,
나의 웹서버는 cloudflare cdn vpn의 client가 된다고 볼수 있습니다.
따라서 server는 모든 ip, 모든 port에 대해 drop해도 통신이 가능합니다.

또한 내부 서비스 구성에 있어서 서버 컴퓨터와 cloudflare 사이에 tunnel을 구성하는 것이 아니라
서버에서 동작하는 애플리케이션, cloudflared와 tunnel을 연결한다고 생각하면 구성도를 이해하기 쉽습니다.
(이해를 위한 것으로 실제 작동 방식이라고 보면 안됩니다)

tunnel을 활용한 웹서버 구성도

cloudflared와 nginx는 같은 server에서 작동하고 있습니다.
따라서 localhost:80으로 접속합니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(103.21.245.198)으로 연결
Cloudflare 인천 CDN은 server의 cloudflared에 연결
cloudflared는 같은 host의 80포트(localhost:80)로 연결

tunnel을 docker로 적용한 예시

cloudflared와 nginx는 같은 docker network에서 작동하고 있습니다.
따라서 <컨테이너 이름>:포트(nginx:80)으로 접속합니다.

DNSServer를 통해 server IP 주소 취득
Client는 DNS를 통해 알아낸 IP 주소(103.21.245.198)으로 연결
Cloudflare 인천 CDN은 server의 cloudflared docker에 tunnel로 연결
cloudflared는 nginx라는 컨테이너의 80포트(nginx:80)로 연결

tunnel 구성하기

cloudflare zero trust 가입

cloudflare zero trust에 가입해야 합니다.
이미 팀을 생성했다면 pass해도 됩니다.

안타깝게도 이미 구성 된 사람은 이 화면을 볼수 없어서 스크린샷은 없습니다.
간단히 팀 이름만 설정하는 것이기 때문에 별거 없긴 합니다.

dash.cloudflare.com으로 접속하여 로그인합니다.
이후 one.dash.cloudflare.com으로 이동하여 zero trust 페이지로 이동하여
zero trust에 가입합니다.

cloudflare 인증 추가

먼저 인증 수단을 추가합니다.
애플리케이션과 warp의 device enroll, app launcher 페이지에 로그인 할 때 사용할 인증 수단입니다.

예를 들어 Google로 zero trust에 로그인 할 수 있습니다.
하지만 인증 수단만 추가하면 구글이라는 수단으로 누구나 로그인 할 수 있게 됩니다.
이것을 막기 위하여 access를 제한하게 됩니다.

application, device enroll, app launcher에 각각 access를 설정할수 있습니다.
하지만, 설정 액세스 설정 접근이 불편함과 일괄로 수정하기 힘든점, 한 화면에서 관리하기 힘든 점 때문에
저는 acess groups에서 group을 생성하고 그룹을 적용시킵니다.

Login method

Settings -> Authentication -> Login methods에서 추가합니다.
절차에 따라 방법을 추가하면 됩니다.

WARP device enroll을 위한 acess groups 생성

Access -> Access Groups에서 devide-enroll 그룹을 추가합니다.

include에 포함된 항목 중 하나가 있으면 로그인이 가능합니다.
require에 포함된 항목을 모두 만족하면 로그인이 가능합니다.
exclude에 포함된 항목이 있으면 로그인이 불가능해집니다.

include나 require에 login metohd를 선택할 수 있는데, 필수는 아닙니다.
어차피 Rules(또는 Policies)를 설정할 수 있는 모든 곳에는 authentication method를 지정할 수 있습니다.
authentication method로는 로그인 화면에 노출될 로그인 방법을 선택할 수 있습니다.
로그인 페이지에서 구글, 깃허브, otp로 로그인 할수 있는 화면을 띄우되, 구글로만 로그인 가능하게 하려고 할 때 사용할 수 있습니다.

먼저 zero trust에 warp 클라이언트 연결부터 할 것입니다.
access groups
저는 이렇게 만들었습니다.
하나의 로그인 방법으로만 허용하되, 모든 로그인 수단을 띄워줄 예정이기 때문에 Login Methods를 설정했습니다.

zero trust에 warp 로그인 방법에 Access groups 추가

access groups에서 규칙을 만들었고, 이 규칙을 적용하러 가야 합니다.
Settings -> WARP Client -> Device enrollment permissions (Manage) -> Rules -> Add a rule로 이동합니다.
rule 이름을 설정하고, include는 설정하지 않습니다.
include 대신 group을 적용할 예정입니다.

하단의 Assign a group에서 warp device enroll을 include로 바꿔줍니다.

cloudflare zero trust에 warp 클라이언트 설정

이제 client를 zero trust에 연결할 것입니다.

Settings -> WARP Client -> Device settings -> Profile settings -> Default -> Config
여기에서 warp 연결된 기기를 제어할 수 있습니다.
자동 재연결을 설정하여 끊을 수 없게 한다거나, zero trust에서 나가지 못하게 할 수 있고
Gateway with WARP인 경우 라우팅도 제어할 수 있습니다.

default에서 Split Tunnels를 제외한 설정을 적당히 설정하시고 저장합니다.
이 프로필을 복제한 다음에, 프로필의 Build an expression -> Selector을 수정하여 디바이스마다 프로필을 설정할 수 있습니다.
새로운 프로필에서 Split Tunnels을 건드릴거예요.
이제 기기마다 서로 다른 라우팅 테이블을 설정할수 있게 되겠지요.

Split Tunnels

지금 우리는 Settings -> WARP Client에 있습니다.
Split Tunnels은 tunnel이 아니라 WARP로 접속한 client에만 적용되는 설정입니다.

Split Tunnels는 어떤 ip/ 어떤 도메인 주소를 WARP 네트워크로 전달할 것인지 선택하게 됩니다.
기본 값으로 Exclude IPs and domains로 설정 되어있으며, local network가 예외로 되어있습니다.
즉 public IP로 통신하는 네트워크만 WARP로 전달이 됩니다.

하지만 패킷이 tunnel로 가려면 일단 WARP로 전달이 되어야 합니다.
Oracle Cloud Infrastructure의 private IP나 synology/qnap 등의 NAS의 private IP를 exclude 목록에서 제외되도록 설정해야 합니다.

주의사항
다음은 꼭 warp로 전달되면 안됩니다.
Include IPs and domains로 설정하더라도 다음 IP 주소는 포함되지 않도록 하세요
(0.0.0.0/0은 사용하지 마세요)

169.254.0.0/16 | DHCP unspecified
255.255.255.255/32 | DHCP Broadcast
fe80::/10 | IPv6 Link Local

cloudflare zero trust에 warp 클라이언트 추가

간단합니다.
settings -> Donwloads -> Download the WARP client에서 WARP client를 다운로드 합니다.
앱 안에서 설정 -> 계정에 가면 zero trust에 로그인 버튼이 있을거예요.
누르시고 zero trust의 team 이름을 입력합니다.

혹시 자신의 team 이름을 모른다면 Cloudflare zero trust dashboard에서 Settings -> Generel에서 확인할 수 있습니다.
cloudflareaccess.com 앞부분이 팀 이름입니다.

로그인 화면이 나타나면 여기에서 access Groups에서 허용한 계정으로 로그인합니다.

Cloudflare zero trust dashboard에서 My Team -> Devices에 장치가 표시되는 것을 확인할 수 있습니다.

cloudflare에 터널 추가

이제 tunnel을 통해서 서버들을 연결할 차례입니다.

deb/rpm 패키지 매니저 기반 linux

Cloudflare zero trust dashboard의 Access -> Tunnels에서 Create a tunnel 버튼을 누릅니다.
이름을 적고, 다음을 누르면 Install connector 화면이 나옵니다.

여기에서 Debian(x86, arm64), Red Hat(x86, arm64)를 누르면 안됩니다
이것을 따라하시면 안됩니다

저 방법으로 하면 업데이트를 할 때 rpm/deb 파일을 받아서 수동으로 해줘야 합니다.
그래서 우리는 repository를 추가해서 설치할 것입니다.
cloudflared packages에서 os에 맞는 절차를 따릅니다.

그리고 OS에 맞는 패키지 매니저로 설치합니다.
(ex: sudo dnf install cloudflared/ sudo apt install cloudflared)

Windows, Mac, Docker

Cloudflare zero trust dashboard의 Access -> Tunnels에서 Create a tunnel 버튼을 누릅니다.
이름을 적고, 다음을 누르면 Install connector 화면이 나옵니다.
여기에서 Windows, Mac, Docker(x86,arm64)를 누르면 복사 붙여넣기로 쉽게 연결할 수 있습니다.
docker는 network를 host로 하거나 bridge로 하여 docker의 포트를 열지 않고 사용할 수 있게 할수 있습니다.

Docker를 설치하지 않은, x86, systemd Linux

systemd (systemctl 명령 사용 가능한) linux

cloudflared 하나를 위해서 docker를 설치하고, docker daemon을 돌릴 필요는 없지요.
특히나 1 core에 ram 1GB인 Oracle Cloud Infrastructure의 E2 같은 머신이나,
Qnap이나 synology의 저사양 NAS는 더욱더 그렇습니다.

alpine과 같은 리눅스들은 deb나 rpm을 설치하지 못하고
apt, yum repository를 사용하지도 못하지만, systemd로 서비스를 생성할 수 있는 경우
이 방법을 따르면 됩니다.

설치

Cloudflare zero trust dashboard의 Settings -> Downloads로 이동합니다.
여기서 가장 하단의 binary 다운로드에 가서 링크를 복사합니다.

ssh로 다음을 실행합니다.

curl -O cloudflared ''
chmod +x cloudflared
sudo ./cloudflared service install 
# 업데이트 서비스와 시작시 실행되는 서비스가 설치되고, 서비스가 실행된다.

이 파일을 OS가 시작될 때 실행되도록 설정할 것입니다.

Docker를 설치하지 않은, x86, non-systemd Linux

qnap이나 synology는 systemctl을 사용하지 못합니다.
이런 경우 systemd service를 생성하지 못하는데 이 경우에 따라하면 되는 방법입니다.

x86 Linux Binary 다운로드

Cloudflare zero trust dashboard의 Settings -> Downloads로 이동합니다.
하단에 Download cloudflared에서 x86 binary를 다운로드 합니다.

시놀로지나 QNap은 DSM이나 QTS webui로 접근하여 파일을 올려주세요

tunnel 생성 및 cloudflared 실행

Cloudflare zero trust dashboard의 Access -> Tunnels에서 Create a tunnel 버튼을 누릅니다.
이름을 적고, 다음을 누르면 Install connector 화면이 나옵니다.
OS 버튼을 아무거나 누르면 토큰을 포함한 명령어가 출력됩니다.

이 박스를 클릭하면 복사되는데 메모장에서 뒤의 토큰 부분만 남기고 지워둡니다.

/binary/파일/위치/cloudflared --autoupdate-freq 24h0m0s tunnel run --token <token>으로 실행하면 됩니다.
시놀로지는 DSM의 작업 스케줄러에서 설정할 예정이므로 다음 섹션에서 설명 드리겠습니다

자동실행으로 등록

Qnap은 제어판 -> 시스템 -> 하드웨어 -> 시작하는 동안 사용자가 지정한 프로세스 실행을 통해서 cloudflared를 실행합니다.

시놀로지는 제어판 -> 서비스 -> 작업 스케쥴러를 추가해서 작업합니다.
시놀로지는 모델에 따라 커널이 구형이라서 에러가 발생할 수 있습니다.
다음과 같은 오류가 발생하면 cloudflared 설정 전에 kernel 설정을 해줘야 합니다.

failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size (https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size) for details.

해결 방법은 UDP Receive Buffer Size 페이지에서 찾았습니다.

시스템 실행시 시작되도록 하여 다음 코드를 삽입합니다

# 에러가 발생할 때만 넣어주세요.
sysctl -w kern.ipc.maxsockbuf=3014656
sysctl -w net.core.rmem_max=2500000
kern.ic.maxsockbut=3014656
# 에러가 발생할 때만 넣어주세요.

/binary/파일/위치/cloudflared --autoupdate-freq 24h0m0s tunnel run --token

x86이 아니면서 rpm/deb 기반이 아닌 리눅스

이 조건에 해당하면 직접 build해서 사용해야 합니다.
build 방법은 다른 분의 방법을 링크로 올려두겠습니다.

tunnel 연결 확인

tunnel을 세팅하고,
warp 단말에서 tunnel에 접속을 시도해볼것입니다.

tunnel Private Network란?

먼저 Private Network에 대한 설명이 필요할 것 같습니다.

앞서서 Split tunnel을 설정해주었습니다.
Split tunnel에 일치하는 패킷이 warp를 통해서 cloudflare로 전달 되었습니다.
이제 이 패킷이 public으로 나갈지 어떤 터널로 갈지 설정해야 합니다.

그림을 보고 설명 드리면, WARP에서는 split tunnel로 라우팅을 설정하고,
tunnel 구간은 Private IP로 라우팅을 결정합니다.

tunnel을 여러개 연결할 수 있기 때문에 이 설정이 필요합니다.
예를 들어서 집은 10.1.0.0/16 대역의 Private IP를 사용하고 있고,
오라클 클라우드는 10.2.0.0/16 대역의 Private IP를 사용중이라고 가정해봅시다.

그러면 WARP를 통해서 cloudflare CDN에 도착한 패킷은
목적지 IP가 10.1.0.0/16아면 home이라는 터널로 가야할 것이고
목적지 IP가 10.2.0.0/16은 Oracle Cloud라는 터널로 가야할 것입니다.

tunnels – Private Network 설정

앞서 설명한 이유로 warp로 들어온 packet이 모든 tunnel에 전달되거나
모든 패킷이 이 tunnel로 전달되는 것이 아닙니다.

여기에서는 이 tunnel로 들어와야 할 ip를 적습니다.
일단 접속 test이므로 /32로 설정해봅시다.

Cloudflare zero trust dashboard의 Access -> Tunnels에서 생성해두었던 tunnel의 configure로 이동합니다.
Private Network 탭에서 Add a private network를 설정합니다.

접속 test

이제 접속 test를 해봅시다.
warp가 연결된 단말에서 ssh 접속을 해보는 겁니다.
ssh user@<PrivateIP> -p <port>해서 되면.. 성공!

reverse proxy 대신 cloudflared 사용하기

cloudflare dns를 사용중이라면 먼저 없애야 합니다.

Cloudflare dashboard에서 DNS -> Records로 이동하여 tunnel로 옮길 dns를 제거합니다.

tunnel의 public hostname에 추가합니다.

Cloudflare zero trust dashboard의 Access -> Tunnels에서 생성해두었던 tunnel의 configure로 이동합니다.
Public Hostname으로 이동합니다.

service에서의 URL은 cloudflared에서 접속할 url을 적어야 합니다.
cloudflared와 nginx가 같은 host라면 localhost:80이 되겠죠!

마무리

이제 private IP로 SMB, ssh를 사용할 수 있습니다.
다른 VPN으로 연결할 필요도 없고, WARP에 연결해서 동시에 smb로 연결해서 10.1.1.1에서 10.255.255.254로 복사하는 것도 가능합니다.

다음 편에서는 Access -> Applications를 이용해서 웹 접근에 암호를 필요로 하게 하거나, SSH, VNC를 사용할수 있도록 해보겠습니다.

oracle cloud와 NAS(synology, qnap)를 Cloudflare zero trust tunnel에 연결해보자

개요

tunnel의 구성도