영구 Tailscale 컨테이너는 ZimaOS 재부팅이나 애플리케이션 수정 후에도 Tailscale 관리 콘솔에서 동일한 시스템으로 유지되어야 합니다. 2025년 9월 원문 스레드에서는 Compose 파일에 이미 다음 항목이 마운트되어 있었음에도 이런 일이 발생하지 않았습니다. /var/lib/tailscale 영구적인 ZimaOS AppData로.
최종 원문 결과는 원인을 좁혀 주므로 중요합니다. 원글 작성자는 영구 저장소가 이미 올바르게 설정되어 있었고, 계속 제공되던 인증 키 환경 변수를 삭제하는 것만으로 문제가 해결되었다고 말했습니다. 이후 Tailscale 노드 식별 정보가 유지되었습니다.
Tailscale에는 영구적인 시스템 상태가 필요합니다.
Tailscale은 상태 디렉터리에 시스템 식별 정보, 키 및 연결 상태를 저장합니다. Docker에서는 일반적으로 다음과 같이 경로를 구성합니다.
와 함께해당 디렉터리가 일회성 컨테이너 파일 시스템 내부에만 존재하면 컨테이너를 다시 만들 때 새로운 Tailscale 식별 정보가 생성됩니다.
상태 디렉터리
원본에는 이미 상태 디렉터리가 마운트되어 있었습니다.
원본 Compose 파일에는 다음이 포함되어 있었습니다./DATA/AppData/tailscale:/var/lib/tailscale 와 함께TS_STATE_DIR=/var/lib/tailscale 호스트 네트워킹,, NET_ADMIN및 NET_RAW에 대한 액세스, /dev/net/tun. 이론적으로는 상태를 보존해야 합니다.
인증 키는 등록용이지, 반드시 모든 재시작에 필요한 것은 아닙니다.
Compose 파일에는 다음 항목도 제공되어 있었습니다. TS_AUTHKEY 모든 컨테이너 시작 시. 한 커뮤니티 답변자는 기존 노드 상태가 예상대로 재사용되지 않으면 재인증으로 인해 새 시스템이 생성될 수 있다고 설명했습니다.
답변자는 첫 시작 시 재사용 가능한 비임시 인증 키를 사용하고, 관리 콘솔에 노드가 표시될 때까지 기다린 다음, 인증 키 줄을 삭제하고 다시 배포하라고 제안했습니다. 그러면 저장된 시스템 상태가 식별 정보의 원본으로 사용됩니다.
원글 작성자는 인증 키를 제거하자 문제가 해결되었다고 확인했습니다.
최종 원문 답변에 따르면 다른 영구 저장 설정은 이미 적용되어 있었고, 삭제해야 했던 것은 인증 키 환경 변수뿐이었습니다. 이후 시스템 이름이 재시작 후에도 유지되었습니다.
이 확인은 권한에 대한 일반적인 추측보다 더 확실합니다. 이 특정 설치에서는 반복 인증이 실제 원인이었습니다.
현재 Tailscale은 TS_AUTH_ONCE를 제공합니다.
최신 Tailscale Docker 배포에서는 다음을 사용할 수 있습니다. TS_AUTH_ONCE=true. 영구 상태가 이미 존재할 때 컨테이너가 시작할 때마다 다시 로그인하도록 강제하지 않게 합니다.
2025년 Compose 파일을 그대로 재사용하기 전에 현재 Tailscale Docker 상태 및 인증 매개변수를 검토하세요.
상태 저장에 전용 호스트 폴더 사용
Tailscale AppData/상태 폴더와 같은 전용 호스트 디렉터리를 사용하면 재배포 후에도 머신 키가 유지되는지 확인하기가 더 쉽습니다. 원문 답변자는 상태를 저장하는 프로세스가 해당 폴더에 쓸 수 있는지도 확인하라고 권장했습니다.
볼륨이 올바르게 마운트되어 있어도 프로세스가 파일을 업데이트하지 못할 수 있으므로 권한이 중요합니다. 이런 상황에서 Tailscale은 재사용 가능한 상태가 없는 것처럼 동작할 수 있습니다.
영구 서버에는 임시 인증 키를 사용하지 마세요
Tailscale은 의도적으로 임시로 사용하는 ephemeral 노드를 지원합니다. 이는 수명이 짧은 CI 작업이나 일회성 컨테이너에 유용하지만, 영구적인 ZimaOS 서버에는 적합하지 않습니다.
자격 증명을 생성할 때 의도한 수명 주기에 맞는지 확인하세요. 영구 홈 서버는 일반적으로 의도적으로 취소하거나 교체할 때까지 동일한 ID를 유지해야 합니다.
TS_HOSTNAME은 머신 ID를 정의하지 않습니다
원문 컨테이너는 다음을 사용했습니다. TS_HOSTNAME=zimaos. 이 설정은 tailnet에 표시되는 알기 쉬운 이름을 제어하지만, 동일한 호스트 이름 문자열을 유지한다고 해서 암호화된 머신 ID가 유지되는 것은 아닙니다. 새로 인증된 두 머신은 서로 다른 노드인 상태에서도 비슷한 이름을 사용하려고 할 수 있습니다.
재부팅과 앱 재배포 모두 테스트
원래 문제는 전체 OS 재부팅과 ZimaOS 앱 편집 후 모두 발생했습니다. 따라서 올바른 해결 방법은 다음 두 경우를 모두 견뎌야 합니다.
- Tailscale 컨테이너를 다시 시작하세요.
- 상태 볼륨을 변경하지 않은 채 앱을 편집하고 다시 배포하며;
- ZimaOS를 재부팅하고;
- Tailscale 관리 콘솔에서 동일한 머신이 계속 온라인 상태인지 확인하세요.
이러한 이벤트 중 하나만 발생한 후 중복 항목이 나타난다면, 해당 수명 주기 작업 중 상태 디렉터리에 어떤 변화가 발생하는지 비교하세요.
영구 Tailscale FAQ
재부팅할 때마다 새로운 Tailscale 머신이 생성된 이유는 무엇인가요?
원문 사례에서는 상태 볼륨이 이미 존재했고, 인증 키를 반복해서 사용하는 것이 남은 실질적인 문제였습니다.
어떤 경로를 유지해야 하나요?
로 구성된 경로 TS_STATE_DIR일반적으로 /var/lib/tailscale 컨테이너 내부에.
TS_AUTHKEY를 환경 변수에 영구적으로 유지해야 하나요?
반드시 그런 것은 아닙니다. 원문 작성자는 등록 후 이 값을 제거하여 중복 노드를 해결했으며, 현재 Tailscale에서도 TS_AUTH_ONCE.
TS_HOSTNAME이 노드 ID를 유지하나요?
아니요. ID를 유지하는 것은 저장된 Tailscale 머신 상태입니다.
