Headscale - Tailscale 컨트롤 서버의 셀프 호스팅 구현 오픈소스

 (github.com/juanfont)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Headscale는 Tailscale 컨트롤 서버를 오픈소스·셀프 호스팅으로 구현한 프로젝트이며, self-hoster와 취미 개발자의 프로젝트·랩 환경을 목표로 함
  • Tailscale은 WireGuard 기반 현대적 VPN이며, NAT traversal을 사용해 네트워크의 컴퓨터 사이에 오버레이 네트워크처럼 동작함
  • Tailscale의 컨트롤 서버는 노드의 WireGuard 공개키 교환, 클라이언트 IP 할당, 사용자 경계 생성, 사용자 간 머신 공유, 노드가 광고한 라우트 노출을 담당함
  • Headscale은 개인 사용이나 소규모 오픈소스 조직에 적합한 단일 Tailscale 네트워크(tailnet) 구현을 좁은 범위로 제공함
  • 프로젝트는 Tailscale Inc.와 관련이 없으며, Headscale 실행에는 리버스 프록시와 컨테이너 사용을 지원하거나 권장하지 않음

Headscale의 목적과 범위

  • Headscale는 Tailscale 컨트롤 서버의 셀프 호스팅 가능한 오픈소스 대안을 목표로 함
  • 대상 사용자는 self-hoster, 취미 개발자, 개인 프로젝트와 랩 환경 사용자임
  • 구현 범위는 좁게 잡혀 있으며, 단일 tailnet을 제공함
    • 개인 사용에 적합함
    • 소규모 오픈소스 조직에도 적합함

Tailscale과 컨트롤 서버의 역할

  • Tailscale은 WireGuard 위에 구축된 현대적 VPN임
  • Tailscale은 네트워크의 컴퓨터 사이에서 오버레이 네트워크처럼 동작하며, NAT traversal을 사용함
  • Tailscale에서 GUI 클라이언트 일부와 컨트롤 서버를 제외한 모든 요소는 오픈소스임
    • 예외로 언급된 GUI 클라이언트는 Windows와 macOS/iOS 같은 독점 OS용 클라이언트임
  • 컨트롤 서버는 Tailscale 네트워크 노드 간 WireGuard 공개키 교환 지점으로 동작함
    • 클라이언트 IP 주소를 할당함
    • 사용자 간 경계를 생성함
    • 사용자 간 머신 공유를 가능하게 함
    • 노드가 광고한 라우트를 노출함
  • Tailscale network, 즉 tailnet은 Tailscale이 개인 사용자나 조직에 할당하는 사설 네트워크임

문서와 버전 주의사항

실행과 빌드

  • Headscale 실행에는 리버스 프록시와 컨테이너 사용을 지원하거나 권장하지 않음
  • 실행 방법은 공식 문서를 보도록 안내함
  • NixOS 사용자를 위한 모듈은 nix/ 디렉터리에 있음
  • main 브랜치의 개발 빌드는 컨테이너 이미지와 바이너리로 제공됨

프로젝트 관계와 기여

  • 이 프로젝트는 Tailscale Inc.와 관련이 없음
  • Headscale의 활성 메인테이너 중 한 명은 Tailscale에 고용되어 있으며, 근무 시간에 프로젝트에 기여할 수 있음
    • 해당 메인테이너의 기여는 다른 메인테이너가 리뷰함
  • 메인테이너들은 self-hoster, 열성 사용자, 취미 개발자 커뮤니티를 지원하면서 지속 가능한 프로젝트를 만드는 원칙 아래 프로젝트 방향을 함께 정함
  • 기여자는 CONTRIBUTING.md를 읽어야 함

개발 환경과 워크플로

  • 기여에는 최신 Go와 Buf가 필요함
    • Buf는 Protobuf 생성기로 사용됨
  • 개발 환경 설정에는 Nix 사용을 권장함
    • nix develop을 실행하면 필요한 도구를 설치하고 셸을 제공함
    • 이 방식은 Headscale 메인테이너와 동일한 개발 환경을 보장함
  • Go 코드는 golangci-lint로 린트하고, golines, gofumpt로 포맷함
    • golines 폭은 88로 설정됨
    • 커밋 전 make lint와 make fmt 실행을 권장함
  • Proto 코드는 buf로 린트하고 clang-format으로 포맷함
  • 문서는 mdformat, Markdown·YAML 등 나머지 파일은 prettier로 포맷함
  • proto/ 변경 시 Protobuf에서 Go 코드 생성을 다시 해야 함
    • 명령어는 make generate
    • gen/ 변경사항은 리뷰를 쉽게 하기 위해 별도 커밋으로 넣도록 권장함
  • 테스트와 빌드는 각각 make test, make build로 실행함
  • 권장 워크플로는 nix develop 이후 make test, make build를 실행하는 방식임
    • 직접 의존성을 관리하는 경우 Make를 바로 사용할 수 있음
    • Makefile은 필요한 도구가 없으면 경고하고 nix develop 실행을 제안함
    • 사용 가능한 대상은 make help로 확인함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 몇 달마다 이 저장소에 돌아와 Tailnet lock이 드디어 동작하는지, 그 사이 누군가 보안 감사를 했는지 확인하게 됨
    아쉽게도 둘 다 진전이 없어 보이고, 그래서 이걸 내 인프라의 핵심 구성요소로 얼마나 신뢰할 수 있을지 점점 불확실해짐
    Tailscale SaaS의 전제는 방화벽을 우회하는 터널을 만들고, 그 터널을 통해 무엇을 라우팅할지 사용자가 직관적이고 통합된 방식으로 통제하게 해주는 것임
    Headscale은 방화벽 우회와 고급 NAT 통과는 잘 해낸 듯하지만, 방금 우회한 보안을 보완할 만큼 자체 보안을 제공할 수 있는지는 의문임
    제어 서버가 클라이언트에게 무엇을 하라고 지시하는지 사용자가 이해하거나 거부할 방법이 없고, 서버 코드 보안 감사도 전혀 없다면 꽤 대담한 선택처럼 보임

    • Tailnet lock은 Headscale에서는 Tailscale보다 훨씬 덜 중요해 보임. Headscale 인프라를 직접 통제하기 때문임
    • Headscale이 정말 그 기능들을 직접 구현한 건지 궁금함
      나는 이게 Tailscale의 기본 백엔드 서비스 위에 얹힌 제어 계층이라고 생각했는데, 새로운 방식으로 연결을 중개하는 건가?
      ZeroTier는 꽤 자주 쓰지만 Tailscale에는 익숙하지 않아서 뻔한 질문일 수 있음
    • 유지보수자 중 한 명이 지금은 Tailscale에서 일함
    • 관련해서 https://github.com/juanfont/headscale/issues/2416를 참고하면 됨

  • 자체 호스팅 오케스트레이션 서버에 관심 있으면 Netbird도 볼 만함
    비슷한 도구인데 서버도 오픈소스로 공개되어 있고, 자체 호스팅 제어 서버에 괜찮은 GUI와 유료 버전의 기능들이 함께 제공됨
    https://netbird.io/knowledge-hub/tailscale-vs-netbird

    • Headscale과 비교하면 Netbird는 움직이는 부품이 정말 많음
      튼튼하고 강력하고 기능도 많아 보이지만, Headscale 자체 호스팅은 훨씬 단순하고 요구사항도 적음
    • Tailscale에서 Netbird로 천천히 옮기는 중인데, Tailscale이 전체 CGNAT 경로를 가져가는 장난 같은 동작을 빼면 아주 잘 작동함
      지금은 Tailscale도 계속 돌리고 있지만, 점점 폐기하고 Netbird로 완전히 전환하는 쪽에 가까워지고 있음
    • Netbird를 쓰고 싶지만, Tailscale의 tsnet처럼 Go 바이너리에 임베드할 수 있는 기능이 아직 없음
      관련 GitHub 이슈는 여기 있음
      https://github.com/netbirdio/netbird/issues/1103
    • IPv6가 없어서 정말 치명적인 단점임: https://github.com/netbirdio/netbird/issues/46
    • Netbird도 Tailscale처럼 정교한 NAT 통과를 해주는지 궁금함

  • 제목에 프로젝트 이름인 Headscale을 넣는 게 좋겠음
    Headscale은 HN에 여러 번 올라왔던 프로젝트임

  • Headscale이 인스턴스 간 피어링/연합을 지원하면 멋질 것 같음. ACL 재작업 이후가 될 수도 있음
    주요 문제 중 하나는 주소 충돌임
    제안은 이렇다: 고유 로컬 주소(ULA) 범위의 IPv6 전용 오버레이 네트워크로 정하고, 남은 121비트를 장치 주소용 하위 20비트(약 100만 개)와 서버 공개키 해시인 상위 101비트로 나눔
    다른 인스턴스의 공개키를 추가해 연합하고, 정책과 ACL로 노드 간 통신을 관리하면 됨
    좋은 아이디어라고 생각하지만, 2023년에 꺼냈을 때 유지보수자 kradalby는 범위 밖이라고 했음: https://github.com/juanfont/headscale/issues/1370

  • Headscale을 반년 동안 잘 쓰고 있음
    아주 좋아서, 예전에 Tailscale 네트워크 없이 어떻게 살았는지 모르겠을 정도임
    OpenBSD에 패키징되어 있고, 나는 그 패키지를 서버로 쓰는 중임

  • Headscale을 좋아하고, 방금 프로덕션에 올렸는데 아주 잘 돌아감

    • Headscale을 2.5년 동안 운영해 왔고 꽤 괜찮았음
      로그인에는 Gmail 도메인을 쓰는데, 사용자가 자기 장치를 직접 등록할 수 있다는 큰 장점이 있음
      예전 OpenVPN에서는 운영팀이 인증서와 설정을 직접 전달해야 했음
      유일한 단점은 사용자가 실수로 자체 서버가 아니라 Tailscale 로그인 서버에 연결한 뒤 왜 서비스에 접근이 안 되는지 헤매는 경우임
      사용자 그룹으로 접근 가능한 서비스를 설정하고 있음
      아직 구버전 Headscale을 쓰는 중인데, 새 제어 평면으로 포팅해야 할 연동들이 있기 때문임
      headscale node list | wc 기준으로 노드는 약 250개이고, 대부분은 서버임
      Tailscale이 라우팅 테이블과 방화벽 규칙에 마법처럼 손대는 건 별로 마음에 들지 않지만, 대체로 문제는 아니었고 꽤 잘 작동했음
    • 회사 전체용 내부 서비스로 배포했다는 뜻인지 궁금함

  • 여러 사용 사례, 예를 들어 모바일 접근이나 macOS GUI에서는 공식 Tailscale 클라이언트가 제어 서버를 설정할 수 있는 기능을 유지해줘야 Headscale을 쓸 수 있음
    Tailscale에서 필연적인 품질 저하가 시작되는 순간 이 기능은 사라질 것임
    지금은 Tailscale에 매우 만족하는 고객이지만, 과거에 다른 회사들이 매각되거나 벤처 자금이 떨어지면서 여러 번 당해본 입장에서 하는 말임

    • 비오픈소스 운영체제의 GUI 부분을 제외하면 대부분의 Tailscale 클라이언트는 오픈소스 아닌가?
    • 기억이 맞다면 Tailscale이 어딘가에서 Headscale이 오히려 매출에 긍정적이라고 말했던 것 같음
      그럴 법함. Headscale은 주로 홈랩 사용자와 작은 취미 사용자들이 쓰고, Pulsesecure, Cisco Anyconnect, GlobalProtect가 아니라 자체 호스팅 OpenVPN이나 WireGuard와 경쟁함
      여가 시간에 새 기술을 좋아하지만 인프라 통제권은 포기하고 싶지 않은 사람들에게 Tailscale을 소개하는 경로임
      그런 사람들이 직장으로 Tailscale 전문성과 열정을 가져가게 됨
      회사는 IT 인프라 관리가 핵심 역량이 아닌 이상 별로 하고 싶어 하지 않음
      물론 일부 회사는 Tailscale 본제품 대신 Headscale을 고르겠지만, 회사 규모와 금액을 고려하면 소수일 가능성이 큼
      그건 매출 비용에 가깝고, Facebook 광고나 실리콘밸리 도로변 광고판과 크게 다르지 않음
    • Tailscale에서 가장 불만인 부분은 클라이언트, 특히 모바일 클라이언트의 배터리 사용량임
      직장에서 Tailscale을 못 쓰는 이유는 우리가 통제할 수 없는 서버를 통해 트래픽이 라우팅되기 때문임
      직장에서 Tailscale을 정말 쓰고 싶고, 많은 문제를 해결해줄 것임
      포트를 열어야 한다면 감수할 수 있지만, 그 포트를 통해 트래픽을 터널링하는 건 매우 걱정됨

  • 흥미로워 보임. WireGuard + OpenWrt 구성보다 어떤 부가가치가 있는지 궁금함

    • 장치들이 수동 설정 없이, 복잡한 NAT 뒤에 있어도 서로 피어 투 피어로 연결됨
      중앙에서 관리하는 ACL의 제약을 받으며 그냥 동작함
      Tailscale을 “그냥 WireGuard 오케스트레이터”라고 깎아보는 경우가 있지만, 실제로는 그보다 훨씬 많음
      제품 관점에서는 WireGuard가 구현 세부사항일 뿐임
    • 메시 VPN이라 피어들이 직접 통신하므로 추가 지연이 없음
      나는 예전에 Headscale UI가 너무 기본적이라고 느껴서 Netbird를 골랐는데, 몇 년 사이 개선됐을 수도 있음
    • Tailscale의 가치 제안은 어느 정도 기술에 익숙한 사람도 혼자 설정하고 관리할 수 있는 WireGuard임
      수많은 클라이언트에서 동작하고, 내 Apple TV들도 Tailscale 네트워크에 연결되어 있음
      설정에 1분 정도 걸렸고 게이트웨이 역할도 할 수 있음
    • 고정 IP가 없거나 집 네트워크에서 무언가가 리스닝하는 걸 원치 않는 사람들도 있음
      Tailscale이나 외부에 호스팅한 Headscale이면 그렇게 쓸 수 있음

  • Tailscale 조정 서버가 침해됐고 Tailnet lock이 켜져 있다면, 내 장치들이 침해될 위험은 어느 정도인지 궁금함

답변달기