Tailscale 컨테이너는 서브넷 라우터로 기능하지 않으면서도 연결된 것으로 표시될 수 있습니다. 2026년 4월의 이 ZimaOS 스레드에서는 Tailscale이 Docker에서 호스트 네트워킹, 권한 모드 및 다음 설정으로 실행되고 있었습니다. /dev/net/tun 마운트되어 있었지만 Tailscale 관리자 콘솔에는 해당 머신이 경로를 노출하지 않는다고 표시되었습니다. Navidrome은 로컬 네트워크에서는 작동했지만 tailnet을 통해 원격으로 접근할 수 없었습니다.
이 스레드는 원 게시자가 수정이 완료되었다고 확인하지 않은 채 끝났습니다. 대신 다른 커뮤니티 회원이 자신의 ZimaOS 환경에서 LAN 서브넷을 성공적으로 광고한 작동하는 BigBear Tailscale 컨테이너 구성을 공유했습니다. 이 구성은 문제 해결 참고 자료로 유용하지만 모든 Tailscale 앱 패키지에 대해 IceWhale이 지원을 보장하는 것은 아닙니다.
Tailscale에 연결되었다고 해서 서브넷 경로가 광고되는 것은 아닙니다
원래 설정에서는 이미 장치 인증이 완료되어 있었습니다. 문제는 구체적으로 라우팅이었습니다. 로그에는 빈 경로 목록이 표시되었고 Tailscale 관리자 콘솔에는 승인할 서브넷 경로가 나타나지 않았습니다.
이 차이는 중요합니다. 일반 Tailscale 노드는 tailnet에 참여하기만 합니다. 서브넷 라우터에는 하나 이상의 LAN 접두사를 광고하고 tailnet과 해당 LAN 간의 트래픽을 전달하는 데 필요한 운영 체제 라우팅 요구 사항을 충족해야 하는 추가 책임이 있습니다.
현재 Tailscale 문서에서는 서브넷 라우터를 tailnet 장치에 사설 네트워크를 광고하는 게이트웨이로 설명합니다. 또한 Linux에서 IP 전달을 활성화해야 하며, 정책이 자동으로 승인을 처리하지 않는 한 Tailscale 관리자 콘솔에서 경로를 승인해야 합니다. 자동 승인자 정책이 승인을 자동으로 처리합니다.
작동하는 커뮤니티 참고 구성은 TS_ROUTES를 사용했습니다
TomasSzwed의 답변은 BigBear Tailscale 컨테이너를 사용하고, 시작 후 수동으로 한 번 실행하는 명령에 의존하는 대신 환경 변수를 통해 서브넷을 구성했습니다. 해당 참고 구성의 중요한 부분은 다음과 같습니다.
-
network_mode: host; - 권한 모드;
-
/dev/net/tun컨테이너에 마운트됨; -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24광고할 LAN의 경우; -
TS_EXTRA_ARGS=--accept-routes해당 사용자의 구성에서; - 에 있는 영구 Tailscale 상태
/var/lib/tailscale.
네트워크에 맞는 올바른 LAN 접두사 사용
작동하는 예시에서 광고한 값은 192.168.2.0/24해당 값은 해당 서브넷을 사용하는 LAN에서만 의미가 있습니다. 다른 홈 네트워크에서는 다음을 사용할 수 있습니다. 192.168.1.0/24, 10.0.0.0/24또는 다른 사설 접두사를 사용하세요.
잘못된 서브넷을 광고하면 Tailscale 노드는 정상 상태이지만 의도한 ZimaOS 서비스로 라우팅하지 못할 수 있습니다. 설정하기 전에 실제 로컬 네트워크 접두사를 확인하세요. TS_ROUTES 또는 이에 상응하는 --advertise-routes 옵션입니다.
광고된 경로는 여전히 활성화되어야 합니다
현재 Tailscale 지침에서는 경로 광고와 경로 승인을 별도로 다룹니다. 서브넷 라우터가 경로를 광고하면 tailnet 정책에서 자동으로 승인하지 않는 한 Tailscale 관리 콘솔에서 해당 경로를 활성화해야 합니다.
관리 콘솔에 해당 머신이 노출하는 경로가 전혀 없다고 표시되면 먼저 컨테이너의 경로 광고 구성을 확인하세요. 경로가 표시되지만 트래픽이 여전히 작동하지 않으면 경로 승인, 접근 제어 정책, 포워딩, 대상 서비스 자체를 검토하세요.
Docker 네트워킹에 따라 컨테이너가 라우팅할 수 있는 대상이 달라집니다
원 게시자는 호스트 네트워킹을 사용하고 TUN 장치를 마운트했습니다. 커뮤니티 참고 구성도 동일했습니다. 현재 Tailscale 문서 역시 Docker에서 Tailscale 실행을 지원하지만, Docker 네트워킹과 Tailscale 라우팅은 서로 다른 계층이므로 둘 다 올바르게 구성해야 합니다.
ZimaOS 앱 스토어의 Tailscale 앱 두 개가 동일한 컨테이너 정의를 사용한다고 가정하지 마세요. 원 게시자는 공유된 예제가 BigBear Tailscale 패키지를 사용하는 반면 기존 설치에는 다른 Tailscale 항목이 사용된다는 점을 특히 알아차렸습니다.
Navidrome 및 기타 로컬 서비스에 미치는 영향
원본 스레드의 목표는 공용 포트 포워딩 없이 iPhone에서 Navidrome에 접속하는 것이었습니다. Navidrome이 이미 로컬 LAN에서 연결 가능한 상태라면, 작동하는 서브넷 라우터를 통해 권한이 있는 tailnet 장치에서 해당 LAN 주소에 접속할 수 있습니다.
하지만 해당 스레드에서는 원 게시자가 BigBear 구성으로 전환을 완료했거나 이후 Navidrome에 성공적으로 접속했는지 확인되지 않습니다. 따라서 이 페이지는 정확히 해당 설치에서 해결이 확인된 사례가 아니라, 활용 가능한 커뮤니티 참고 자료와 진단 모델을 문서화합니다.
ZimaOS Tailscale 서브넷 라우팅 FAQ
Tailscale이 연결됨으로 표시되지만 서브넷 경로가 없는 이유는 무엇인가요?
tailnet에 참여하는 것과 LAN 경로를 광고하는 것은 서로 다른 작업입니다. 원본 사례에서는 인증에는 성공했지만 경로 목록은 비어 있었습니다.
ZimaOS에서 Docker의 Tailscale이 서브넷 라우터 역할을 할 수 있나요?
한 커뮤니티 구성원이 ZimaOS 설정에서 작동했다고 보고하며 BigBear Tailscale 구성을 공유했습니다. Tailscale 자체도 서브넷 라우팅과 Docker 배포를 지원하지만, 정확한 ZimaOS 앱 구성도 여전히 중요합니다.
Tailscale에서 경로를 승인해야 하나요?
현재 Tailscale 동작 방식에서는 광고된 서브넷 경로를 일반적으로 관리 콘솔에서 승인해야 합니다. 단, 자동 승인자 정책이 자동으로 처리합니다.
스크린샷의 192.168.2.0/24를 복사해야 하나요?
아니요. 노출하려는 LAN의 실제 서브넷을 사용하세요. 스크린샷의 값은 다른 커뮤니티 구성원의 네트워크에 해당합니다.
