▲

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

 (github.com/juanfont)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Headscale은 Tailscale의 컨트롤 서버 기능을 자체 호스팅할 수 있도록 만든 오픈 소스 대안 프로젝트
  • Tailscale은 WireGuard 기반의 현대적 VPN 솔루션으로, NAT 환경에서도 작동하는 오버레이 네트워크 구성 가능
  • 원래의 Tailscale Control 서버는 비공개 소프트웨어이나, Headscale은 이를 대체할 수 있는 자유롭게 설치 가능한 서버 소프트웨어로 개발됨
  • Windows, macOS, iOS 클라이언트는 여전히 Tailscale의 GUI를 필요로 함

Headscale의 목적과 특징

  • Headscale은 개인 및 소규모 오픈소스 조직이 사용할 수 있도록 한 개의 tailnet(가상 사설망)만 지원
  • 자체 서버를 운영하고 싶은 사용자와 자유 소프트웨어 애호가에게 적합한 솔루션
  • 설계 범위를 좁게 설정하여 유지 보수와 관리가 간편함

주요 기능

  • 클라이언트 노드 간의 WireGuard 공개 키 교환
  • 각 노드의 IP 주소 할당 및 경계 설정
  • 사용자 간의 머신 공유 기능
  • 노드의 라우트 광고 관리
  • 공식 기능 목록은 여기에서 확인 가능

지원 클라이언트 운영 체제

  • Headscale과 호환 가능한 운영 체제 및 클라이언트 목록은 공식 문서에서 확인 가능

설치 및 실행 관련 안내

  • **역방향 프록시(reverse proxy)**나 컨테이너 기반 실행은 공식적으로 권장하지 않음
  • 실행 방법 및 설정은 공식 문서 참고

커뮤니티 및 기여

개발 환경 및 코드 스타일

  • 개발에 필요한 주요 도구:
    • 최신 버전의 Go
    • Buf (Protobuf 생성기)
    • Nix를 이용한 개발 환경 구성 가능 (nix develop 명령어)
  • 코드 스타일:
    • Go 코드: golangci-lint, golines, gofumpt 사용
    • Proto 코드: buf, clang-format 사용
    • 기타 파일: prettier로 정렬
  • 커밋 전에는 make lint, make fmt로 코드 정리 필수

빌드 및 테스트

  • Protobuf 코드 변경 시, Go 코드 재생성 필요: make generate
  • 테스트 실행: make test
  • 빌드:
    • nix build
    • 또는 make build 명령어 사용

기타 정보

  • 2023년 FOSDEM에서 Headscale 관련 발표 진행: 영상 보기
  • 프로젝트는 Tailscale Inc.와 직접적인 연관은 없으나, Tailscale 소속의 기여자가 참여 중이며 독립적으로 코드 리뷰 및 방향성 설정
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 몇 달마다 이 저장소를 다시 방문하여 Tailnet lock이 작동하는지 또는 보안 감사가 진행되었는지 확인함. 불행히도 둘 다 진전이 없어 이 시스템을 인프라의 핵심 부분으로 신뢰할 수 있을지 불확실해짐

    • Tailscale SaaS의 전체 전제는 방화벽 주위에 터널을 만들고 사용자가 이러한 터널을 통해 라우팅할 수 있는 것을 직관적이고 통합된 방식으로 관리할 수 있도록 하는 것임
    • Headscale은 방화벽을 우회하고 NAT-traversal을 수행하는 부분을 잘 해결한 것 같음. 그러나 그들이 우회한 것을 보완할 만큼 충분한 보안을 제공할 수 있는지, 아니면 단순히 로컬 네트워크 관리자를 방해하는 도구로 전락할 것인지 의문임
    • Tailscale 구현에 대해 사용자가 제어 서버가 클라이언트에게 지시하는 것을 이해하거나 거부할 수 있는 방법을 제공하지 않으면서 서버 코드를 전혀 감사하지 않는 것은 대담해 보임

  • 오케스트레이션 서버를 자체 호스팅하는 것에 관심이 있다면 Netbird를 살펴볼 수 있음. 이 도구는 매우 유사하지만 서버가 오픈 소스로 제공됨. 따라서 유료 버전의 모든 기능을 갖춘 자체 호스팅 제어 서버와 멋진 GUI를 가질 수 있음

  • Headscale이 인스턴스 간 피어링/연합을 허용하면 좋겠음 (ACL 재작업 후에라도). 주요 문제 중 하나는 주소 충돌임

    • 제안: 고유 로컬 주소(ULA) 범위에서 IPv6 전용 오버레이 네트워크에 전념하고, 나머지 121비트를 20비트는 장치 주소(~100만 개)로, 101비트는 서버의 공개 키 해시로 나누기. 다른 인스턴스의 공개 키를 추가하고 정책 및 ACL을 사용하여 노드 간 통신 관리하기
    • 이 아이디어는 좋다고 생각하지만, 2023년에 이 문제를 제기했을 때 유지보수자 kradalby는 범위를 벗어난다고 말했음 GitHub 이슈 링크

  • 프로젝트 이름, Headscale을 제목에 추가해야 함

    • Headscale은 HN에 여러 번 등장했음

  • Plan 9에서 실행되는지 궁금함

  • Headscale을 사랑함. 우리는 이를 프로덕션에 도입했고 아주 좋았음

  • Tailscale 조정 서버가 손상되고 tailnet lock이 활성화된 경우 내 장치가 손상될 위험이 얼마나 되는지 궁금함

  • 많은 사용 사례(모바일 액세스, macOS의 GUI)에서 공식 Tailscale 클라이언트가 제어 서버를 설정할 수 있는 능력에 의존함

    • Tailscale에서 불가피한 기능 축소가 시작되면 이 기능은 사라질 것임
    • 과거에 다른 회사들이 매각되거나 VC 자금이 고갈되어 여러 번 실망했지만 현재 매우 만족하는 Tailscale 고객으로서 이 말을 함

  • 이 설정이 wireguard + openwrt 설정에 비해 어떤 추가 가치를 제공하는지 궁금함

  • "Tailscale 구현에 대해 사용자가 제어 서버가 클라이언트에게 지시하는 것을 이해하거나 거부할 수 있는 방법을 제공하지 않으면서 서버 코드를 전혀 감사하지 않는 것은 대담해 보임"이라는 진술은 Headscale 제어 서버의 소스 코드를 공개하는 것만으로는 사용자가 "제어 서버가 클라이언트에게 지시하는 것을 이해하거나 거부할 수 있는" 충분한 조건이 되지 않음을 시사함

    • Headscale 제어 서버를 사용하는 경우 사용자는 "제어 서버가 클라이언트에게 지시하는 모든 것을 이해하거나 거부할 수 있음". 이는 소스 코드를 읽고, 편집하고, 컴파일함으로써 달성할 수 있음
    • Tailscale 제어 서버를 사용하는 경우 사용자는 Tailscale 회사가 허용하는 범위 내에서만 "제어 서버가 클라이언트에게 지시하는 것을 이해하거나 거부할 수 있음". 사용자는 소스 코드를 편집하거나 컴파일하는 것이 금지됨
    • 모든 사용자가 사용하는 타사 소프트웨어를 읽고, 편집하고, 컴파일할 옵션을 원하는 것은 아님. 일부 사용자는 실리콘 밸리 VC 자금으로 운영되는 회사의 지속적인 보증에 의존하는 것에 만족할 수 있음. 100% 오픈 소스 프로젝트를 원하는 사용자에게는 Headscale이 유용할 수 있음
    • Headscale의 작성자는 Tailscale 조정 서버를 "본질적으로 공개 키를 위한 공유 드롭박스"라고 부름
답변달기