Tailscale이란 무엇이며 어떻게 작동하나요?

Tailscale이란 무엇인가?

Tailscale은 사용자가 운영하는 단일 게이트웨이로 모든 트래픽을 라우팅하는 대신, 기기들을 서로 직접 연결하는 VPN입니다. 모든 노드는 WireGuard를 실행하므로 패킷은 한 서버에서 다른 서버로 암호화되어 전송되며, 경로상에 있는 그 어떤 것도 패킷을 읽을 수 없습니다. 호스팅된 조정 서버(coordination server)가 연결을 중재합니다. 이 서버는 공개 키를 저장 및 배포하고 각 노드에 다른 노드의 위치를 알려줍니다. 또한 사용자가 작성한 접근 규칙을 각 노드로 전달합니다.

이러한 분리 구조가 전체 설계의 핵심입니다. 데이터 평면(data plane)은 피어 투 피어(peer to peer) 방식이며 노드 간에 암호화됩니다. 제어 평면(control plane)은 Tailscale이 사용자를 대신해 운영하는 서비스입니다. 신뢰 문제와 같은 불편한 질문을 포함하여 Tailscale에 관한 모든 중요한 의문은 이 두 가지 사실에서 비롯됩니다. 만약 이미 VPS에 직접 WireGuard VPN을 구축해 본 경험이 있다면, Tailscale은 키 배포와 방화벽 통과 과정을 대신 처리해 주는 동일한 터널이라고 이해하면 됩니다.

Tailscale은 어떻게 작동합니까?

사용자의 노드로 구성된 사설 네트워크를 tailnet이라고 부릅니다. 기기가 tailnet에 합류하면 다음 네 가지 과정이 일어납니다.

1. tailscaled 데몬이 시작되고 WireGuard 키 쌍을 생성하며, 상태를 /var/lib/tailscale/tailscaled.state에 저장합니다. 개인 키는 해당 기기를 벗어나지 않습니다. Tailscale은 "개인 키는 절대로 노드를 떠나지 않는다"고 명확히 밝히고 있습니다.
2. 노드는 조정 서버(coordination server)에 로그인하여 공개 키와 자신이 도달 가능하다고 판단하는 주소를 업로드합니다. Tailscale은 이 서버를 "공개 키를 위한 공유 드롭박스"라고 설명합니다.
3. 조정 서버는 네트워크 맵을 반환합니다. 여기에는 해당 노드가 통신할 수 있는 모든 노드의 공개 키, tailnet 주소, 기기 이름, 후보 엔드포인트 정보가 포함됩니다.
4. 각 노드 쌍은 서로 직접적인 WireGuard 터널을 구축하려고 시도합니다. 연결에 실패하면 패킷을 릴레이 서버를 통해 전달합니다.

각 노드는 100.64.0.0/10 범위에서 고정 주소를 할당받습니다. 이는 100.64.0.0에서 100.127.255.255까지 이어지는 캐리어급 NAT 대역입니다. Tailscale이 이 대역을 사용하는 이유는 서비스 제공자 인프라용으로 예약되어 있어, 사용자의 서버가 이미 사용 중인 사설 IP 대역과 충돌할 가능성이 낮기 때문입니다. Linux에서 이 터널은 tailscale0라는 이름의 인터페이스로 나타납니다.

WireGuard 구현은 커널 모듈이 아닌 사용자 공간의 tailscaled 내에서 실행됩니다. 이것이 바로 sudo modprobe wireguard이 Operation not supported 오류로 실패하는 컨테이너 가상화 환경에서도 Tailscale이 시작될 수 있는 이유입니다. 또한 이는 특정 장비에서의 처리량 상한선이 커널 기반 WireGuard보다 낮다는 것을 의미하며, 이는 Tailscale과 일반 WireGuard 비교에서 다루는 트레이드오프 중 하나입니다.

현재 상태를 확인하는 두 가지 명령어가 있습니다.

tailscale ip -4
tailscale status

tailscale status는 노드당 한 줄씩 출력하며, 마지막 열이 가장 중요합니다.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct 뒤에 주소와 포트가 표시된다면 두 기기가 서로 경로를 찾았으며 트래픽이 피어 투 피어로 전달되고 있음을 의미합니다. relay "fra"은 프랑크푸르트에 있는 Tailscale 릴레이를 거치고 있다는 뜻입니다. -는 현재 해당 노드와 활성화된 세션이 없음을 의미하며, 이는 정상적인 상태입니다.

코디네이션 서버가 볼 수 있는 정보와 볼 수 없는 정보

코디네이션 서버는 공개 키와 메타데이터를 보유합니다. 서버는 사용자의 머신 이름, 각 노드를 소유한 사용자나 태그, 각 노드의 tailnet 주소, 노드에 접근 가능한 공인 주소, 마지막으로 온라인 상태였던 시점, 그리고 사용자가 작성한 정책 파일을 알고 있습니다. 이는 전체 장비 구성에 대한 완전한 지도와 같습니다.

서버는 개인 키를 보유하지 않으므로 두 노드 간의 트래픽을 복호화할 수 없습니다. 암호화는 WireGuard 피어 간의 종단 간(end-to-end) 방식으로 이루어지며, 코디네이션 서버는 피어에 포함되지 않습니다.

서버가 할 수 있는 일은 키를 전달하는 것입니다. 호스팅 방식이든 직접 운영하는 방식이든, 모든 코디네이션 서버는 어떤 공개 키가 tailnet에 속하는지 노드에 알려주는 역할을 신뢰받습니다. 이는 아래에서 다룰 위협 모델의 핵심이며, 직접 호스팅할 수 있는 오픈 소스 코디네이션 서버인 Headscale이 존재하는 이유이기도 합니다.

서로 다른 방화벽 뒤에 있는 두 서버가 직접 통신하는 방법

NAT(network address translation)는 여러 대의 기기가 하나의 공인 IP 주소를 공유할 수 있게 해줍니다. 일반적으로 VPS는 고유한 공인 IP 주소를 가지고 있지만, tailnet에 포함하려는 다른 기기들(가정용 서버, 사무실 네트워크의 빌드 러너, 설정을 변경할 수 없는 제공자 방화벽 뒤의 장비 등)은 그렇지 않은 경우가 많습니다.

Tailscale은 STUN(session traversal utilities for NAT) 및 ICE 표준을 기반으로 구축된 기술을 사용하여 경로를 찾습니다. 각 노드는 STUN 서버로 작은 UDP 패킷을 전송하여 해당 소켓에 라우터가 할당한 공인 IP 주소와 포트를 확인합니다. 두 노드는 이러한 후보 정보를 조정 서버(coordination server)에 보고하고, 서버는 이를 상대방에게 전달합니다. 그 후 두 노드는 동시에 서로에게 패킷을 보내기 시작합니다. 각 라우터는 아웃바운드 패킷을 먼저 확인하므로 매핑을 생성하고, 동일한 주소에서 도착하는 응답을 허용합니다. 따라서 양쪽 모두 인바운드 방화벽 규칙을 설정할 필요가 없습니다.

포트는 고정되어 있습니다. 직접적인 WireGuard 터널은 기본적으로 41641번 소스 포트를 사용하는 UDP를 사용합니다. STUN은 Tailscale의 릴레이 서버를 대상으로 UDP 3478번 포트를 통해 실행됩니다. 제어 연결 및 모든 릴레이 데이터는 TCP 443번 포트에서 HTTPS를 사용합니다. 대부분의 경우 인바운드 포트를 열 필요는 없지만, NAT 환경이 까다로운 네트워크에서는 UDP 41641번 포트를 인바운드로 허용하면 직접 연결될 확률이 높아집니다.

tailscale netcheck

해당 보고서의 두 줄을 확인하십시오. UDP: true은 UDP가 기기에서 정상적으로 나가는지 여부를 의미하며, UDP: false는 이 노드에서 발생하는 모든 연결이 릴레이됨을 의미합니다. MappingVariesByDestIP: true는 라우터가 목적지마다 서로 다른 공인 포트를 할당한다는 뜻이며, 이 경우 위에서 설명한 주소 예측이 작동하지 않아 해당 노드들은 일반적으로 릴레이 상태로 유지됩니다.

Tailscale이 DERP 릴레이를 사용하는 경우

DERP(designated encrypted relay for packets)는 폴백(fallback) 메커니즘입니다. Tailscale은 여러 지역에서 릴레이를 운영하며, 이들은 TCP 443 포트를 통해 접근할 수 있습니다. 직접적인 경로를 찾지 못한 노드는 WireGuard 패킷을 이 릴레이 중 하나를 통해 전송합니다.

패킷은 암호화된 상태로 유지됩니다. Tailscale은 이를 명확히 밝히고 있습니다. "DERP 서버가 사용자의 트래픽을 복호화할 방법은 없습니다. 서버는 이미 암호화된 트래픽을 한 노드에서 다른 노드로 단순히 전달할 뿐입니다." 릴레이는 암호문과 어떤 노드가 서로 통신하는지만 확인할 수 있습니다.

릴레이는 대부분의 연결에서 초기 패킷을 처리하기도 합니다. 직접적인 경로를 찾는 데는 시간이 걸리므로, 세션은 대개 릴레이를 통해 시작된 뒤 두 노드가 서로를 발견하면 직접 연결로 전환됩니다. 이 과정을 직접 확인할 수 있습니다.

tailscale ping db-1

첫 번째 응답은 via DERP(fra)으로 돌아오며, 이후 줄에서 via 198.51.100.24:41641과 같은 메시지가 나타납니다. 이 변화는 직접 터널로의 업그레이드를 의미합니다. 만약 이 상태가 변하지 않는다면 양쪽 끝에서 tailscale netcheck을 실행하십시오. 릴레이 경로를 통해서도 통신은 정상적으로 작동합니다. 다만 모든 패킷이 제3의 장비를 거쳐 우회하므로 지연 시간이 발생합니다.

VPS를 tailnet에 연결하기

설치 스크립트는 Ubuntu와 Debian을 지원합니다.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up 명령은 URL을 출력합니다. 해당 URL을 열어 인증하면 관리 콘솔에 노드가 나타납니다. 그 후 재부팅 시 데몬이 정상적으로 다시 시작되는지 확인하십시오. 많은 사용자가 이 단계를 간과합니다.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled 명령은 enabled을 출력해야 하며, tailscale status 명령은 100.x 주소를 가진 새 노드를 목록에 표시해야 합니다. 스크립트로 구축한 서버의 경우 대화형 URL은 사용할 수 없습니다. 관리 콘솔에서 인증 키(auth key)를 생성하고, 해당 머신의 종류를 기록하는 태그와 함께 전달하십시오.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

태그가 지정된 노드는 명령을 실행한 개인이 아닌 태그가 소유하므로, 해당 사용자의 계정이 삭제되어도 계속 작동합니다. 태그는 먼저 정책 파일의 tagOwners 항목에 선언되어 있어야 하며, 그렇지 않으면 명령이 거부됩니다. 태그 지정은 머신이 요금제에 계산되는 방식에도 영향을 줍니다. 태그가 지정된 리소스는 개인 기기와 별도로 가격이 책정되며, 무료 티어의 실제 적용 범위에서 해당 제한 사항을 확인할 수 있습니다.

플릿(fleet) 운영 시 두 가지 설정이 중요합니다. 노드 키는 기본적으로 180일 후에 만료됩니다(2026년 8월 기준). 키가 만료되면 누군가 다시 로그인할 때까지 "해당 엔드포인트와의 연결이 중단"되므로, 무인 서버의 경우 관리 콘솔에서 해당 머신 행을 열어 Disable Key Expiry를 선택하십시오. 2022년 10월 20일 이후 생성된 tailnet에서 기본적으로 활성화되는 MagicDNS는 각 노드에 db-1.yak-bebop.ts.net와 같은 이름을 부여하며, 이는 100.100.100.100의 stub resolver를 통해 해석됩니다. 노드를 재구축하면 주소는 바뀌지만 이름은 유지되므로, IP 주소 대신 이름을 사용하는 것이 좋습니다.

apt 또는 저장소 문제로 설치 자체가 실패하는 경우, Ubuntu에서의 일반적인 Tailscale 설치 오류에서 해결 방법을 확인할 수 있습니다.

localhost에 바인딩된 서비스에 접근하기

이 지점에서 tailnet이 유용하게 사용되지만, 많은 사용자가 여기서 어려움을 겪습니다. tailnet에 가입한다고 해서 loopback 서비스에 바로 접근할 수 있는 것은 아닙니다.

ss -tlnp | grep 3000

만약 해당 명령이 127.0.0.1:3000을 출력한다면, 소켓은 목적지가 127.0.0.1인 패킷만 수락합니다. 다른 노드에서 보낸 요청은 이 노드의 100.x 주소로 전달되는데, 커널은 해당 주소에서 수신 대기 중인 프로세스가 없으므로 TCP reset으로 응답합니다. 클라이언트는 Connection refused 오류를 보고합니다. 터널은 정상이나, 리스너 설정이 문제입니다.

두 가지 확실한 해결책이 있습니다. 서비스를 노드의 tailnet 주소에 바인딩하면 프록시 없이도 공용 인터페이스를 거치지 않게 할 수 있습니다. 설정에서 --bind 100.101.102.104 또는 그에 상응하는 옵션을 전달하십시오. 컨테이너의 경우 포트를 -p 100.101.102.104:3000:3000로 게시하십시오. 아니면 서비스를 loopback에 그대로 두고 그 앞에 Tailscale을 배치하십시오.

tailscale serve 3000

이 방식은 요청을 http://127.0.0.1:3000으로 프록시하며, tailnet에 대해 HTTPS 인증서가 활성화되면 tailnet 내부에서 ts.net 이름으로 서비스를 제공합니다. 이는 사용자의 노드들 사이에서만 비공개로 유지됩니다. 동일한 개념의 공개 버전은 Funnel이며, Tailscale serve와 funnel 비교에서 필요한 기능을 선택하는 방법을 다룹니다.

관련된 두 가지 작업은 별도의 페이지에서 설명합니다. Tailscale이 설치되지 않은 전체 사설 네트워크에 접근하려면 VPS를 이용한 서브넷 라우터가 필요하며, 노드의 아웃바운드 인터넷 트래픽을 다른 노드를 통해 전송하려면 exit node가 필요합니다.

더 이상 필요하지 않은 포트 닫기

모든 관리자가 tailnet을 통해 서버에 접근할 수 있게 되면, 공개된 22번 포트는 더 이상 할 일이 없습니다. 이것이 실질적인 이점입니다. 닫힌 포트는 무차별 대입 공격을 받을 수 없으며, 로그에 공격 시도가 쌓이는 일도 멈춥니다.

순서가 중요합니다. tailnet 접근 권한을 추가하고, 두 번째 세션을 통해 해당 경로로 로그인할 수 있음을 확인한 뒤에만 공개 규칙을 제거하십시오.

sudo ufw allow in on tailscale0
sudo ufw status verbose

그 후, 공개 SSH 규칙을 삭제하고 MagicDNS 이름을 사용하여 다시 연결하십시오. ufw allow in on tailscale0가 실제로 수행하는 작업을 유의하십시오. 이 설정은 터널을 통해 들어오는 모든 트래픽을 신뢰하므로, ufw 대신 Tailscale 정책 파일이 접근 제어의 중심이 됩니다. 이 점을 고려하여 정책을 작성하십시오.

컨테이너를 실행 중인 사용자에게 한 가지 주의 사항이 있습니다. Docker의 포트 게시(published port) 기능은 자체적으로 NAT 규칙을 설치하여 ufw를 우회하므로, ufw deny을 실행해도 해당 포트는 닫히지 않습니다. ufw를 우회하는 Docker 게시 포트에서 해당 메커니즘을 설명합니다. 위에서 설명한 대로 tailnet 주소로 포트를 게시하면 이 문제를 피할 수 있습니다.

Tailscale이 보호하는 것과 보호하지 않는 것

마케팅 문구는 이 경계를 모호하게 만들기 때문에 명확히 짚고 넘어갈 필요가 있습니다.

보호 대상: 두 노드 간의 트래픽은 WireGuard로 종단 간 암호화되며, 중간의 어떤 릴레이도 이를 읽을 수 없습니다. 개인 키는 키를 생성한 장비를 절대 떠나지 않습니다. 노드는 인바운드 공용 포트가 필요하지 않으므로, 인터넷에서 스캔할 수 있는 22번이나 5432번 포트 같은 것이 존재하지 않습니다. 노드 간 접근은 주소를 아는 사람이 아니라 정책 파일에 의해 결정됩니다.

보호하지 않는 대상: 조정 서버(coordination server)는 사용자의 장치 그래프를 볼 수 있습니다. 장비 이름, 소유자, 주소, 온라인 시간은 인프라를 설명하므로 이 메타데이터 자체로도 민감합니다. 또한 서버는 키를 배포하는데, 이는 더 큰 위험 요소입니다. Tailscale은 이를 직접적으로 밝히고 있습니다. "만약 Tailscale이 악의를 품고 네트워크에 몰래 새로운 노드를 삽입한다면, Tailscale은 기존 노드와 평문으로 트래픽을 주고받을 수 있습니다." 단일 로그온(SSO) 제공자도 동일한 신뢰 경로에 있습니다. 해당 서비스에서 신원을 생성할 수 있는 사람은 누구든 노드를 추가할 수 있기 때문입니다. 또한 침해당한 노드는 tailnet 내부의 피어(peer)가 되므로, 해당 노드가 접근할 수 있는 범위는 사용자의 정책이 허용하는 모든 곳이 됩니다. 이것이 수용 가능한 위험인지 여부는 방어 대상이 누구인지에 달려 있으며, 전체 신뢰 모델은 도난당한 신원 계정이 실제로 무엇을 할 수 있는지 등 각 사례를 상세히 설명합니다.

키 배포 위험에 대한 해결책은 두 가지입니다. 첫 번째는 tailnet lock입니다. 이는 기존의 신뢰할 수 있는 노드들이 새로운 노드를 암호학적으로 서명해야만 다른 노드들이 해당 노드를 수락하도록 하는 방식입니다. 유효한 서명 없이 노드를 추가하는 제어 평면(control plane)은 무시됩니다. 관리자 콘솔은 서명 노드를 위한 정확한 tailscale lock init 라인을 생성하며, 모든 노드는 자신이 보는 내용을 확인할 수 있습니다.

tailscale lock status

모든 노드는 동일한 신뢰할 수 있는 서명 키 세트를 보고해야 합니다. 두 번째 해결책은 제어 평면을 직접 운영하는 것입니다. 자체 호스팅 Headscale 조정 서버는 동일한 클라이언트에 동일한 프로토콜로 통신하므로, 장치 그래프와 키 배포를 사용자가 소유한 하드웨어로 옮길 수 있습니다. 이 경우 서버의 가동 시간(uptime) 또한 사용자가 책임져야 합니다. 아직 자체 호스팅 제어 평면을 비교 중이라면, NetBird는 단일 VPS에서 서버를 완전히 직접 운영할 수 있는 별도의 메시 VPN입니다.

첫날 반드시 수정해야 할 기본 설정이 하나 있습니다. 새로운 tailnet은 기본적으로 허용적입니다. "기본 tailnet 정책 파일은 tailnet 내의 모든 장치 간 통신을 활성화합니다." acls 섹션을 추가하는 즉시 모델은 기본 거부(deny by default)로 전환되며, 사용자가 작성한 규칙만 통과하게 됩니다.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

이 정책은 tailnet 구성원이 태그가 지정된 서버의 SSH에만 접근할 수 있게 하며, 그 외에는 아무것도 허용하지 않습니다. 와일드카드를 그대로 두지 말고 서비스별로 규칙을 추가하십시오. 와일드카드를 사용하면 도난당한 노트북 키 하나로 데이터베이스까지 접근이 가능해지기 때문입니다.

실패 유형과 표시되는 문자열

tailscale status은 항상 relay을 출력합니다. 두 노드가 직접 경로를 생성하지 못했습니다. 양쪽 끝에서 tailscale netcheck을 실행하십시오. UDP: false는 UDP 아웃바운드 트래픽이 차단되었음을 의미하며, 이 경우 릴레이만 작동할 수 있습니다. MappingVariesByDestIP: true은 엄격한 NAT가 가로막고 있음을 의미합니다. 제어 가능한 측에서 UDP 41641 포트의 인바운드 트래픽을 허용하면 문제가 해결되는 경우가 많습니다.

수개월간 정상 작동하던 노드가 사라졌습니다. 노드 키가 기본값인 180일 만료 기간을 넘겼습니다. 관리 콘솔에서 해당 머신이 만료된 것으로 표시되며, 해당 장비에서 sudo tailscale up을 실행하면 다시 복구됩니다. 이런 일이 반복되지 않도록 서버의 키 만료 설정을 비활성화하십시오.

피어는 목록에 나타나지만 연결 시 타임아웃이 발생합니다. 연결성은 정상이나 정책이 트래픽을 거부하고 있습니다. 해당 소스, 대상, 포트를 포함하는 규칙이 있는지 acls 섹션을 확인하십시오. 거부된 패킷은 응답 대신 폐기되므로, Connection refused 대신 타임아웃이 발생합니다.

MagicDNS 이름이 해석되지 않습니다. ping db-1는 실패하지만 ping 100.101.102.104는 정상 작동합니다. 무언가가 /etc/resolv.conf을 대체하여 쿼리가 100.100.100.100의 스텁 리졸버에 도달하지 못하고 있습니다. cat /etc/resolv.conf에서 100.100.100.100 설정을 확인하고, 해당 파일을 수정하는 다른 프로세스가 있는지 살펴보십시오. 이는 WireGuard 터널 내부의 DNS 문제와 동일한 유형의 문제입니다.

tailscale up이 태그를 거부합니다. 해당 태그가 정책 파일의 tagOwners 아래에 선언되지 않았습니다. 해당 위치에 태그를 추가한 뒤 명령어를 다시 실행하십시오.

FAQ

Tailscale은 VPN입니까, 아니면 메시 네트워크입니까?

두 용어 모두 정확하며, 서로 다른 계층을 설명합니다. 터널은 WireGuard를 사용하므로 VPN이 맞습니다. 토폴로지는 메시 구조인데, 이는 모든 패킷을 중앙 서버로 보내는 대신 각 노드가 통신할 노드와 직접 터널을 구축하기 때문입니다. 조정 서버(coordination server)는 제어 경로에 위치하며 데이터 경로에는 관여하지 않습니다. 따라서 서버에 접근할 수 없게 되어도 기존 터널은 트래픽을 계속 전달합니다. 장애 발생 시 중단되는 것은 새로운 노드의 합류와 키 또는 정책 변경 사항의 적용뿐입니다.

Tailscale이 내 트래픽을 읽을 수 있습니까?

내용은 읽을 수 없습니다. 트래픽은 WireGuard를 통해 노드 간 종단 간(end-to-end) 암호화되며, 개인 키는 노드를 벗어나지 않습니다. DERP 릴레이는 복호화할 방법이 없는 패킷을 전달할 뿐입니다. Tailscale은 머신 이름, 소유자, 공개 키, 엔드포인트 주소, 각 노드의 온라인 상태와 같은 메타데이터는 확인합니다. 또한 키를 배포하므로, 조정 서버가 침해되면 귀하의 플릿이 신뢰하게 될 노드를 삽입하려고 시도할 수 있습니다. Tailnet lock은 귀하가 신뢰하는 노드의 서명을 요구함으로써 이를 차단하며, Headscale을 사용하면 호스팅된 제어 평면을 배제할 수 있습니다.

Tailscale을 위해 방화벽 포트를 열어야 합니까?

인바운드 포트는 거의 열 필요가 없습니다. Tailscale의 자체 지침에 따르면 "대부분의 경우 방화벽 포트를 열 필요가 없습니다." 아웃바운드의 경우, 노드는 조정 서버 및 릴레이와 통신하기 위해 TCP 443 포트가 필요하며, STUN을 위해 UDP 3478 포트가 필요합니다. 직접 터널은 기본적으로 소스 포트 41641을 사용하는 UDP를 사용합니다. UDP 41641 인바운드를 허용하는 것은 선택 사항이며, 이는 까다로운 네트워크 환경에서 직접 연결 성공률을 높이는 데만 도움이 됩니다.

다른 노드에서 내 서비스의 3000번 포트에 접근할 수 없는 이유는 무엇입니까?

먼저 ss -tlnp를 사용하여 바인드 주소를 확인하십시오. 127.0.0.1:3000에서 대기 중인 리스너는 노드의 100.x tailnet 주소로 도착하는 연결을 거부합니다. 해당 소켓은 루프백 대상만 허용하기 때문이며, 클라이언트는 Connection refused 오류를 보게 됩니다. 서비스를 tailnet 주소에 바인드하거나, tailscale serve 3000를 실행하여 프록시하십시오. 리스너가 이미 0.0.0.0에 설정되어 있는데도 연결이 거부되지 않고 시간 초과가 발생한다면, 원인은 바인드 주소가 아니라 정책 규칙이나 호스트 방화벽일 가능성이 큽니다.

Tailscale의 조정 서버 대신 Headscale을 실행해야 합니까?

장치 그래프나 키 배포를 직접 제어하는 인프라 내에 유지해야 하거나, 외부 서비스에 대한 의존성 없이 tailnet을 운영해야 할 때는 Headscale을 실행하십시오. 클라이언트와 프로토콜은 동일합니다. 그 대가로 귀하가 직접 조정 서버를 운영해야 하며, 서버 장애 시 새로운 노드 합류나 정책 변경 적용이 중단됩니다. 소규모 플릿의 경우, tailnet lock을 활성화한 상태로 호스팅된 제어 평면을 사용하는 것이 일반적으로 더 나은 선택입니다.