일반적인 Tailscale Docker 앱은 편리하지만 컨테이너화된 VPN이 Linux 호스트에 직접 설치된 Tailscale처럼 항상 작동하는 것은 아닙니다. 원문 작성자는 실제 TUN 장치를 사용하는 일급 호스트 데몬을 원했으며, 이를 통해 ZimaOS 자체가 서브넷 라우터 또는 출구 노드로 작동하고 tailnet에서 접근 가능한 리소스를 마운트할 수 있게 했습니다.
ZimaOS에는 어플라이언스 스타일의 읽기 전용 루트와 일반적인 apt install tailscale 경로에 작성자는 Tailscale을 다음과 같이 패키징했습니다. systemd-sysext 확장 기능. 이는 IceWhale이 지원하는 Tailscale 패키지가 아닌 커뮤니티 프로젝트이므로 명령과 수명 주기를 그에 맞게 표시해야 합니다.
Tailscale을 호스트에서 실행하는 이유
원문 작성자는 Docker 사용자 공간 네트워킹이 일반적인 연결에는 충분하지만 호스트 수준 라우팅에는 불편하다고 설명했습니다. 네이티브 데몬은 커널 TUN 장치를 직접 사용하고 다음과 통합할 수 있습니다. systemctl, IP 포워딩, 서브넷 경로 및 출구 노드 동작.
systemd-sysext가 ZimaOS에 적합한 이유
systemd-sysext는 다음과 같은 위치에 파일을 추가로 오버레이합니다. /usr 실행 중에 불변 기본 이미지를 수정하지 않고. 작성자는 Tailscale의 업스트림 Buildroot 레이아웃을 따르고 지속적인 인증 상태를 다음 위치에 저장했습니다. /DATA/AppData/tailscale/.
프로젝트는 호스트 설치 스크립트를 제공합니다
커뮤니티 저장소의 빠른 시작 과정은 프로젝트를 클론하고 sudo로 설치 프로그램을 실행한 다음 다음으로 인증하는 방식입니다. tailscale up. 이는 root 권한으로 실행되는 서드파티 코드이므로 실행하기 전에 저장소와 릴리스 기록을 검토하세요.
오래된 포럼 버전을 복사하지 말고 현재 sysext 프로젝트와 유지 관리되는 설치 안내를 읽어 보세요.
인증 상태는 일회성 확장 기능 외부에 저장됩니다
프로젝트는 노드 상태를 다음 위치에 저장합니다. /DATA/AppData/tailscale/이를 통해 Tailscale ID가 다시 빌드하거나 교체해도 유지됩니다. .raw sysext 파일.
초기 릴리스 후 실제 재부팅 버그가 발견되었습니다
사용자가 다음과 같이 보고했습니다. tailscaled 재부팅 후 시작되지 않았습니다. 프로젝트 작성자는 이를 재현하고 다음과 같이 경쟁 상태를 설명했습니다. multi-user.target 이전에 서비스 종속성을 해결했습니다. systemd-sysext.service 확장 기능을 병합한 시점에 systemd가 대상을 구성했기 때문에 서비스 유닛이 존재하지 않았습니다.
v1.0.1 감시 타이머 추가
작성자는 지속형 루트에 저장된 작은 타이머와 oneshot 서비스를 사용해 부팅 경쟁 상태를 해결했습니다. /etc/systemd/system/부팅 직후 실행되어 다음을 시작합니다. tailscaled sysext 오버레이가 적용된 직후에.
원문 작성자는 실제 재부팅으로 수정 사항을 확인했다고 보고했습니다.
IP 포워딩 설정은 별도의 지속성 문제였습니다
스레드에서는 서브넷 라우터 sysctl 설정이 재시작 후에도 유지되는지도 질문했습니다. 작성자는 ZimaOS가 유지한다는 점을 설명했습니다. /etc 지속형 스토리지가 지원하는 오버레이를 통해 /etc 아래의 구성이 /etc/sysctl.d/ 유지되며 다시 적용됩니다.
이러한 전달 설정은 서브넷 라우터 또는 출구 노드로 사용할 때 필요하며, 일반적인 Tailscale 클라이언트에는 필요하지 않습니다.
ZimaOS 커널에 따라 IPv6 제한이 변경되었습니다
2026년 5월의 원래 모듈 문서에는 ZimaOS 1.6.1/커널 6.12.25에서 IPv6 정책 라우팅 커널 옵션이 누락되어 Tailscale이 터널링된 IPv6를 비활성화했다는 내용이 기록되어 있습니다.
7월 30일에 작성자는 IceWhale의 최신 커널이 필요한 IPv6 기능을 제공한다는 내용으로 스레드를 업데이트했습니다. 현재 프로젝트 저장소는 ZimaOS 1.7.0/커널 6.18.9에서 IPv6 tailnet 작동을 검증합니다.
ZimaOS 업데이트 후 설치 프로그램을 다시 실행하세요
이 프로젝트는 공식 Tailscale 정적 바이너리로 sysext를 다시 빌드하고 인증 상태는 별도로 보존하도록 설계되었습니다. 현재 저장소에서는 ZimaOS를 업그레이드한 후 설치 프로그램을 다시 실행할 것을 권장합니다.
루트 수준의 커뮤니티 모듈을 시스템 소프트웨어로 취급하세요
이 모듈은 NAS 호스트에서 직접 실행되며 설치 프로그램에는 높은 수준의 권한이 필요합니다. 중요한 데이터를 보관하는 시스템에 배포하기 전에 소스, 해시, 업데이트 동작 및 제거 동작을 검토하세요.
ZimaOS 1.7.0에서 프로젝트를 다시 검증했습니다
현재 저장소는 커널 6.18.9를 사용하는 ZimaOS 1.7.0에서 재부팅 후에도 설정이 유지되고 tailnet IPv6도 정상 작동하는 깔끔한 엔드투엔드 테스트 결과를 보고합니다. 이는 ZimaOS 1.6.1을 기준으로 개발된 2026년 5월의 원래 게시물보다 더 강력한 근거입니다.
Docker와 네이티브 sysext는 서로 다른 요구 사항을 해결합니다
Tailscale을 통해 선택한 애플리케이션에만 연결할 수 있으면 된다면 Docker 방식이 더 간단하고 호스트 수정도 최소화할 수 있습니다. 반면 ZimaOS 호스트 자체에서 tailnet 리소스를 마운트하거나 LAN 서브넷을 광고하거나 출구 노드로 작동해야 한다면 sysext 방식이 매력적입니다.
네이티브 방식이 존재한다는 이유만으로 정상 작동하는 Docker 설치를 교체하지 마세요. 실제로 호스트 수준 라우팅이 필요한지에 따라 선택하세요.
제거와 완전 삭제는 서로 다른 작업입니다
이 커뮤니티 프로젝트는 sysext 제거와 Tailscale 상태 삭제를 의도적으로 분리합니다. 일반 제거 경로에서는 영구 노드 데이터를 유지할 수 있지만, 완전 삭제를 수행하면 상태 디렉터리도 함께 제거됩니다. 다른 tailnet ID를 만들지 않고 재설치하려는 경우 이 차이가 중요합니다.
부팅 Watchdog은 여전히 설계의 일부입니다
현재 프로젝트 문서에 따르면 sysext 내부의 서비스 유닛이 systemd 대상의 초기 구성을 여전히 놓칠 수 있으므로 ZimaOS 1.7.0에서도 watchdog이 필요합니다. 최신 커널은 IPv6 기능을 수정했지만 sysext 서비스 순서 경쟁 상태까지 해결한 것은 아닙니다.
네이티브 Tailscale FAQ
이것은 IceWhale의 공식 Tailscale 패키지인가요?
아니요. 이것은 커뮤니티에서 만든 systemd-sysext 프로젝트입니다.
Docker 대신 이것을 사용하는 이유는 무엇인가요?
이 프로젝트는 호스트 수준의 TUN, 서브넷 라우터, 출구 노드 및 일반적인 systemd 통합을 대상으로 합니다.
재부팅 후 시작되지 않는 문제가 해결되었나요?
프로젝트 작성자가 이 문제를 재현했고 v1.0.1에서 watchdog 기반 수정 사항을 배포했습니다.
IPv6에 아직도 1.6.1의 제한이 있나요?
이 프로젝트에 따르면 ZimaOS 1.7.0에서 사용하는 최신 6.18.9 커널이 필요한 IPv6 정책 라우팅 지원을 제공합니다.
