▲

Tailscale Peer Relays: 안전하고 유연한 네트워크를 위한 고속 릴레이

 (tailscale.com)
3P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • Tailscale Peer Relays는 기존 DERP 서버를 대체하는 새로운 트래픽 릴레이 기능으로, 사용자가 직접 배포하고 관리할 수 있는 구조
  • 각 노드는 UDP 포트 하나만 열면 릴레이 역할을 수행할 수 있으며, Tailscale 클라이언트에 내장되어 간단히 활성화 가능
  • 고속·고처리량 연결을 지원해, 클라우드 NAT나 방화벽 뒤에서도 직접 연결에 가까운 성능 확보
  • 모든 트래픽은 WireGuard® 기반 종단 간 암호화를 유지하며, DERP 및 커스텀 DERP로의 자동 폴백(fallback) 지원
  • 현재 공개 베타로 제공되며, 모든 요금제에서 최대 2개의 무료 Peer Relay 사용 가능

Tailscale Peer Relays 개요

  • Tailscale Peer Relays는 Tailscale의 관리형 DERP 서버를 대체할 수 있는 사용자 관리형 트래픽 릴레이 메커니즘
    • 어떤 Tailscale 노드든 릴레이로 설정 가능하며, 동일한 tailnet 내 노드 간 트래픽을 중계
    • 릴레이는 자신이 속한 tailnet의 노드만 중계 가능
  • 고객이 직접 관리하므로 DERP보다 처리량 제약이 적고, 폐쇄형 클라우드 인프라나 방화벽 환경에서도 높은 성능 제공
  • 초기 파트너 테스트에서 직접 연결에 근접한 처리량을 기록, 기존 DERP 대비 수십 배 이상 빠른 성능 확인

Hard NAT 환경 극복

  • Tailscale은 NAT 환경에서도 가능한 한 직접 연결(90% 이상) 을 유지하도록 개선된 NAT 트래버설 기술을 적용
  • 그러나 일부 클라우드 환경에서는 직접 연결이 불가능하거나 비효율적일 수 있음
  • 기존 DERP는 안정적 연결을 제공하지만, QoS 제약과 성능 한계로 인해 일부 배포 환경에서 어려움 존재
  • Peer Relays는 성능 중심의 연결 도구로 설계되어, UDP 기반 저지연 통신과 클라이언트 내장형 구조로 배포 용이
  • 고객이 직접 릴레이를 배치해 고성능·고유연성 네트워크 구성 가능

작동 방식

  • Peer Relay는 양쪽 노드가 접근 가능한 단일 UDP 포트를 사용
  • CLI 명령어 tailscale set --relay-server-port로 간단히 활성화 가능
  • 직접 연결이 불가능할 경우, Peer Relay → DERP(관리형 또는 커스텀) 순으로 자동 폴백
  • 모든 연결은 WireGuard® 암호화로 보호
  • 방화벽 예외를 최소화하면서 tailnet 내부 트래픽만 허용하도록 설정 가능
  • 지역 간 확장성, 네트워크 장애 내성, DERP 자동 폴백 기능을 모두 지원

다양한 활용 시나리오

  • 클라우드 NAT 환경(AWS Managed NAT Gateway 등) 에서 직접 연결 불가 트래픽을 고속 중계
  • 엄격한 방화벽 환경에서 단일 UDP 포트만 개방해 승인 절차 단축
  • DERP 네트워크 부하 감소 및 커스텀 DERP 유지보수 불필요
  • 폐쇄형 고객 네트워크 접근 시 예측 가능한 엔드포인트를 통해 최소 포트만 개방
  • 실제 고객들은 Peer Relay를 활용해 비관리 네트워크 접근, 파트너 연결 경로 제어, VPC 피어링 기반 세분화된 네트워크 구성 등을 구현

공개 베타 및 제공 정책

  • Tailscale Peer Relays는 공개 베타 버전으로 즉시 사용 가능
  • 현재 일부 가시성 및 디버깅 개선 작업이 진행 중
  • 초기 파트너들은 손쉬운 배포와 안정적 성능을 확인
  • 모든 요금제(무료 포함)에서 최대 2개의 Peer Relay 무료 제공, 추가 릴레이는 확장 가능
  • 추가 릴레이 필요 시 Tailscale 영업팀 문의를 통해 확장 가능
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 이번 기능이 정말 합리적이라 생각함
    직접 연결이 불가능할 때만 중간 노드를 사용하는 구조로, 트래픽은 종단 간 암호화됨
    직접 derp 서버를 운영하는 것과 비슷하지만 포트를 열 필요가 없고, Tailscale의 릴레이 사용량을 줄여 대역폭 비용도 절감됨
    다만 두 개 이상의 릴레이를 쓰면 왜 유료인지 궁금함

    • 대부분의 경우 인터넷에 포트를 열어야 함
      그렇지 않다면 애초에 tailscale이 필요 없을 수도 있음
      예외적으로 두 클라이언트가 릴레이에는 접근 가능하지만 서로 직접 연결은 안 되는 경우가 있음

  • 예전 tinc가 이미 이런 문제를 해결했음
    모든 노드가 릴레이 역할을 할 수 있고, 중앙 서버 없이 진짜 메시 네트워크로 동작함
    굳이 새로 구현하기보다 wireguard 기반으로 메모리 안전 언어로 포팅하는 게 낫다고 봄

    • 나도 30개 노드의 Tinc 네트워크를 운영 중인데, NAT 뒤에 있는 호스트들이 자주 경로를 잃음
      SSH 연결 직후 경로가 끊기는 경우도 많음
      릴레이 노드에서 트래픽이 복호화·재암호화되는 구조라 종단 간 암호화를 위해선 실험적 프로토콜을 써야 함
      cjdns 프로토콜 기반으로 다시 써보고 싶지만 쉽지 않음
    • Wireguard로도 같은 기능을 구현할 수 있음

  • Tailscale의 새 Peer Relay 기능이 ZeroTier가 예전에 하던 것과 비슷해 보임
    “Tailscale만의 독자 기능”이라 주장하기엔 무리이고, 사용자당 요금 외에 추가 과금은 과하다고 느낌

    • 예전에 ZeroTier를 써봤지만 이런 기능은 없었음
      대신 자체 암호화 방식, 단일 스레드 성능 저하, 느린 개발 속도가 문제였음
      여러 대안을 써봤지만 Tailscale만큼 기능과 성능을 모두 갖춘 건 아직 없음
      “FTP 있는데 왜 Dropbox 쓰냐”는 식의 비교처럼 느껴짐

  • 외부 IPv4/IPv6 주소를 직접 지정할 수 있는지 궁금함
    송신과 수신 트래픽이 다른 주소를 쓰거나, 여러 인터넷 연결 주소 중 일부만 방화벽이 허용된 경우가 있기 때문임

  • 지난주에 headscale과 split horizon SSL을 설정했는데, 결국 DERP만 가능하다는 걸 알게 됨
    로컬 네트워크에서 UDP 포트를 직접 노출하는 게 더 낫다고 생각함
    Wireguard 클라이언트의 보안이 충분히 검증됐다면 그게 더 편함

    • “DERP만 가능하다”는 게 무슨 뜻인지 궁금함
      직접 Wireguard 포트를 열려고 한 건지, 아니면 Tailscale 포트를 말하는 건지 묻고 싶음

  • DERP 대신 이 기능을 쓰면 브라우저에서는 동작하지 않음
    네이티브 UDP 기반이라서임
    나중에 WebTransport로 구현할 수 있을지 궁금함

    • (Tailscalar) 나도 WebTransport에 기대가 큼
      하지만 NAT 트래버설 문제는 해결하지 못함
      Iroh의 QAD 진행 상황도 주의 깊게 보고 있음
      다 잘 맞아떨어지면 훨씬 매직 같은 네트워크가 될 것 같음

  • 다음 단계로 모든 tailscale 클라이언트가 자동으로 포워딩 요청을 받아서 메시 네트워크가 끊김 없이 자가 복구되면 어떨까 생각함

    • 홉이 늘어나면 지연이 커지므로, 차라리 요청이 실패해서 문제를 명확히 드러내는 게 낫다고 봄
    • 이런 확장은 오버레이 네트워크에서 자주 논의됨
      다만 다른 사람의 트래픽 중계를 허용할지 여부가 핵심임

  • Tailscale로 서비스 간 연결이 가능하지만, 만약 Tailscale 장애가 나면 내 서비스끼리도 통신이 끊기는지 궁금함

    • 실제로 로그인 서버 장애가 있었을 때 로컬 네트워크까지 모두 끊김
      tailscale에 접속할 수 없어 재연결도 불가능했음
      그래서 이제 headscale을 직접 구축하려고 함
      로컬 LAN 장치끼리도 통신이 안 되는 건 좀 어이없었음

  • 주말 내내 Kubernetes Operator용으로 임시 솔루션을 만들었는데, 이제 이 기능 덕분에 다 걷어낼 수 있게 됨
    정말 브라보임

    • K8s는 내 악몽임 ㅋㅋ 완전 공감함

  • 이 기능의 사용 사례가 궁금했음
    SaaS 제품이 고객 시스템의 데이터를 필요로 할 때, 고객 쪽에서 데이터를 릴레이로 노출해 통합하는 용도 같음
    그래도 인증·로깅 등을 위한 소프트웨어는 필요할 듯함

    • 이건 tailscale이 운영하는 DERP 서버의 대안임
      NAT 우회가 안 되는 경우가 많아 DERP가 자주 쓰이는데, 속도가 느림
      이제는 네트워크 내에서 연결이 좋은 피어를 릴레이로 지정해 더 빠르게 쓸 수 있음
      새로운 사용 사례라기보다 기존 DERP의 성능 개선판임
    • Tailscale은 기본적으로 보안 VPN 플랫폼임
      전통적인 허브-스포크 구조 대신, 가능한 한 모든 노드가 직접 UDP/IP로 연결되는 P2P 구조를 지향함
      하지만 NAT와 방화벽 때문에 직접 연결이 안 되는 경우가 많아 DERP가 이를 중계함
      DERP는 느리고 사용자가 성능을 개선할 방법이 없었는데, 이번 Peer Relay로 직접 릴레이를 운영할 수 있게 됨
      위치를 잘 잡으면 지연도 줄일 수 있음
      물론 모든 사용자에게 필요한 기능은 아님
답변달기