Tailscale exit node를 실전 관점에서 깊이 있게 살펴본다. 라우팅 변화, traceroute 증거, DERP 폴백, 신뢰 경계, 그리고 이 모델이 무료일 수 있는 이유까지 다룬다.
저는 현재 새로운 기회를 찾고 있습니다! 이력서 보기 또는 LinkedIn에서 연결하기.
집의 Tailscale exit node를 실전적으로 깊이 파고든 글이다. 라우트 변화, traceroute로 확인한 증거, DERP 폴백, 신뢰 경계, 그리고 이 모델이 무료일 수 있는 이유까지 다룬다.
2026년 3월 31일·17분·3524단어
목차
저는 몇 년 전에 Tailscale을 설정했지만, 그동안은 “내 기기에 접속하기” 같은 용도로만 사용했습니다. 그런데 이번 주에 드디어 제대로 된 집용 exit node를 구성했습니다. 제 Proxmox 박스 위에 올린 작고 전용인 LXC 하나입니다(1 vCPU, 512 MB RAM, 사실상 Tailscale만 돌아감).
잘 동작하는지 확인하려고 집 서버들에 ping을 날려봤고, 문제없이 되었습니다. 하지만 더 깊이 이해하고 싶어서 traceroute를 사용해봤습니다.
traceroute github.com
traceroute to github.com (<destination-ip-redacted>), 64 hops max, 40 byte packets
1 tailscale-gw (100.x.y.z) ~7 ms
2 192.168.x.1 ~7 ms
3 10.x.x.1 ~9-177 ms
4 * * *
5 * * *
6 * * *
7 home-isp-edge.example (<home-public-ip>) ~11-14 ms7번째 홉에서 제 머릿속 톱니바퀴가 돌아가기 시작했습니다. 저건 제 집 ISP입니다. 그럼 이건 VPN 같은 걸까요? 아니면 다른 걸까요?
exit node가 없으면, Tailscale은 제 Tailscale 기기들 로 가는 트래픽은 보내주지만 일반적인 웹 트래픽은 제 로컬 네트워크나 ISP를 통해 나갑니다(exit nodes docs).
exit node를 켜면, 제 기기는 기본 인터넷 경로 를 선택한 기기로 바꾸고, 그 기기가 대신 인터넷으로 트래픽을 내보냅니다.
인터넷 트래픽 관점에서 exit node는 전통적인 VPN 게이트웨이처럼 동작합니다. 다만 한 가지 단서가 있습니다. Tailscale은 항상 모든 트래픽을 위한 VPN 터널인 것은 아니지만, exit-node 모드에서는 그렇습니다.
exit node가 없을 때는 Tailscale에 노출한 서비스들을 발견하고 접근하는 정도에 가깝습니다. exit node가 있으면, 우리 기기는 인터넷 트래픽에 대해 사실상 full-tunnel VPN 모드로 동작합니다.
exit node까지 가는 트래픽은 암호화되며, 우리가 접속하는 웹사이트는 현재 기기가 연결된 ISP의 IP가 아니라 exit node의 공인 IP를 보게 됩니다.
Exit Node는 익명성이 아니다
exit node는 신뢰를 두는 위치를 옮길 뿐, 신뢰 자체를 완전히 없애지는 않습니다. 카페 WiFi는 여러분이 Tailscale로 암호화된 트래픽을 보내고 있다는 사실과 트래픽 양 정도는 볼 수 있지만, 내용은 읽을 수 없습니다. exit node는 트래픽이 어디로 가는지(대상 IP/도메인 같은 메타데이터)는 여전히 볼 수 있고, 웹사이트는 exit node의 공인 IP를 보게 됩니다.
라우팅 이야기에 들어가기 전에, 우선 Tailscale이 애초에 기기들을 어떻게 연결하는지 짚고 넘어가고 싶습니다. 저는 계속 VPN에 비유하고 있었지만, Tailscale은 사실 WireGuard 위에 제어 평면이 올라간 메시 네트워크입니다.
제어 평면 vs 데이터 평면
아주 쉽게 말하면, 제어 평면은 지도이자 교통경찰이고 데이터 평면은 도로입니다. 제어 평면은 누가 누구와 통신할 수 있는지, 어떻게 도달할지를 결정합니다. 데이터 평면은 암호화된 패킷을 실제로 운반합니다(control/data plane docs).
WireGuard 자체는 대부분 데이터 평면 에 가깝습니다. Tailscale은 그 위에 제어 평면 을 추가합니다. 여기에는 identity/SSO, 피어 발견, NAT traversal 조정, ACL 배포, 라우트 배포(exit node 기본 라우트 포함), MagicDNS, 그리고 빠른 기기 폐기가 포함됩니다. 우리도 직접 WireGuard 터널을 운영할 수는 있지만, 그러면 그 제어 평면 기계장치 대부분을 직접 만들고 운영해야 합니다.
두 기기가 연결될 때 흐름은 대략 이렇습니다.
카페에 있는 여러분의 휴대폰과 집 서버가 둘 다 라우터 뒤에 있다고 상상해봅시다. NAT는 누가 밖으로 나갔는지는 추적하지만, 외부의 아무나 직접 들어오게 하지는 않는 프런트 데스크 같은 것입니다. hole-punching은 양쪽이 동시에 “밖으로 한 발 나가게” 만들어, 각자의 라우터가 되돌아오는 경로를 허용하게 하려는 시도입니다. 그 타이밍이나 매핑이 실패하면 DERP가 중립적인 만남의 장소 역할을 합니다. DERP는 피어 사이의 암호문을 전달하지만 이를 복호화할 수는 없습니다.
즉 exit node는 제가 일반적인 인바운드 VPN 포트를 노출해서 연결되는 것이 아니라, 발견 가능한 피어가 되고 WireGuard 핸드셰이크를 완료함으로써 연결됩니다. exit node의 경우 구체적으로는, 노드가 0.0.0.0/0와 ::/0를 제어 평면에 광고하고, 제어 평면이 이를 자격 있는 클라이언트에게 알려주고, 클라이언트가 그것을 선택합니다. 그러면 그 시점부터 모든 인터넷 트래픽이 암호화된 피어 터널을 통해 흐릅니다.
라우트 수준에서 보면, exit node를 활성화하면 일반적으로 다음과 같은 일이 일어납니다.
0.0.0.0/0와 ::/0)를 수락합니다.tailscale0, macOS에서는 utun, Windows에서는 Wintun; 이름은 달라도 역할은 동일)로 가도록 정책 라우트를 설치합니다.allow LAN access 설정에 따라 로컬 LAN 라우트를 유지하거나 억제합니다.라우트란 “목적지 X로 가는 패킷은 다음 홉 Y로 보내라”라고 말하는 규칙일 뿐입니다. 기본 라우트는 일반 인터넷 트래픽을 위한 포괄 규칙입니다. “탈출 경로” 라우트는 exit node의 실제 공인 엔드포인트로 가는 트래픽이 일반 네트워크 경로를 유지하게 해서, 터널이 자기 자신을 다시 터널링하지 않게 해줍니다.
운영체제별 내부 구현은 다르지만, 사용자 입장에서의 결과는 같습니다.
ip rule + 별도 라우팅 테이블)을 사용해 기본 트래픽을 tailscale0로 유도하고, 동시에 루프를 피하기 위해 터널 전송 트래픽을 예외 처리합니다.Tailscale의 exit-node 모드와 OpenVPN은 둘 다 하나의 게이트웨이로 full-tunnel을 만드는 점은 같지만, 내부 동작 방식은 다릅니다. Linux에서는 그 차이가 가장 분명합니다.
tun0로 가도록 만듭니다(보통 0.0.0.0/1 + 128.0.0.0/1 사용). 그리고 VPN 서버에 대해서는 하나의 탈출 경로를 둡니다.ip rule + 별도 라우팅 테이블을 사용하고, 정책 기반으로 트래픽을 선택하며, 루프에서 제외하기 위해 터널 전송 패킷에 마킹을 합니다.macOS에서는 둘 다 utun 인터페이스를 만들고, 기본 트래픽을 그쪽으로 보내며, 터널 엔드포인트에 대해서는 예외 경로를 유지합니다. 차이는 라우팅 주변의 시스템에 있습니다. WireGuard vs OpenVPN 프로토콜, 메시 토폴로지 vs 클라이언트-서버 구조, Tailscale의 기기 identity vs OpenVPN 인증서, 그리고 DERP 폴백을 포함한 Tailscale의 NAT traversal 같은 부분들입니다.
처음에 저를 놀라게 했던 점은 이것입니다. Tailscale의 coordination 서비스는 주로 패킷을 실어 나르는 데이터 평면이 아니라 제어 평면이라는 것입니다(how Tailscale works, DERP). 이 서비스는 기기들이 서로를 찾고, identity와 정책을 교환하고, 암호화된 피어 경로를 설정하도록 도와줍니다. 실제 트래픽은 가능하면 그 다음부터 직접 peer-to-peer로 흐릅니다.
exit node의 정상 경로는 이렇습니다.
client -> exit node -> internet
직접 연결이 막혀 있으면 DERP 릴레이가 폴백이 됩니다.
client -> DERP relay -> exit node -> internet
어느 경우든 인터넷으로 나가는 지점은 여전히 exit node입니다. DERP는 암호화된 패킷을 전달할 뿐입니다. 이것은 전송 계층 폴백이지, 여러분의 브라우징이 종료되는 지점이 아닙니다. 이 폴백은 주로 제한이 심한 네트워크에서 발동합니다. UDP/피어 경로를 막는 회사나 게스트 WiFi, 더 엄격한 carrier-grade NAT, 혹은 아웃바운드 트래픽이 강하게 통제되는 환경 같은 곳입니다. 전형적인 가정 환경(제 경우 집 인터넷에 연결된 Proxmox 노드 같은 경우)에서는 직접 피어 연결이 보통 잘 되므로, DERP는 거의 나타나지 않을 수도 있습니다.
이것이 Tailscale이 무료 티어를 제공할 수 있는 이유이기도 합니다. 전통적인 VPN 제공업체는 여러분의 트래픽이 그들의 서버를 통과하므로 사용한 모든 대역폭 비용을 부담해야 합니다. Tailscale 모델에서는 제 집 ISP와 exit-node 머신이 송신 트래픽을 담당하고, Tailscale 인프라는 그것을 담당하지 않습니다.
사용자 100,000명에 대한 대충 계산해보면:
100,000 * 100 GB = 10,000,000 GB/month (월 10 PB)$0.02-$0.05/GB 비용으로 전부 중계해야 한다면, 대역폭 비용만 해도 대략 $200,000-$500,000/month입니다.500,000 GB/month가 되고 대략 $10,000-$25,000/month입니다.100,000 GB/month가 되고 대략 $2,000-$5,000/month입니다.이 계산은 대략적인 가정에 기반한 설명용 수치일 뿐이며, Tailscale 내부의 실제 트래픽 비율이나 정확한 비용을 주장하는 것은 아닙니다.
무엇과 비교하느냐에 따라 달라집니다.
Nord/Mullvad/상용 VPN과 비교하면: 여러분은 다른 누군가가 여러분의 대역폭을 운반해주는 비용을 내는 것입니다. 일반적인 가격은 사용자당 월 $3-$12 정도입니다. 그 대가로 전 세계 exit 위치와 설정이 거의 필요 없는 편의성을 얻지만, 트래픽 메타데이터는 그들의 인프라에 맡기게 됩니다. 집에 둔 Tailscale exit node를 쓰면, 이미 ISP에 내는 비용 외에 대역폭 비용은 사실상 0입니다. 대신 한 위치(집 IP)에서만 나갈 수 있다는 절충이 있습니다.
셀프 호스팅 OpenVPN과 비교하면: 여기서는 비교가 더 흥미로워집니다. 목표가 같기 때문입니다. 즉, 자기만의 게이트웨이를 운영하는 것입니다. 하지만 OpenVPN을 인터넷에서 접근 가능하게 만들려면, Tailscale이 대신 처리해주는 여러 문제를 직접 해결해야 합니다.
정리하면 이렇습니다. 상용 VPN은 편의성과 다양한 exit 위치를 돈으로 사는 모델입니다. 셀프 호스팅 OpenVPN은 제어권을 위해 운영 부담을 감수하는 모델입니다. Tailscale exit node는 그 중간에 있습니다. 셀프 호스팅의 제어권은 얻되, 포트 포워딩, DDNS, PKI, NAT traversal의 골칫거리는 줄일 수 있습니다.
제가 curl example.com을 입력하면, 명령은 어느 쪽이든 같아 보이지만 그 뒤의 네트워크 경로는 달라집니다. 아래 표는 그 두 경로를 단계별로 비교한 것입니다.
curl example.com을 예로 들어, 흐름을 나란히 비교해봅시다.
| Step | Without Exit Node | With Tailscale + Exit Node |
|---|---|---|
| 1. 클라이언트의 라우트 결정 | 기본 라우트가 로컬 라우터 / ISP 게이트웨이를 가리킨다. | 기본 라우트가 Tailscale로 유도되며, 선택한 exit node를 대상으로 한다. |
| 2. 첫 번째 네트워크 홉 | 패킷이 로컬 네트워크 인터페이스를 통해 직접 ISP 경로로 나간다. | 패킷이 터널 안에서 암호화되어 exit node 피어를 향해 전송된다. |
| 3. 전송 경로 | 현재 네트워크에서 출발하는 일반 인터넷 경로. | 가능하면 직접 peer-to-peer, 직접 경로가 실패하면 DERP 릴레이. |
| 4. 인터넷 송신 지점 | 현재 네트워크의 공인 IP로 요청이 나간다. | Exit node가 복호화하고 NAT를 적용한 뒤, 자신의 공인 IP로 내보낸다. |
| 5. 응답 반환 경로 | 응답이 현재 네트워크의 공인 IP로 직접 돌아온다. | 응답이 exit node로 돌아온 뒤, 암호화된 터널을 통해 다시 클라이언트로 간다. |
| 6. 웹사이트가 보는 것 | 현재 연결된 네트워크의 IP/주소 맥락. | Exit node 네트워크의 IP/주소 맥락. |
이제 traceroute 출력을 다시 봅시다. 서두에서 본 출력은 1홉이 제 Tailscale exit gateway였고, 7홉쯤에서 집 ISP 엣지에 도달했습니다. 같은 MacBook을 exit node 없이 사용했을 때와 비교하면 이렇습니다.
traceroute github.com
traceroute to github.com (<destination-ip-redacted>), 64 hops max, 40 byte packets
1 192.168.x.1 ~4-5 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 cafe-or-local-isp-edge.example (<local-public-ip>) ~11-16 ms
8 isp-backbone.example ~11 ms
9 * * *
10 upstream-cloud-edge.example ~31-36 ms
11 upstream-core.example ~32-71 ms
12 destination-network-edge.example ~31-40 msexit node가 없으면 1홉은 그냥 로컬 라우터이고, 그 다음은 로컬 ISP 경로와 상위 인터넷 홉들입니다. 송신 위치가 바뀌는 것이 핵심적인 신호입니다.
이건 제가 원하던 것과 정확히 맞아떨어졌습니다. 즉, 트래픽이 현재 MacBook이 연결된 네트워크가 아니라 집을 통해 나간다는 뜻입니다.
여기서 바뀌는 것은 주로 트래픽이 어디서 나가는지, 그리고 로컬 네트워크에서 누가 메타데이터를 관찰할 수 있는지입니다. 반대로 바뀌지 않는 것은, 콘텐츠 보호의 핵심이 여전히 HTTPS라는 점입니다.
저는 exit node를 켜고 끌 때 작은 체크리스트를 사용합니다.
# 1) Egress identity check
curl ifconfig.me
# 2) Path shape check
traceroute github.com
# 3) Exit node health/path check
tailscale status
tailscale ping <exit-node-name>
# 4) DNS behavior check
dig <my-internal-domain>
dig github.com기대하는 신호는 다음과 같습니다.
curl ifconfig.me는 집/exit-node 공인 IP로 바뀌어야 합니다.traceroute는 활성화되었을 때 1홉이 exit-node 경로로 보이어야 합니다.tailscale ping은 가능하면 direct path를, 필요하면 DERP를 보여줘야 합니다.이 부분이 저에게는 전체 모델을 단번에 이해하게 만든 지점이었습니다. exit node는 단순히 Tailscale에서 “온라인 상태”인 것이 아니라, 실제 라우터 역할을 수행하고 있었습니다.
Exit Node의 책임
exit node는 라우터 역할을 하므로 IP forwarding이 활성화되어 있어야 하고 NAT/masquerade도 설정되어 있어야 합니다. 평범한 말로 하면 이렇습니다. Tailscale에서 온 패킷을 받아 인터넷으로 내보내고, 돌아오는 응답을 올바른 클라이언트에 다시 매핑해야 합니다. forwarding이나 NAT가 빠져 있으면 클라이언트는 연결된 것처럼 보여도 인터넷 트래픽은 깨집니다. 그리고 신뢰가 “무작위 카페 네트워크”에서 “내가 소유한 exit node 머신”으로 이동하는 지점도 바로 여기입니다.
Proxmox LXC에서의 함정
Proxmox LXC 컨테이너 안에서 Tailscale을 실행한다면(저처럼), 기본 상태에서는 바로 동작하지 않습니다. LXC 컨테이너는 기본적으로 /dev/net/tun에 접근할 수 없고, Tailscale은 이것이 필요합니다. Proxmox 호스트 에서 컨테이너 설정 파일(/etc/pve/lxc/<CTID>.conf)에 다음을 추가해야 합니다.
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
이것을 추가한 뒤 컨테이너를 재시작하세요. 최신 Proxmox 버전(7+)에서는 웹 UI의 컨테이너 Options > Features에서 TUN 기능을 활성화할 수도 있습니다. 뭐가 더 끔찍한지 모르겠습니다. Proxmox UI인지, 아니면 그 복잡하게 여러 갈래로 나뉜 CLI인지.
제 LXC exit node에서 설정은 크게 두 가지로 요약됩니다.
# /etc/sysctl.d/99-tailscale.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1iptables masquerade 규칙으로 이것을 자동 처리하지만, 디버깅 중이라면 다음으로 확인할 수 있습니다.iptables -t nat -L POSTROUTING -v그런 다음 exit node 자체에서는 역할을 광고합니다.
tailscale up --advertise-exit-node클라이언트에서는 그것을 선택합니다.
tailscale up --exit-node=<exit-node-name>이 때문에 exit-node 설정이 망가졌을 때 꽤 헷갈릴 수 있습니다. tailscale status는 피어가 “connected”라고 보여주지만, exit node 쪽에서 forwarding이나 NAT가 잘못 설정되어 있어서 인터넷 접속은 여전히 실패할 수 있기 때문입니다.
보안 이야기는 결국 신뢰를 어디에 두느냐의 문제입니다. exit node가 없으면, 현재 접속한 네트워크를 더 신뢰하는 쪽에 가깝습니다. exit node가 있으면, 게이트웨이로 선택한 머신을 더 신뢰하는 쪽에 가깝습니다.
제 경우 이 신뢰 판단은 정당화하기 쉽습니다. 이 exit node는 집에 있는 제 Proxmox 서버 위의 LXC이고, 의도적으로 아주 최소화해 두었습니다(1 vCPU, 512 MB RAM, 사실상 Tailscale만 실행).
누가 무엇을 볼 수 있는가
| Party | 보통 볼 수 있는 것 | 보통 볼 수 없는 것 |
|---|---|---|
| 카페 WiFi / 로컬 ISP | Tailscale에 연결되어 있다는 사실, 트래픽 양/타이밍 | 터널링된 트래픽의 내용 |
| Exit node 운영자 | 목적지 메타데이터(IP/도메인 패턴), 양/타이밍, 그리고 평문 HTTP | 종단 간 HTTPS 페이지 내용 |
| 방문한 웹사이트 | 여러분의 요청과 exit node의 공인 IP | 카페 네트워크의 공인 IP |
이제 카페 라우터의 관점만 조금 더 확대해봅시다.
| Scenario | 카페 라우터가 보통 보는 것 | 보통 볼 수 없는 것 |
|---|---|---|
| Exit node 없이 | 여러분의 기기에서 여러 목적지 IP로 향하는 일반 인터넷 흐름, 그리고 트래픽 타이밍과 양 | HTTPS 페이지 내용, 비밀번호, 메시지 본문 |
| Tailscale + exit node 사용 시 | 주로 Tailscale 피어/릴레이로 향하는 하나의 암호화된 터널 흐름과 타이밍/양 메타데이터 | 터널을 통해 도달하는 최종 웹사이트/서비스와 터널 내부 요청 내용 |
작은 단서 하나: DNS 처리는 OS와 설정에 따라 달라질 수 있으므로, 여기서 “보통”이라는 표현은 의도적으로 사용한 것입니다.
저에게는 이것이 실용적인 규칙입니다. 그 머신에 아웃바운드 메타데이터를 맡기고 싶지 않다면, exit node로 써서는 안 됩니다. 그래서 저는 거의 아무것도 올리지 않은 작은 전용 컨테이너에서 이것을 돌립니다. 특히 npm 패키지가 제 네트워크를 무너뜨릴 수 없는 곳에서요.
집의 exit node를 통해 라우팅하기 시작하고 나서 깨달은 점 하나가 있습니다. 원격 세션에서 AdGuard의 DNS 텔레메트리가 훨씬 예측 가능해진다는 것입니다.
제 MacBook이 다른 네트워크에 있어도 exit node를 사용하면, 집의 DNS 스택에 도달하는 쿼리는 집 경로를 통해 들어온 것처럼 보입니다. 실전에서는 이것이 “VPN으로 라우팅된 기기에서 온 것”이라는 보기 좋은 묶음을 한 곳에 만들어줍니다.
물론 절충도 있습니다. DNS와 NAT 구성이 어떤지에 따라 기기별 식별은 더 흐려질 수 있습니다. 하지만 제 사용 사례에서는 전체적인 가시성이 오히려 이득입니다.
DNS와 라우팅은 관련은 있지만 같은 조절 손잡이는 아닙니다. exit-node 모드는 인터넷 트래픽이 어디서 나가는지를 바꾸고, DNS 설정은 이름 조회에 어떤 리졸버가 답할지를 결정합니다.
DNS 이야기
exit node는 인터넷 트래픽이 나가는 위치를 바꾸지만, DNS 동작은 여전히 리졸버 설정에 따라 달라집니다. MagicDNS와 split DNS는 일치하는 도메인을 계속 Tailscale이 설정한 DNS 서버로 보냅니다. 공용 조회는 여전히 시스템 리졸버 경로를 따를 수 있으며, 이는 OS와 설정에 따라 달라집니다. 실용적인 규칙은 둘 다 테스트하는 것입니다. 이름은 dig/nslookup으로, 공인 IP 송신은 curl ifconfig.me로 확인하면 됩니다.
디버깅할 때 저는 다음 순서로 확인합니다.
curl ifconfig.me가 exit node 공인 IP와 일치한다..home.arpa를 AdGuard로 라우팅하기#저는 Tailscale에서 split DNS를 설정해서, .home.arpa 아래의 모든 것(제가 선택한 로컬 도메인)이 집 네트워크에서 동작하는 AdGuard DNS 서버로 해석되게 했습니다. 공용 도메인은 여전히 일반 리졸버 경로를 따르지만, *.home.arpa에 대한 질의는 모두 집의 AdGuard로 라우팅됩니다.
그래서 제 MacBook이 카페 네트워크에 있고 exit node가 활성화되어 있어도, 공용 DNS 체인에 그 이름들을 노출하지 않으면서 내부 서비스(nas.home.arpa, proxmox.home.arpa)에 이름으로 접근할 수 있습니다. split DNS 설정은 Tailscale 관리 콘솔의 DNS 설정 아래에 있으며, 해당 도메인 접미사에 대한 nameserver를 추가하고 그것을 AdGuard 인스턴스의 Tailscale IP로 지정하면 됩니다.
좋은 부수 효과도 있습니다. 이런 질의는 AdGuard를 거치므로 광고 차단과 추적 방지 적용도 받고, 제 AdGuard 질의 로그에도 다른 것들과 함께 나타납니다. DNS 가시성을 모두 한 곳에서 볼 수 있는 셈입니다.
저는 이 둘을 서로 다른 결과를 위해 사용합니다. 어디서든 “집 인터넷 위에 있는 것처럼” 되고 싶다면 exit node를 사용합니다. 반대로 일반 웹 브라우징은 로컬에 그대로 두고 사설 LAN 서비스에만 접근하고 싶다면 subnet router를 사용합니다.
한 문장으로 보는 차이
exit node는 “모든 인터넷 트래픽을 나를 통해 보내라”(0.0.0.0/0, ::/0)를 의미하고, subnet router는 “이 사설 네트워크들만 나를 통해 보내라”(예: 192.168.1.0/24)를 의미합니다.
한 대의 머신이 두 역할을 모두 할 수도 있지만, 저는 여전히 기기별로 full internet egress control이 필요한지, 아니면 단순히 private-network reachability만 필요한지를 선택합니다.
이것을 설정하고 경로를 추적해본 뒤, 제 머릿속 모델은 아주 단순해졌습니다. exit node는 인터넷 트래픽에 대해 Tailscale을 full-tunnel VPN처럼 동작하게 만들고, 제가 선택한 머신이 게이트웨이 역할을 합니다.
신뢰 측면의 절충도 마찬가지로 단순합니다. 저는 현재 접속 중인 네트워크를 더 이상 신뢰하지 않고, 대신 제가 통제하는 exit node를 신뢰하게 됩니다. 제 경우 그것은 집에 있는 작고 전용인 LXC이므로, 그 절충은 충분히 가치가 있습니다.
이제 제 sanity check는 세 가지 명령입니다. curl ifconfig.me, traceroute, 그리고 DNS 조회입니다. 이 셋이 모두 맞아떨어지면, 트래픽이 집을 통해 나가고 있고 설정이 의도대로 동작하고 있다는 것을 알 수 있습니다.
ip rule 매뉴얼 페이지« Prev Rust로 Traceroute를 다시 만들어봤는데 생각보다 훨씬 단순했다Next » 내가 마지막으로 읽고 있던 것은 무엇이었을까? 그리 쉽지 않은 세 편으로
최신 게시글과 인사이트를 받은편지함으로 받아보세요.
이름을 입력하세요 이메일을 입력하세요 Built using Picoletter.
© 2026 Stonecharioteer on Tech · Powered by Hugo&PaperMod