Tailscale Exit Node: full-tunnel VPN을 대체하는 구성 검토

작성일: 2026년 4월 21일
카테고리: Networking, Tailscale, VPN
키워드: Tailscale, Exit Node, WireGuard, Route Injection, Userspace Netstack

요약

원격 네트워크 경유가 필요할 때 WireGuard/OpenVPN 서버를 별도로 구축하는 대신, 기존에 운영 중이던 Tailscale 환경에서 exit node 기능으로 동일한 효과를 얻을 수 있다. 핵심 동작은 (1) 컨트롤 플레인이 클라이언트에 주입하는 route injection으로 default route를 재작성하는 것과, (2) exit node 쪽 패킷 중계를 Linux kernel mode 또는 userspace netstack 두 가지 방식으로 처리하는 것이다. 플랫폼별 중계 모드는 성능·방화벽 통합·감사 로깅 측면에서 의미 있는 운영 차이를 만든다.

대안 비교

원격지 노드를 경유해 인터넷에 나가는 full-tunnel 경로가 필요한 상황에서 실무적으로 선택지는 네 가지다.

선택지	범위	비용
SSH/RDP 원격 접속	원격 호스트 내부 작업만	로컬 도구·파일 활용 불가
ssh -D SOCKS 프록시	애플리케이션 단위	앱별 프록시 설정, 미지원 도구 누락
WireGuard/OpenVPN 자체 구축	OS 전체	서버·NAT traversal·키/인증서 수명주기
Tailscale exit node	OS 전체	tailscaled 설치 노드에서 플래그 2개

Tailscale이 이미 운영 중이라면 네 번째가 가장 가성비가 높다.

# 원격 노드에서 광고
$ sudo tailscale up --advertise-exit-node

# 클라이언트에서 선택 (로컬 LAN은 예외 허용)
$ tailscale up --exit-node=<노드명> --exit-node-allow-lan-access

관리자는 Admin Console에서 해당 노드의 Use as exit node를 승인해야 한다. 승인 자동화는 tailnet policy(auto-approvers)로 지정할 수 있다.

동작 요약: Route Injection

Tailscale은 WireGuard 기반 L3 오버레이다. 평소에는 100.64.0.0/10 대역 트래픽만 터널로 흐르는 split tunnel 구조인데, exit node가 지정되면 클라이언트 OS의 default route (0.0.0.0/0, ::/0) 가 터널을 향하도록 바뀐다.

flowchart LR
    A[클라이언트] -->|default route| B[WireGuard 터널]
    B --> C[Exit Node]
    C --> D[인터넷]

    style A stroke:#2563eb,stroke-width:2px
    style B stroke:#16a34a,stroke-width:2px
    style C stroke:#dc2626,stroke-width:3px

이 재작성은 Tailscale의 route injection 프로토콜로 이뤄진다. 컨트롤 플레인이 tailnet policy에 따라 경로 맵을 내려보내고, tailscaled 데몬이 OS 라우팅 테이블에 반영한다. 사용자가 수동으로 라우트를 건드리지 않아도 default route가 바뀌는 이유다.

Exit Node의 중계 모드 — 운영 관점의 진짜 차이

Tailscale은 플랫폼에 따라 패킷 중계를 두 가지 방식으로 구현한다. 이 차이는 성능, 방화벽 통합, 감사 로깅 정책에 영향을 준다.

Kernel mode — root 권한 Linux

flowchart LR
    A[Tailscale 인터페이스] --> B[Linux netfilter]
    B --> C[ip_forward / NAT]
    C --> D[외부 NIC]

    style A stroke:#16a34a,stroke-width:2px
    style B stroke:#2563eb,stroke-width:2px
    style C stroke:#ea580c,stroke-width:2px

• net.ipv4.ip_forward=1 필요
• 커널이 직접 포워딩 → 오버헤드 최소
• iptables/nftables, conntrack, tc, eBPF 등 기존 리눅스 네트워크 툴과 그대로 결합 가능
• 원 클라이언트 IP가 커널 레벨 방화벽에 노출되므로 플로우 기반 감사·차단 정책 적용이 용이

Userspace netstack — Windows, macOS, non-root Linux

flowchart LR
    A[Tailscale 인터페이스] --> B[tailscaled]
    B --> C[userspace netstack]
    C --> D[OS 소켓 신규 outbound]

    style A stroke:#16a34a,stroke-width:2px
    style B stroke:#dc2626,stroke-width:3px
    style C stroke:#ea580c,stroke-width:2px

• Tailscale이 userspace TCP/IP 스택을 운용 — 자체 구현이 아니라 Google gVisor의 netstack 패키지(Go 기반)
• 터널로 들어온 패킷을 netstack이 종단하고, 내용만 꺼내 OS 소켓 API로 새 outbound 연결을 맺음
• 커널 포워딩이 불가능한 OS(Windows/macOS)나 권한(non-root)에서도 동작
• 트레이드오프
  • 커널-유저 경계 오가는 오버헤드 → kernel mode 대비 throughput 낮음, 고대역 요구 환경 비권장
  • 외부에서 볼 때 플로우가 "exit node 로컬에서 시작된 연결"로 보임 → 커널 레벨 방화벽/IDS에서 원 클라이언트 IP가 보이지 않음. 감사 요건이 있다면 tailscaled 로그 수집을 별도로 구성해야 함
  • 기존 iptables 기반 QoS/레이트 리밋 룰이 그대로 적용되지 않을 수 있음

즉 같은 "exit node" 기능이지만, Linux root에서는 전통적 라우터처럼, 그 외에서는 NAT된 애플리케이션 레벨 게이트웨이처럼 동작한다. 엔터프라이즈에서 exit node를 상시 운영할 계획이면 Linux kernel mode 권장.

운영·보안 체크포인트

인증/권한

• tailnet policy (ACL)는 컨트롤 플레인 JSON으로 정의 — exit node 사용 대상도 사용자/그룹 단위로 제어 가능
• 디바이스 인증은 SSO 연동 (OIDC/Okta/Google Workspace 등)
• exit node 승인 자동화: autoApprovers.exitNode

컨트롤 플레인 의존성

• Tailscale SaaS: 컨트롤 플레인 가용성 = 디바이스 인증/정책 가용성. 기존 데이터 플레인(P2P 터널) 세션은 장애 중에도 유지되지만 신규 접속·경로 변경은 차단
• 규제·격리 요건이 있다면 Headscale(오픈소스 컨트롤 플레인) 자체 호스팅 검토

감사/로그

• tailscaled 자체 로그 + 컨트롤 플레인의 감사 로그(Enterprise)
• kernel mode exit node는 netflow/sflow·conntrack 수집으로 원 소스 추적 가능
• userspace netstack 환경은 원 클라이언트 IP 추적 난이도가 올라가므로, 감사 요건이 있는 트래픽은 Linux 호스트를 exit node로 지정

성능

• 터널 자체 처리량은 WireGuard 성능에 수렴 (Linux kernel WireGuard는 일반적으로 수 Gbps급)
• Userspace netstack은 고대역에서 CPU bound가 되기 쉬움 — 벤치마크 후 도입
• P2P 연결이 NAT/방화벽으로 막히면 DERP relay 경유로 폴백 → 지연·대역폭 저하. tailscale netcheck로 경로 확인

블라스트 레이디어스

• default route 재작성은 전방위적 → --exit-node-allow-lan-access 없이는 현재 LAN의 프린터/NAS/공유기 UI 모두 차단됨
• MagicDNS / split DNS 설정이 exit node의 DNS 정책으로 덮이는지 확인 필요

정리

• 기존 Tailscale 환경이 있다면 별도 VPN 서버 구축 없이 exit node 플래그 두 줄로 full-tunnel 경로 구성 가능
• 플랫폼별 중계 모드(kernel vs userspace)가 성능·방화벽 통합·감사 로깅 특성을 결정 — 장기 운영이면 kernel mode Linux 권장
• "설정의 단순함"과 "엔터프라이즈 운영 준비도"는 별개. ACL, 컨트롤 플레인 가용성, 감사 정책, DNS/LAN 정책은 여전히 직접 설계 필요

참고 자료

• Tailscale: How it works
• Route injection · Tailscale Docs
• Exit nodes (route all traffic) · Tailscale Docs
• Kernel vs. netstack subnet routing & exit nodes · Tailscale Docs
• Headscale