한 ZimaOS 사용자는 앱 페이지에 “서비스를 사용할 수 없음”이 표시되고 휴대폰으로 홈 서버 서비스에 연결할 수 없었기 때문에 첫 실행 후 Tailscale에 문제가 발생했다고 생각했습니다. 하지만 컨테이너 진단 결과는 달랐습니다. Tailscale은 실행 중이었고, 장치는 인증되었으며, 상태 및 터널 마운트도 존재했습니다.
확인된 문제는 휴대폰에서 사용한 주소였습니다. 사용자는 서브넷 라우팅을 구성하지 않은 상태에서 일반적인 홈 LAN 주소로 연결하려고 했습니다. ZimaOS 장치의 Tailscale을 통해 서비스에 연결하면 100.x.x.x 주소가 작동했습니다.
Tailscale 컨테이너는 실패하지 않았습니다
초기 증상은 재시작 후 컨테이너가 중지된 것처럼 보였지만, 수집된 상태는 다음과 같았습니다.
- 컨테이너 상태는 종료 코드 0으로 실행 중이었습니다.
- Tailscale의 상태가 Starting에서 Running으로 진행되었습니다.
- 해당 장치는 사용자의 테일넷에서 인증되었습니다.
- 영구 상태 디렉터리도 컨테이너에 매핑되어 있었습니다.
- Tailscale에 필요한 TUN 장치도 매핑되어 있었습니다.
- 장치가 Tailscale IPv4 주소를 할당받았고 피어를 확인할 수 있었습니다.
이 증거를 통해 ZimaOS 앱 페이지 또는 웹 인터페이스의 메시지와 Tailscale 데몬 자체의 상태를 구분할 수 있었습니다.
첫 번째 진단 시도에서 권한 거부가 표시된 이유
터미널 세션은 일반 ZimaOS 사용자로 실행되었습니다. 처음 Docker 목록은 높은 권한으로 실행되었지만, 이후 명령은 권한 없이 Docker 소켓에 접근하려 했기 때문에 권한 오류가 반환되었습니다. 또한 포럼에서 복사한 곡선형 따옴표 때문에 일부 명령 치환이 올바르게 해석되지 않았습니다.
이러한 권한 메시지는 진단 세션에 관한 내용이지 Tailscale 런타임 오류가 아니었습니다. 적절한 권한으로 나중에 확인한 출력에서는 컨테이너가 정상 상태임이 나타났습니다.
홈 LAN 주소가 자동으로 Tailscale 주소가 되는 것은 아님
다음과 같은 주소는 10.0.0.93 이는 홈 LAN에 속합니다. 동일한 테일넷에 원격으로 연결된 휴대폰이 모든 사설 LAN 주소로 가는 경로를 자동으로 얻는 것은 아닙니다.
Tailscale은 각 노드에 고유한 주소를 할당하며, 일반적으로 100.x.x.x 범위에 해당합니다. Tailscale의 공식 IP 주소 문서에서는 이러한 주소가 테일넷 내부의 장치를 식별하며 일반적인 LAN 주소와는 별개로 유지된다고 설명합니다.
작동한 연결 방법
응답자는 사용자에게 ZimaOS 노드의 Tailscale IP와 애플리케이션 자체 포트를 사용해 애플리케이션에 연결하도록 안내했습니다.
http://TAILSCALE-IP:APP-PORT예를 들어 포트에서 실행 중인 서비스가 8096 다음과 같은 형식의 URL을 사용합니다.
http://100.x.x.x:8096휴대폰도 동일한 테일넷에 로그인되어 있고 Tailscale에 연결된 상태여야 합니다. 사용자는 이 주소가 작동한다고 확인했으며, 이를 통해 Tailscale 자체는 정상적으로 작동하고 있음이 확인되었습니다.
서브넷 라우팅이 필요한 경우
기존 LAN 주소를 통해 장치에 연결하려는 경우—예를 들면 10.0.0.x—해당 네트워크의 장치가 LAN 서브넷을 라우트로 광고해야 하며, tailnet 구성에 따라 해당 라우트를 승인해야 합니다.
이는 자체 Tailscale IP를 통해 ZimaOS 호스트에 직접 접근하는 것과는 다른 구성입니다. 일반적인 LAN 주소가 원격에서 작동할 것으로 기대하기 전에 Tailscale의 공식 서브넷 라우터 문서를 따르세요.
앱 페이지에 여전히 “서비스를 사용할 수 없음”이라고 표시될 수 있는 이유
웹 인터페이스의 가용성 확인은 네트워크 데몬이 실행 중이어도 실패할 수 있습니다. 원본 사례에서 결정적인 증거는 실행 중 상태, 성공적인 tailnet 인증, 할당된 Tailscale IP, 표시되는 피어, 그리고 작동하는 원격 서비스 연결이었습니다.
임의로 앱 포트를 변경하거나, Tailscale 상태를 삭제하거나, 컨테이너를 반복해서 재설치해도 잘못된 대상 주소 문제는 해결되지 않습니다. 작동 중인 ID를 초기화하기 전에 데몬 상태와 연결 방식을 확인하세요.
정상 작동하는 연결이 느리게 느껴질 수 있는 이유
최종 답변에서는 연결이 직접 피어 투 피어 경로가 아니라 DERP 릴레이를 사용하고 있을 수 있다고 설명했습니다. 릴레이된 Tailscale 트래픽은 정상적으로 작동하면서도 네트워크, 라우터 및 사용 가능한 릴레이 리전에 따라 처리량이 낮거나 지연 시간이 길 수 있습니다.
느리다는 사실만으로 컨테이너에 문제가 있다고 단정할 수는 없습니다. 먼저 연결이 작동하는지, Tailscale이 직접 경로 또는 릴레이 경로를 보고하는지 확인한 다음, 성능이 중요한 경우 NAT 및 방화벽 동작을 조사하세요.
더 안전한 진단 순서
- 앱 페이지 상태에만 의존하지 말고 Tailscale 컨테이너가 실행 중인지 확인하세요.
- ZimaOS 노드가 휴대폰과 동일한 tailnet에서 인증되고 온라인 상태로 표시되는지 확인하세요.
- ZimaOS 노드의 Tailscale
100.x.x.xTailscale 인터페이스 또는 관리자 콘솔을 통해 주소에 연결합니다. - 해당 Tailscale 주소와 서비스 포트를 사용하여 대상 서비스에 연결하세요.
- 일반적인 홈 LAN 주소를 통한 접근이 필요한 경우에만 서브넷 라우팅을 구성하세요.
- 연결은 되지만 느린 경우 DERP 릴레이 사용 여부를 별도로 조사하세요.
ZimaOS Tailscale 연결 FAQ
“서비스를 사용할 수 없음”이라는 메시지가 Tailscale이 중지되었다는 증거인가요?
아니요. 이 경우 앱 페이지에 해당 메시지가 표시되었더라도 컨테이너는 실행 중이었고, 인증되었으며, 연결되어 있었습니다.
Tailscale 앱 포트를 변경해도 도움이 되지 않은 이유는 무엇인가요?
문제는 일반적인 웹 앱 포트 충돌이 아니라 대상 주소였습니다. 사용자는 노드의 Tailscale IP가 필요했습니다.
원격 휴대폰은 어떤 주소를 사용해야 하나요?
ZimaOS 노드의 Tailscale 100.x.x.x 서브넷 라우터가 LAN 주소용으로 구성되지 않았다면, 주소와 애플리케이션 포트를 함께 사용해야 합니다.
10.0.0.x 주소가 Tailscale을 통해 작동하지 않는 이유는 무엇인가요?
이는 개인 홈 LAN 주소입니다. 해당 서브넷에 원격으로 접근하려면 서브넷 라우트를 광고하고 승인해야 합니다.
정상적으로 작동하는 Tailscale 연결이 느릴 수 있는 이유는 무엇인가요?
연결이 직접 피어 투 피어 경로 대신 DERP를 통해 릴레이될 수 있습니다.
