Tailscale exit node 설정: VPS로 VPN 구축하기

Tailscale exit node의 역할

Tailscale exit node는 tailnet 내의 다른 장치들이 사용하는 모든 인터넷 트래픽을 전달하는 장치입니다. VPS(virtual private server)는 고정된 공인 IP 주소를 가지고 항상 온라인 상태를 유지하므로 exit node로 사용하기에 적합합니다. 설정은 5단계로 진행됩니다. 서버에 Tailscale을 설치하고, exit node를 광고(advertise)하며, IP 포워딩을 활성화하고, 관리 콘솔에서 경로를 승인한 뒤, 마지막으로 노트북에서 해당 노드를 선택하면 됩니다. 네 번째 단계는 명령어가 아닌 웹 페이지상의 토글 스위치이므로, 많은 사용자가 이 부분에서 진행을 멈추곤 합니다.

기능이 활성화되면 노트북은 모든 패킷을 암호화하여 VPS로 전송합니다. VPS는 소스 NAT(network address translation)를 적용한 뒤 자신의 공인 IP 주소로 패킷을 내보냅니다. 웹사이트는 VPS의 주소를 보게 되며, 카페 Wi-Fi는 VPS로 향하는 암호화된 UDP 흐름 하나만 확인할 뿐 그 외의 내용은 알 수 없습니다.

Tailscale은 데이터 경로에 WireGuard를 사용하며, 키를 배포하고 NAT 환경에서 두 장치가 서로를 찾을 수 있도록 돕는 조정 서버(coordination server)를 포함합니다. 이 조정 서버 덕분에 아래 과정에서 별도로 키를 복사할 필요가 없습니다. 상세한 장단점을 확인하려면 Tailscale과 일반 WireGuard 비교 문서를 읽어보시기 바랍니다. 만약 터널의 모든 부분을 직접 관리하고 싶다면, 대신 VPS에 일반 WireGuard VPN 직접 호스팅하기를 참조하십시오.

아래 단계는 노트북에 이미 Tailscale이 설치되어 있고, 두 장치 모두 동일한 tailnet에 로그인되어 있다는 가정하에 진행합니다. tailnet은 사용자의 개인 Tailscale 네트워크를 의미하며, 네트워크 내의 모든 장치는 100.64.0.0/10 내부의 안정적인 주소를 할당받습니다.

VPS에 Tailscale 설치하기

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

설치 스크립트는 배포판에 맞는 패키지 저장소를 선택하고 tailscaled 데몬을 설치합니다. 이후 tailscale up 명령은 인증 URL을 출력합니다. 브라우저에서 해당 URL을 열고 노트북에서 사용하는 것과 동일한 계정으로 로그인하십시오. 다른 tailnet에 로그인된 VPS는 노트북과 연결할 수 없기 때문입니다.

tailscale status
tailscale ip -4

이제 tailscale status 명령을 실행하면 두 장치가 모두 표시되어야 합니다. tailscale ip -4 명령은 나중에 클라이언트에 전달할 VPS의 tailnet 주소를 출력합니다.

Tailscale은 터널을 구축하기 위해 TUN 장치가 필요합니다. KVM 기반 VPS에는 이 장치가 포함되어 있습니다. 호스트 커널을 공유하는 컨테이너 가상화 방식의 플랜에서는 /dev/net/tun 장치가 누락되는 경우가 있으며, 이 경우 tailscaled는 tailscale0 인터페이스를 생성할 수 없습니다. 진행하기 전에 ls -l /dev/net/tun 명령을 실행하십시오.

IP 포워딩 활성화 (활성화하지 않으면 VPS가 모든 패킷을 폐기함)

Linux 머신은 기본적으로 net.ipv4.ip_forward 값이 0이므로 자신에게 전달되지 않은 모든 패킷을 폐기합니다. 이 상태에서는 엑시트 노드가 트래픽을 수신하여 복호화하더라도 그대로 버리게 됩니다. 재부팅 후에도 설정이 유지되도록 파일에 설정을 기록하십시오.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

tee -a은 내용을 덧붙이는 방식이므로, 이 명령줄을 두 번 실행하면 두 설정이 파일에 두 번 기록됩니다. 결과적으로 동작은 하지만 cat /etc/sysctl.d/99-tailscale.conf의 내용이 보기 어색해질 수 있습니다. 파일의 내용을 맹신하지 말고 실제 적용된 값을 확인하십시오:

sysctl net.ipv4.ip_forward

반드시 net.ipv4.ip_forward = 1이 출력되어야 합니다. 이 과정을 건너뛰고 tailscale up --advertise-exit-node를 사용하면 클라이언트는 다음과 같은 메시지를 표시합니다:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node은 해당 검사를 수행하지 않으므로, set에서 아무런 메시지가 출력되지 않는다고 해서 포워딩이 활성화된 것은 아닙니다. 직접 sysctl 값을 읽어 확인하십시오.

수동으로 매스커레이드(masquerade) 규칙을 작성할 필요는 없습니다. tailscaled는 ts-input, ts-forward, ts-postrouting라는 이름의 자체 방화벽 체인을 설치하며, 엑시트 노드 트래픽을 위한 NAT 규칙은 ts-postrouting에 위치합니다. sudo iptables-save | grep ts-을 사용하여 확인하거나, nftables를 사용하는 환경이라면 sudo nft list ruleset을 사용하십시오.

VPS를 엑시트 노드로 광고하기

sudo tailscale set --advertise-exit-node

tailscale set는 하나의 설정값만 변경하며 나머지는 그대로 둡니다. tailscale up --advertise-exit-node은 노드를 광고하는 동시에 부작용을 일으킵니다. up은 명령줄에 입력된 플래그를 기본값이 아닌 전체 설정 세트로 간주하므로, 나중에 인자 없이 sudo tailscale up를 실행하면 다음과 같은 오류가 발생하며 실행이 거부됩니다.

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

지속적인 변경을 위해서는 set을 사용하십시오. 그러면 해당 메시지를 마주할 일이 없습니다.

광고는 하나의 제안입니다. 이제 VPS는 조정 서버에 자신이 엑시트 노드로 동작할 의사가 있음을 알립니다. 아직 어떤 클라이언트도 이 노드를 사용할 수는 없습니다.

관리 콘솔에서 Tailscale exit node 승인하기

이 단계는 별도의 명령어를 실행하지 않습니다. 관리 콘솔의 Machines 페이지를 열고 해당 VPS를 찾은 뒤, 행 끝에 있는 점 3개 메뉴를 클릭하여 Edit route settings를 선택하고 Use as exit node를 활성화합니다.

이 토글을 켜기 전까지는 제어 평면(control plane)이 해당 제안을 보류하며 누구에게도 전달하지 않습니다. 노트북에서 tailscale exit-node list를 실행해도 아무것도 나타나지 않으며, 트래픽은 기존 경로를 그대로 유지합니다. 양쪽 기기 모두에서 별도의 오류 메시지는 발생하지 않으며, 단지 exit node가 표시되지 않을 뿐입니다.

tailnet 정책 파일에 항목을 추가하여 exit node를 자동으로 승인할 수도 있습니다.

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

--advertise-tags=tag:exit 옵션으로 시작된 기기는 동일한 정책 파일 내의 tagOwners 아래에 tag:exit이 정의되어 있다면 자동으로 승인됩니다. 태그를 지정하면 소유권이 변경됩니다. 태그가 지정된 기기는 사용자 계정이 아닌 tailnet에 귀속되며, 해당 기기에 적용되는 접근 규칙도 그에 따라 변경됩니다. 단일 VPS의 경우에는 토글을 사용하는 방식이 더 간단합니다.

노트북에서 엑시트 노드 선택하기

Linux 클라이언트의 경우:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

exit-node list은(는) tailnet에서 승인된 엑시트 노드와 해당 주소를 출력합니다. 목록이 비어 있다면 승인 단계가 완료되지 않은 것입니다. macOS, Windows, iOS, Android에서는 Tailscale 앱의 Exit Node 메뉴 항목에서 동일한 선택을 할 수 있습니다.

서버가 아닌 클라이언트에서 확인하십시오:

curl -4 https://ifconfig.me

엑시트 노드를 선택하기 전과 후에 각각 한 번씩 실행하십시오. 주소가 로컬 주소에서 VPS의 공인 IP로 변경되어야 합니다. 엑시트 노드 사용을 중단하려면 다음을 실행하십시오:

sudo tailscale set --exit-node=

초기에 중요한 플래그가 하나 더 있습니다. 엑시트 노드가 선택되면 클라이언트는 192.168.1.50로 향하는 패킷을 포함한 모든 트래픽을 터널로 전송하므로, 프린터나 네트워크 스토리지의 응답이 중단됩니다. 로컬 네트워크를 로컬 경로로 유지하려면 다음을 사용하십시오:

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

출구 노드를 켰을 때 DNS가 변경되는 이유

기본적으로 출구 노드를 사용하는 장치는 모든 도메인에 대해 해당 출구 노드를 DNS(도메인 이름 시스템) 리졸버로 사용하며, 이는 테일넷(tailnet)에 설정된 전역 및 분할 DNS 네임서버 설정을 덮어씁니다. 이러한 동작은 의도된 것입니다. 만약 쿼리가 계속 로컬 네트워크의 리졸버로 전달된다면, 트래픽 자체는 비공개 상태일지라도 카페 라우터가 사용자가 방문하는 모든 사이트의 이름을 확인할 수 있기 때문입니다. 이름과 패킷은 동일한 경로를 통해 나가야 합니다.

내부 리졸버를 운영하는 사용자에게는 한 가지 문제가 발생합니다. 출구 노드가 켜져 있는 동안에는 의존하고 있던 테일넷 네임서버가 사용되지 않게 됩니다. 이를 다시 활성화하려면 관리 콘솔의 DNS 페이지에서 해당 네임서버에 대해 Use with exit node 옵션을 켜십시오.

MagicDNS 이름은 계속 작동합니다. Tailscale 클라이언트가 출구 노드에 도달하기 전 100.100.100.100에서 로컬로 응답하기 때문입니다. dig @100.100.100.100 your-vps.your-tailnet.ts.net을 사용하거나, Tailscale 인터페이스가 100.100.100.100을 DNS 서버로 나열하는 systemd-resolved 클라이언트에서 resolvectl status를 사용하여 이를 확인할 수 있습니다.

--accept-dns=false를 사용하여 Tailscale의 DNS 처리를 비활성화하면, 클라이언트는 로컬 네트워크에서 학습한 리졸버를 유지합니다. 트래픽은 터널링되지만 쿼리는 그렇지 않으며, 이는 직접 구축한 WireGuard 터널에서 발생하는 것과 동일한 DNS 유출입니다. 특별한 변경 사유가 없다면 --accept-dns는 그대로 두십시오.

출구 노드를 통한 IPv6 통신

출구 노드는 기본 경로인 0.0.0.0/0 및 ::/0을 모두 광고합니다. VPS에 인터넷으로 연결되는 정상적인 IPv6 경로가 없으면, IPv6 패킷은 터널을 통해 도착한 뒤 더 이상 전달되지 못합니다. 신뢰하기 전에 VPS에서 다음을 테스트하십시오.

ip -6 addr show
curl -6 https://ifconfig.me

요청이 실패한다면 VPS에 IPv6 업스트림이 없는 것입니다. 듀얼 스택 웹사이트는 보통 정상적으로 로드되는데, 이는 클라이언트가 IPv6 연결을 포기하고 IPv4로 재시도하기 때문입니다. 다만 이 재시도 과정으로 인해 각 사이트에 처음 연결할 때 지연 시간이 발생합니다. IPv6 전용 목적지는 계속해서 연결할 수 없습니다.

나머지 절반은 포워딩 설정입니다. net.ipv6.conf.all.forwarding를 0으로 둔 채 net.ipv4.ip_forward = 1만 설정하면 IPv4 경로는 정상적으로 작동하지만 IPv6는 블랙홀에 빠지게 됩니다. 사용자는 이를 오류로 인식하여 검색하기보다는 "일부 사이트가 느리다"는 현상으로 경험하게 됩니다. 두 설정 항목 모두 sysctl 파일에 포함되어야 합니다.

VPS가 서브넷 경로도 광고해야 합니까?

Exit node는 모든 인터넷 트래픽을 전달합니다. 서브넷 경로는 해당 경로를 광고하는 머신 뒤에 위치한 하나의 사설 대역을 전달합니다. 이 둘은 별개의 기능이며 각각 승인이 필요하지만, 하나의 머신이 두 기능을 모두 수행할 수도 있습니다.

sudo tailscale set --advertise-routes=10.0.0.0/24

VPS가 사설 주소로 접근하려는 다른 서버들과 사설 네트워크를 공유하는 경우 서브넷을 광고하십시오. 동일한 Edit route settings 패널의 개별 토글에서 해당 경로를 승인할 수 있습니다.

대역을 신중하게 선택하십시오. 광고된 경로는 노트북의 기본 경로보다 우선순위가 높으므로, VPS에서 192.168.1.0/24을 광고하면 동일한 대역을 사용하는 홈 네트워크의 주소를 가로채게 되어 책상 위의 기기들이 통신 불능 상태가 될 수 있습니다. 홈 공유기가 자동으로 할당한 대역이 아닌, 직접 지정한 대역을 사용하십시오.

UDP GRO forwarding을 사용하여 exit node 속도 향상하기

Tailscale 1.54 버전 이상과 Linux 6.2 이상의 커널 환경에서는 전달되는 트래픽의 처리량을 높이는 수신 오프로드 기능을 사용할 수 있습니다. GRO(generic receive offload)는 커널이 패킷을 하나씩 처리하기 전에 들어오는 패킷들을 병합합니다. 2026년 8월 기준으로 이 설정은 exit node에서 수동으로 수행해야 합니다.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8은 실제로 인터넷에 연결되는 인터페이스를 보고하므로 eth0, ens3, enp1s0 사이에서 고민할 필요가 없습니다. ethtool -k $NETDEV | grep udp-gro-forwarding로 확인하면 이제 on으로 표시되어야 합니다.

이 설정은 재부팅 시 초기화됩니다. networkd-dispatcher를 사용하는 시스템이라면 다음 명령으로 자동화할 수 있습니다.

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

먼저 /etc/networkd-dispatcher/routable.d/이 존재하는지 확인하십시오. 파일이 없다면 해당 시스템은 networkd-dispatcher를 사용하지 않는 것이므로, 부팅 시 ethtool 라인을 실행하는 간단한 systemd unit을 생성하여 동일한 작업을 수행할 수 있습니다.

제공업체의 이용 약관이 출구 트래픽에 의미하는 바

클라이언트가 출구 노드를 통해 보내는 모든 패킷은 VPS의 공인 IP 주소를 달고 나가므로, 해당 활동은 귀하의 계정으로 귀속됩니다. 저작권 침해 통지나 포트 스캔 관련 불만 사항과 같은 악용 사례 보고서가 귀하의 메일함으로 전달됩니다. 가정이나 팀 전체의 트래픽을 하나의 서버로 라우팅하기 전에 제공업체의 AUP(이용 약관)를 확인하십시오. 또한, 신원을 보증할 수 없는 사람들에게는 출구 노드를 개방하지 마십시오.

대역폭은 두 번 계산됩니다. 트래픽이 터널을 통해 VPS에 도착한 뒤 다시 인터넷으로 나가기 때문에, 두 방향 모두 해당 요금제의 데이터 전송 허용량에서 차감되는 것이 일반적입니다. 출구 노드를 통해 시청하는 동영상 스트리밍은 대부분의 사용자가 예상하는 것보다 훨씬 큰 데이터 사용량을 차지합니다.

데이터 센터의 주소 대역은 고유한 평판을 가집니다. 일부 사이트는 이러한 주소 대역에 더 많은 CAPTCHA를 요구하며, 일부 스트리밍 서비스는 접속을 완전히 차단하기도 합니다. 이는 제공업체가 보유한 주소 블록의 특성이므로 귀하의 설정 변경으로는 해결할 수 없습니다.

트래픽이 여전히 로컬 연결을 통해 나가는 이유

출구 노드가 광고되었으나 승인되지 않았습니다. 클라이언트에서 tailscale exit-node list를 실행해도 아무것도 출력되지 않으며, 양쪽 장비 모두 오류 로그를 남기지 않습니다. Machines 페이지로 이동하여 Use as exit node를 활성화하십시오.

클라이언트가 해당 노드를 선택하지 않았습니다. 승인 절차는 해당 노드를 tailnet에서 사용할 수 있게 만들 뿐입니다. 선택은 각 장치에서 별도로 수행해야 하는 작업입니다. sudo tailscale set --exit-node=<name>을 다시 실행한 다음, curl -4 https://ifconfig.me을 다시 확인하십시오.

포워딩이 꺼져 있습니다. 이 문제는 증상이 명확합니다. tailscale ping <vps>는 성공하고 터널은 확실히 연결되어 있으나, 모든 외부 주소에 대해 타임아웃이 발생합니다. sysctl net.ipv4.ip_forward의 값이 0으로 나옵니다. sysctl 파일을 수정하고 sudo sysctl -p /etc/sysctl.d/99-tailscale.conf를 실행하십시오.

방화벽이 포워딩된 패킷을 차단하고 있습니다. tailscaled는 자체적인 ts-forward 체인을 삽입하며, 깨끗한 상태의 VPS라면 이것만으로 충분합니다. 하지만 ufw나 Docker가 이미 실행 중인 환경에서는 FORWARD 정책이 DROP으로 설정되어 있거나, Tailscale의 규칙보다 우선하는 규칙이 존재할 수 있습니다. 추측하지 마십시오. 클라이언트가 페이지를 로드하는 동안 sudo iptables -L FORWARD -n -v을 실행하여 어떤 카운터가 증가하는지 확인하십시오. ufw를 사용하는 환경에서는 일반적으로 /etc/default/ufw 파일에 DEFAULT_FORWARD_POLICY="ACCEPT"을 추가한 뒤 sudo ufw reload을 실행하여 해결합니다. 서버에서 실행 중인 설정과는 별개로, 제어판에서 제공업체의 네트워크 방화벽 설정도 함께 확인하십시오.

연결은 되지만 속도가 느립니다. 양쪽 장비에서 tailscale netcheck을 실행하십시오. 만약 UDP가 차단되었다고 표시된다면, 두 장치가 직접 경로를 생성하지 못하고 DERP 릴레이를 거치게 되어 모든 연결의 지연 시간이 증가합니다. 제공업체의 네트워크 방화벽에서 포트 41641로 들어오는 UDP 트래픽을 허용하면 보통 직접 경로가 복구됩니다.

Tailscale의 조정 서버를 떠나야 할 때

위의 모든 과정은 키 교환과 사용자가 클릭한 승인을 위해 Tailscale이 호스팅하는 조정 서버에 의존합니다. 트래픽은 여전히 노트북에서 VPS로 직접 전달되며 조정 서버가 이를 운반하지는 않지만, 누가 tailnet에 참여할 수 있는지와 각 장치가 무엇에 접근할 수 있는지는 조정 서버가 결정합니다. 이러한 의존성을 제거하고 싶다면 Headscale을 직접 Tailscale 제어 서버로 실행하고 두 클라이언트 모두 이를 가리키도록 설정하십시오. 이후의 exit node 설정 단계는 동일하며, 경로 승인은 호스팅된 콘솔 대신 Headscale 명령줄을 통해 수행됩니다. Headscale은 제어 평면만 교체할 뿐 Tailscale 클라이언트는 그대로 유지합니다. 만약 전체 스택을 직접 운영하고 싶다면 NetBird가 제공하는 자체 조정 서버와 클라이언트를 하나의 VPS에 호스팅하십시오.

FAQ

엑시트 노드를 선택했는데도 왜 트래픽이 여전히 로컬 연결을 사용합니까?

두 가지 일반적인 원인이 있습니다. 첫째, 엑시트 노드가 광고는 되었으나 승인되지 않은 경우입니다. 관리 콘솔의 Machines 페이지를 열고 해당 VPS를 찾은 뒤, Edit route settings를 선택하여 Use as exit node를 켭니다. 승인은 콘솔에서 전환하는 설정이며, 서버의 어떤 명령어로도 수행할 수 없습니다. 둘째, IP 포워딩이 꺼져 있는 경우입니다. 이 경우 터널은 생성되어 VPS로의 tailscale ping는 작동하지만, 모든 외부 주소는 타임아웃됩니다. sysctl net.ipv4.ip_forward 명령어로 확인하십시오. 값이 1이어야 합니다.

엑시트 노드를 매번 수동으로 승인해야 합니까?

이 설정은 각 머신당 한 번만 수행하면 됩니다. VPS를 자주 재구축한다면, "exitNode": ["tag:exit"]를 포함하는 autoApprovers 블록을 테일넷 정책 파일에 추가하고, tagOwners 아래에 tag:exit을 정의한 뒤, --advertise-tags=tag:exit 명령어로 노드를 시작하십시오. 태그가 지정된 장치는 사용자 계정이 아닌 테일넷이 소유하게 되며, 이에 따라 적용되는 접근 규칙도 변경됩니다.

엑시트 노드가 켜져 있을 때 내 노트북은 어떤 DNS 서버를 사용합니까?

엑시트 노드 자체를 사용합니다. 엑시트 노드를 사용하는 장치는 모든 DNS 쿼리를 해당 노드로 보내며, 이는 테일넷에 설정된 전역 및 분할 DNS 네임서버보다 우선합니다. 이로 인해 로컬 네트워크는 사용자가 조회하는 도메인 이름을 확인할 수 없습니다. 특정 테일넷 네임서버를 계속 적용하려면 관리 콘솔의 DNS 페이지에서 해당 서버에 대해 Use with exit node를 활성화하십시오. MagicDNS 이름은 Tailscale 클라이언트가 100.100.100.100에서 로컬로 응답하므로 여전히 해석됩니다.

하나의 VPS가 동시에 엑시트 노드이자 서브넷 라우터가 될 수 있습니까?

네, 가능합니다. sudo tailscale set --advertise-exit-node과 sudo tailscale set --advertise-routes=10.0.0.0/24은 독립적이며, 각각 Edit route settings에서 별도의 승인 토글을 가집니다. 두 기능 모두 VPS에서 IP 포워딩이 활성화되어 있어야 합니다. 노트북의 홈 네트워크와 일치하는 대역을 광고하지 마십시오. 광고된 경로가 기본 경로보다 우선순위가 높기 때문에 로컬 장치에 접근할 수 없게 됩니다.

엑시트 노드를 사용하면 VPS 제공업체로부터 트래픽을 숨길 수 있습니까?

아니요. 터널은 VPS에서 종료되므로 트래픽은 목적지가 요구하는 형식으로 서버를 떠나게 되며, 사이트 자체가 암호화되지 않은 경우 제공업체는 이를 평문으로 전송하게 됩니다. 엑시트 노드는 트래픽이 인터넷으로 나가는 지점을 현재 사용 중인 네트워크에서 임대한 서버로 옮겨줄 뿐입니다. 이는 카페 Wi-Fi나 가정용 ISP로부터 브라우징 기록을 숨겨주지만, VPS 제공업체에는 귀하의 계정 이름과 함께 동일한 브라우징 기록이 노출됩니다.