▲

Tailscale Peer Relays: 자체 장치를 고속 릴레이로 활용

 (tailscale.com)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • Tailscale Peer Relays가 정식 출시되어, 사용자가 자신의 장치를 고성능 릴레이 노드로 활용할 수 있게 됨
  • 방화벽, NAT, 클라우드 네트워크 제약 등으로 직접 연결이 어려운 환경에서도 안정적이고 빠른 트래픽 중계를 지원
  • 스루풋 향상과 락 경합 개선, UDP 소켓 분산 처리로 다수 클라이언트 연결 시 성능이 크게 개선됨
  • 정적 엔드포인트 통합을 통해 자동 탐색이 불가능한 클라우드 환경에서도 AWS NLB 등 뒤에서 릴레이 운영 가능
  • 가시성·모니터링 통합으로 트래픽 경로, 지연, 릴레이 상태를 명확히 파악할 수 있어 대규모 네트워크 운영에 중요함

Tailscale Peer Relays 개요

  • Peer Relays는 고성능 릴레이 기능을 자체 장치에서 실행할 수 있게 하는 기능
    • 기존 DERP 릴레이에 더해, 사용자가 직접 배포한 노드를 릴레이로 활용 가능
    • 베타 이후 성능, 안정성, 가시성이 크게 개선되어 프로덕션 수준으로 발전
  • 복잡한 NAT 환경을 우회하기 위한 기능에서 출발해, 대규모 네트워크 연결 옵션으로 확장됨
    • 팀 단위로 성능·제어·유연성을 확보할 수 있는 구조 제공

성능 및 신뢰성 개선

  • 다수의 클라이언트가 릴레이를 통해 연결될 때 스루풋이 크게 향상됨
    • 클라이언트는 릴레이 내에서 가장 적합한 인터페이스와 주소 패밀리를 자동 선택
    • 릴레이는 락 경합 감소와 멀티 UDP 소켓 분산 처리로 패킷 처리 효율 향상
  • 이러한 개선으로 일상적인 트래픽에서도 성능과 안정성이 향상되며, 직접 연결이 불가능한 경우에도 메시 네트워크에 가까운 성능을 제공

정적 엔드포인트 지원

  • 공용 클라우드 환경에서는 자동 엔드포인트 탐색이 어려운 경우가 많음
    • 방화벽 규칙, 포트 포워딩, 로드 밸런서 등으로 인해 임의 포트 개방이 불가능한 경우 존재
  • Peer Relays는 --relay-server-static-endpoints 플래그를 통해 고정 IP:포트 쌍을 광고할 수 있음
    • AWS Network Load Balancer 등 인프라 뒤에서도 외부 클라이언트가 릴레이를 통해 트래픽을 전달 가능
  • 이 기능으로 제한된 클라우드 환경에서도 고속 연결을 확보할 수 있으며, 서브넷 라우터를 대체해 풀 메시 구성이 가능

가시성 및 모니터링 통합

  • Peer Relays는 Tailscale의 관찰 도구와 직접 통합되어 릴레이 동작을 명확히 파악 가능
    • tailscale ping 명령으로 릴레이 사용 여부, 도달 가능성, 지연 및 신뢰성 영향 확인 가능
    • 문제 발생 시 트래픽이 릴레이를 거치는지, 릴레이 상태가 정상인지 즉시 판단 가능
  • 모니터링 지표로 tailscaled_peer_relay_forwarded_packets_total, tailscaled_peer_relay_forwarded_bytes_total을 제공
    • Prometheus, Grafana 등과 연동해 트래픽 패턴 분석, 이상 탐지, 네트워크 상태 모니터링 가능

일반 제공 및 배포 방식

  • 정식 출시된 Peer Relays는 Tailscale 확장성의 핵심 구성요소로 자리함
    • 직접 경로가 불가능할 때 고속·저지연 연결 제공
    • 정적 엔드포인트 기반 배포로 제한된 클라우드 환경에서도 동작
    • 사설 서브넷 내 풀 메시 구성과 입출구 제어 경로 설정 지원
  • 엔드 투 엔드 암호화, 최소 권한 접근, 예측 가능한 동작 등 Tailscale의 기본 보안 원칙 유지
  • CLI를 통해 모든 지원 노드에서 활성화 가능하며, ACL 기반 제어 및 점진적 배포 지원
  • Peer Relays는 모든 요금제(무료 Personal 플랜 포함) 에서 사용 가능
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • Tailscale이 “열려 있다(open)”는 이유로 신뢰받는다면, 동시에 일부 클라이언트가 폐쇄형이라는 점도 알아야 함
    공식 배포 채널(예: Apple App Store)을 통해서만 배포되고, 완전히 그들의 통제 아래 있음
    이런 입장을 정당화하는 논리가 황당한데, “사용자가 비공개 OS를 쓰는 게 괜찮다면 Tailscale도 비공개여도 괜찮다”는 식임
    이런 구조는 연결성 제한 환경에서는 신뢰하기 어려움
    기술적으로 경쟁사보다 낫더라도 결국 비즈니스일 뿐임. 가능하다면 자유 소프트웨어 대안을 지원해야 함
    관련 GitHub 이슈

    • 일부 플랫폼에서 GUI만 비공개임을 명확히 하고 싶음 (Tailscalar)
    • 나는 성능보다 통제권(control) 을 더 중요하게 여김
      사용자가 소스에서 직접 빌드할 수 있다면 성능 개선도 가능하지만, 통제권이 없으면 불만족스러운 부분을 고칠 방법이 없음
      상용 소프트웨어는 종종 품질이 낮고, 업데이트 의존적이며, 완성도보다 출시 속도를 우선시함
    • macOS용 CLI 클라이언트는 소스에서 직접 빌드 가능함
      go install tailscale.com/cmd/tailscale{,d}@latest 명령으로 설치할 수 있고, 공식 위키에 설명되어 있음
      GUI는 폐쇄형이지만 CLI는 완전 개방되어 있어 제한된 네트워크 환경에서도 사용 가능함
    • 대부분의 Mac 앱이 폐쇄형이라, Tailscale 메뉴바 아이콘 하나쯤은 신경 쓰이지 않음
      정말 불편하다면 brew나 CLI로 제어하면 됨
    • 오픈소스와 상용의 하이브리드 모델이 현실적인 절충안이라 생각함
      나도 비슷한 구조의 앱을 개발 중인데, CLI는 완전 오픈소스로 제공하고 GUI는 유료로 판매할 예정임
      이렇게 해서 개발을 지속하고 생계를 유지할 수 있음
      validate 라이브러리를 기반으로 GUI와 CLI를 함께 개발 중임

  • 최근 Tailscale을 설정했는데, 핑이 16ms에서 10ms로 감소하고 대역폭이 세 배로 늘어남
    Moonlight/Sunshine과 함께 사용하니 MacBook에서 Linux 데스크톱으로 Windows 게임을 50Mbps/10ms로 스트리밍 가능함
    포트 포워딩 없이 라우터를 피어 노드로만 설정했음

    • Sunshine 관련해서는 Apollo를 시도해볼 만함
    • 흥미로운 사용 사례지만, 사실상 NAT 트래버설과 포트 포워딩을 자동화된 프로토콜에 위임한 것임
    • 게임 스트리밍을 일반 사용자에게 공개하려면 상대방도 Tailscale을 설치해야 하는지 궁금함
      Tailscale은 기본적으로 신뢰할 수 있는 사용자 간 공유에 초점이 맞춰져 있는지 알고 싶음
    • OpenWRT 라우터로 비슷한 구성을 시도했는데, 여전히 포트를 열어야 하는 줄 알았음
      그렇다면 여전히 인터넷에 노출되는 것 아닌가 혼란스러움

  • Tailscale의 수익 모델이 궁금함. 서비스는 마음에 들지만 장기 지속 가능성이 걱정됨
    가끔 속도 제한(rate limit) 이 걸리는 느낌도 있음

    • 우리 회사는 월 18달러/사용자 요금의 비즈니스 플랜을 사용 중임
      팀 규모가 커지면 유료 플랜이 필수이고, serve/funnel, SSH 같은 기능이 유용함
      예전에는 Zerotier를 썼는데, 몇 년간 무료로 사용하다가 사용자 수가 늘면서 월 5달러 정도만 냈음
    • 원래 Tailscale은 초기 연결 후 P2P WireGuard 연결을 맺기 때문에 속도 제한이 없어야 함
      다만 네트워크 환경에 따라 중계(relay)가 필요할 수 있음
      오픈소스 대안으로는 Headscale과 Netbird가 있음
    • 공식 블로그의 무료 플랜 설명을 참고할 만함
    • 개발자 무료 플랜으로 인기를 얻고, 이후 기업이 유료 플랜으로 전환하는 프리미엄 모델의 전형적인 사례임
    • P2P 연결은 비용이 거의 들지 않기 때문에, 무료 티어로 개발자 충성도를 높이는 전략이 효과적임

  • Peer Relay로 전환된 것은 NAT 환경의 셀프호스터에게 큰 승리임
    직접 DERP 서버를 설정할 필요가 없어 UX가 개선됨

    • (Tailscale 직원 Alex) 우리도 같은 문제를 겪었음
      Peer Relay는 기존 subnet router와 exit node 인프라를 재활용해 구현 부담이 크지 않았음
      AWS 같은 제한적 NAT 환경에서도 안정적인 연결을 위해 필수적임
      결과적으로 지연 시간과 사용자 경험 모두 개선됨
    • 중앙 DERP가 트래픽을 블랙홀처럼 삼키는 문제가 있었는데, 최근에는 안정적임
      Peer Relay 도입으로 이런 문제 가능성이 더 줄어들 것 같음

  • Peer Relay가 UDP를 지원하는 점이 핵심임
    DERP는 TCP 기반이라 게임 스트리밍이나 음성 통신에서 지연(latency) 문제가 있었음
    Peer Relay는 UDP를 사용하므로 실시간 트래픽에 훨씬 적합함
    별도의 DERP 인스턴스를 설정하지 않아도 기존 서브넷 라우터에서 바로 활성화 가능함

    • 하지만 새 계정에서 긍정적인 댓글이 연속으로 달리고, 일부는 Tailscale 직원이 응답한 걸 보면 AI 기반 홍보(PR) 같아 보임
      이런 식의 AI 댓글은 커뮤니티 신뢰를 해치므로 자제해야 함

  • 여러 개의 Relay가 있을 때, Tailscale이 자동으로 가장 낮은 지연의 노드를 선택하는지 궁금함

  • 실제 CGNAT 환경에서 Tailscale이 큰 도움이 되었음
    Google Cloud Run에서 AI 비전 시스템을 돌리는데, ISP가 포트 포워딩을 막고 있었음
    Tailscale을 통해 Cloud Run 컨테이너와 카메라가 같은 LAN처럼 통신 가능해짐
    Peer Relay 덕분에 컨테이너가 자주 재시작될 때 생기던 지연 문제도 줄어들 것으로 기대됨
    다만, 에페메럴(임시) 노드 환경에서 Relay 선택이 어떻게 동작하는지 궁금함

  • 나는 기존에 직접 구성한 WireGuard 네트워크를 쓰고 있는데, Tailscale이 내부적으로 뭘 하는지 궁금함
    DNS, 라우팅, 방화벽 등을 자동으로 조정하는 “매직” 기능이 많아 불안함
    공식 문서를 봤지만 세부 내용이 부족함
    복잡한 네트워크 설정에서도 잘 작동하는지 알고 싶음

    • (Tailscale 직원) 완벽한 문서를 유지하기 어렵지만, 가능한 한 환경 적응형 휴리스틱을 문서화하려고 함
      Linux에서는 다양한 설정 패턴이 존재해 복잡함
      관련 블로그 글에서도 설명함
      주요 동작은 다음과 같음
      • 규칙 기반 라우팅으로 충돌 방지
      • systemd-resolved를 우선 통합, 없으면 /etc/resolv.conf 수정
      • iptables와 nftables 모두 지원하며, ufw/firewalld와 호환되도록 구성
      • SSH 로그인은 배포판별 차이를 고려해 최대한 호환성 있게 구현
      • 안정적 통신을 위해 1360바이트 MTU 경로 필요
        매우 커스텀한 환경에서는 문제가 생길 수도 있지만, 지원을 통해 해결 가능함
    • 클라이언트는 오픈소스이며, 일부 직원이 Headscale 같은 리버스엔지니어링 서버에도 기여함
    • Headscale은 오픈소스 대안으로 참고할 만함

  • 모바일에서 페이지를 열었는데 닫기 버튼이 보이지 않아 모달을 닫을 수 없었음
    스크린샷 참고
    나중에 찾긴 했지만 위치가 이상했음

    • 모달 오른쪽 아래 파란 상자 안의 흰색 X 버튼이 닫기 버튼임
답변달기