Tailscale은 안전한가요? 보안 모델과 신뢰 구조 분석

Tailscale은 안전한가? 짧은 답변

Tailscale은 안전합니까? 대부분의 사용자가 우려하는 부분에 대해서는 '그렇다'입니다. tailnet을 운영하는 조정 서버(coordination server)는 트래픽을 암호화하는 개인 키를 보관하지 않으므로, 장치 간에 전송되는 데이터를 읽을 수 없습니다. Tailscale의 보안 페이지에는 "개인 키는 장치를 벗어나지 않습니다. 모든 트래픽은 항상 종단 간 암호화됩니다."라고 명시되어 있습니다. 더 중요한 질문은 따로 있습니다. 조정 서버가 침해당하거나 법적 명령을 받는 경우, 서버는 패킷을 읽을 필요가 없습니다. 서버는 어떤 공개 키를 장치가 신뢰할지 결정하므로, 사용자가 승인하지 않은 장치를 등록할 수 있습니다.

이것이 한 문장으로 요약한 신뢰 모델입니다. 암호화는 데이터를 보호하고, 제어 평면(control plane)은 멤버십을 결정합니다. 아래의 각 섹션에서는 사용자가 신뢰해야 하는 주체를 명시하고, 해당 주체가 실제로 수행할 수 있는 작업과 이를 제한하는 제어 방법을 설명합니다. 이 제품이 처음이라면 Tailscale의 정의와 메시 네트워크 작동 방식부터 확인하십시오.

제어 평면과 데이터 평면의 분리

Tailscale은 WireGuard를 기반으로 구축된 메시 VPN(가상 사설망)입니다. 이는 직접 호스팅하는 WireGuard VPS에서 수동으로 구성하는 프로토콜과 동일합니다. 모든 장치는 로컬에서 고유한 WireGuard 키 쌍을 생성합니다. Tailscale의 작동 원리 게시물은 조정 서버를 "공개 키를 위한 공유 드롭박스"라고 지칭하며, "개인 키는 노드를 절대 떠나지 않는다"고 명시합니다.

데이터 평면은 장치 간의 암호화된 트래픽을 의미합니다. 이 트래픽은 네트워크가 허용하는 경우 장치 간에 직접 이동합니다. 제어 평면은 그 외의 모든 것을 담당합니다. 여기에는 tailnet에 속한 장치, 장치별 공개 키, 접근 정책, DNS 설정, 릴레이 목록 등이 포함됩니다. Tailscale은 제어 평면을 호스팅 서비스로 운영하며, 사용자는 자신의 기기에서 데이터 평면을 실행합니다.

이 두 가지를 분리해서 생각하면 보안과 관련된 모든 질문에 답할 수 있습니다. 암호화는 데이터 평면의 속성입니다. 멤버십은 제어 평면의 결정 사항입니다. 암호화 수준이 높다고 해서 누가 피어로 허용되는지 알 수 있는 것은 아닙니다.

침해된 조정 서버는 무엇을 할 수 있습니까?

트래픽을 복호화할 수 없습니다. 암호화를 수행하는 키는 사용자의 기기에서 생성되며 절대 업로드되지 않으므로, 터널을 열 수 있는 탈취되거나 유출될 정보가 존재하지 않습니다. 이는 아래에서 자세히 다룰 릴레이 트래픽에도 동일하게 적용됩니다.

노드를 등록할 수 있습니다. Tailscale이 tailnet lock을 발표했을 때, 회사는 그 위험성을 다음과 같이 설명했습니다. 악의적인 서버는 "비밀리에 추가된 노드를 사용하여 기존 노드와 트래픽을 송수신"할 수 있으며, 이 시점에는 "피어 자체가 악의적이므로 트래픽이 암호화되어 있다는 사실은 중요하지 않게 됩니다." 사용자의 기기는 제어 평면(control plane)이 해당 키가 tailnet에 속한다고 알려주었기 때문에 피어를 신뢰합니다.

기기가 접근할 수 있는 대상을 변경할 수 있습니다. 접근 정책은 제어 평면에 존재하며 각 노드로 배포됩니다. Tailscale의 tailnet lock 백서에 따르면, tailnet lock은 "제어 평면이 침해되었을 때 새로운 노드 키 배포를 실패하게 하거나, 모든 노드에 대한 접근을 거부하는 접근 제어 정책을 배포하는 등 네트워크 연결을 방해하는 것을 막지는 못합니다."

어느 경우든 연결 메타데이터는 볼 수 있습니다. Tailscale의 네트워크 흐름 로그는 모든 기기 간 연결의 시작 및 종료 이벤트를 기록합니다. 문서에 따르면 해당 로그는 "클라이언트 작업이나 네트워크 트래픽의 내용에 관한 어떠한 정보도 포함하지 않습니다." 따라서 제어 평면은 사용자의 어떤 기기가 어떤 기기와 언제 통신했는지는 알 수 있습니다. 하지만 그들이 무엇을 주고받았는지는 알 수 없습니다.

위 목록 중 암호화와 관련된 항목은 하나뿐입니다. 나머지는 누가 구성원인지, 정책이 무엇인지에 관한 것이며, 이것이 바로 사용자가 주의를 기울여야 할 제어 항목이 등록을 관리하는 부분인 이유입니다.

ID 공급자는 tailnet의 신뢰 루트입니다

Tailscale은 자체적인 비밀번호 데이터베이스를 운영하지 않습니다. Tailscale의 문서에는 Tailscale 전용 비밀번호가 없으며, 로그인은 Apple, Google, GitHub, Microsoft, Okta, OneLogin 또는 사용자 지정 OpenID Connect 공급자와 같은 ID 공급자(IdP)에 위임된다고 명시되어 있습니다.

이 문구는 보안 정책의 핵심이므로 주의 깊게 읽어야 합니다. 귀하의 Google 또는 Microsoft 계정에 로그인할 수 있는 사람은 누구든 귀하의 tailnet에 로그인할 수 있습니다. 귀하의 다중 인증(MFA)은 해당 IdP가 강제하는 정책을 따릅니다. 퇴사자 처리는 해당 IdP가 직원을 삭제할 때 수행하는 절차에 의존합니다. 피싱으로 탈취된 IdP 계정은 곧 tailnet 계정이 되며, 공격자는 WireGuard를 직접 공격할 필요가 없습니다. 공격자는 단순히 기기를 추가하고 귀하의 정책이 해당 사용자에게 부여한 모든 권한을 상속받게 됩니다.

탈취된 ID 계정이 tailnet 내부에서 기기로 작동하는 것을 막는 두 가지 통제 수단은 기기 승인(device approval)과 키 만료(key expiry)입니다. Tailnet lock은 세 번째 통제 수단이며, 이는 계정이 아닌 제어 평면(control plane)을 보호하는 것을 목표로 합니다.

기기 승인: 사람이 승인하기 전까지는 아무것도 연결되지 않음

Tailscale 문서에서는 기기 승인을 "Tailscale 네트워크 관리자가 새로운 기기가 Tailscale 네트워크에 참여하기 전에 검토하고 승인할 수 있게 해주는" 기능으로 설명합니다. 소유자(Owner), 관리자(Admin) 또는 IT 관리자가 승인할 수 있습니다. 새로운 기기는 누군가 조치를 취하기 전까지 Machines 페이지에 "Needs approval" 배지를 표시합니다.

이 기능을 켜면 계정 탈취 시나리오의 양상이 달라집니다. 공격자가 로그인하여 기기를 등록하더라도, 기기는 아무것도 연결하지 못한 채 대기 상태가 됩니다. 관리 콘솔에는 본인이 알지 못하는 기기가 참여를 요청하고 있다는 배지가 표시됩니다. 인증 키(auth key)를 생성할 때 미리 승인된 것으로 표시하거나 API를 통해 기기를 승인할 수 있으므로 자동화는 여전히 정상적으로 작동합니다.

인증 키는 또 다른 진입 경로이므로 자격 증명으로 취급해야 합니다. Tailscale 문서는 위험한 유형의 키에 대해 다음과 같이 명확히 경고합니다. "재사용 가능한 키는 매우 주의해서 사용하십시오! 도난당할 경우 매우 위험할 수 있습니다. 이러한 키는 전용 키 보관소(key vault) 제품에 보관하는 것이 가장 좋습니다." 2026년 8월 기준으로 문서화된 키 만료 범위는 1일에서 90일이며, 만료 기간을 지정하지 않으면 기본값인 90일이 적용됩니다. 일회용 키를 우선적으로 사용하고, 생성과 삭제가 잦은 기기에는 ephemeral 설정을 적용하십시오. 재사용 가능한 키는 셸 스크립트에 직접 넣지 말고 Ansible Vault로 암호화하거나 비밀 관리자(secrets manager)에 보관하십시오.

키 만료: 다른 모든 실수를 제한하는 타이머

노드 키는 만료되며, 이 기능 덕분에 도난당하거나 잊힌 장치가 일시적인 문제로 끝납니다. Tailscale 문서에 따르면 "기본적으로 새 도메인은 180일의 만료 기간으로 설정"되며, "재인증이 이루어지지 않으면 키가 만료되고 해당 엔드포인트와의 연결이 중단됩니다." 장치를 직접 재인증할 수 있습니다.

tailscale up --force-reauth

문서는 이 작업이 "tailnet 연결을 끊을 수 있으므로, 연결이 끊겼을 때를 대비한 대체 로그인 수단 없이 SSH나 RDP를 통해 원격으로 수행해서는 안 된다"고 경고합니다. 현재 사용 중인 네트워크가 중단될 것이므로, 콘솔 접근 권한을 열어두거나 해당 머신에 접속할 수 있는 다른 경로를 확보한 상태에서 실행하십시오.

서버는 이러한 제어가 유연하게 적용되는 곳입니다. 180일마다 재인증해야 하는 머신은 아무도 지켜보지 않는 새벽 3시에 tailnet에서 이탈하게 되므로, 관리자는 서버의 키 만료 기능을 비활성화합니다. 이는 도난당한 키를 결국 차단하게 될 타이머를 제거하는 셈입니다. 서버에는 태그가 지정된 장치를 사용하는 것이 더 나은 해결책입니다. 태그는 특정 개인이 아닌 머신 자체를 소유하므로, 해당 인원이 퇴사하더라도 머신은 계속 유지됩니다. 어떤 결정을 내리든 만료가 비활성화된 머신 목록을 유지하십시오. 해당 키는 장치를 삭제하기 전까지 계속 유효합니다.

Tailnet lock: 조정 서버를 신뢰 체인에서 제외하기

Tailnet lock은 등록 문제를 직접적으로 해결합니다. Tailscale의 Tailnet lock 문서는 이 메커니즘을 다음과 같이 설명합니다. "새 노드가 tailnet에 참여할 때, 해당 노드의 공개 노드 키는 Tailnet Lock 키의 서명을 요구합니다. 조정 서버는 서명된 공개 노드 키를 피어 노드들에 배포합니다." 기존 장치들은 피어를 수락하기 전에 해당 서명을 검증하므로, 제어 평면이 임의로 생성한 노드 키는 거부됩니다.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init를 사용하면 이 기능을 활성화할 수 있으며, 활성화 시점에 서명 노드를 지정합니다. Tailscale은 초기화 시 최소 2개의 서명 노드를 요구하며, 하나의 tailnet당 최대 20개까지 허용합니다. 그 이후부터는 모든 새 장치가 서명 노드 중 하나로부터 서명을 받아야 하며, 이는 실제 운영 비용을 발생시킵니다. 예를 들어 휴대폰을 추가하려면 노트북에서 명령어를 실행해야 합니다.

제한 사항은 문서화되어 있으며, 기능 설명보다 더 중요하게 고려해야 합니다.

• 비활성화 비밀 키(disablement secret)를 분실하면 복구할 방법이 없습니다. 문서는 "비활성화 비밀 키를 분실했고 Tailscale 지원팀에 제공하지 않았다면, 해당 tailnet은 복구할 수 없습니다"라고 명시합니다.
• 서명 키는 사용자가 소유한 장치에 저장되므로, 해당 장치의 보안 수준을 그대로 따릅니다. 문서는 "장치가 침해되면 키를 탈취당할 수 있다"고 명확히 밝힙니다.
• 두 가지 제어 방식을 동시에 사용할 수 없습니다. Tailscale은 tailnet lock과 장치 승인(device approval) 기능이 상호 배타적이므로, 하나를 활성화하면 다른 하나는 포기해야 한다고 명시합니다.
• 이는 최초 사용 시 신뢰(TOFU, Trust On First Use) 방식입니다. 초기 설정은 여전히 제어 평면을 거치며, 신뢰의 닻은 첫 번째 단계가 완료된 후에야 사용자 본인의 네트워크로 이동합니다.

Tailnet lock은 멤버십을 보호합니다. 백서에서도 명시하듯, 이 기능은 가용성을 보호하지는 않습니다.

릴레이 연결이 내 트래픽을 노출합니까?

아니요. 두 장치가 서로 직접 연결할 수 없을 때, 트래픽은 DERP(Designated Encrypted Relay for Packets) 서버를 경유하게 됩니다. Tailscale의 문서는 이 특성을 다음과 같이 명확히 설명합니다. "Tailscale 개인 키는 키를 생성한 로컬 장치를 절대 떠나지 않으므로, DERP 서버가 사용자의 트래픽을 복호화하는 것은 불가능합니다. DERP 서버는 이미 암호화된 트래픽을 한 장치에서 다른 장치로 단순히 전달할 뿐입니다."

릴레이를 사용하면 속도가 저하되며, 릴레이 서버는 메타데이터를 관찰할 수 있습니다. 즉, 암호화된 두 종단점과 그 사이를 오가는 데이터의 타이밍 및 전송량을 알 수 있습니다. 현재 사용 중인 연결 방식을 확인하려면 다음을 참고하십시오.

tailscale status
tailscale netcheck

tailscale status는 모든 피어의 연결 상태를 직접 연결인 경우 direct 203.0.113.10:41641로, 릴레이 연결인 경우 relay과 함께 릴레이 서버 이름 및 바이트 카운터를 표시합니다. 피어가 계속 릴레이 상태로 유지된다면 양쪽 끝단이 직접 경로를 생성하지 못한 것이며, 이는 보통 어딘가에서 UDP가 차단되었거나 양측 모두 엄격한 NAT(network address translation) 뒤에 위치하기 때문입니다. tailscale netcheck는 해당 장치에서 UDP가 정상적으로 작동하는지, NAT가 포트를 어떻게 매핑하는지, 그리고 가장 가까운 릴레이까지의 지연 시간은 얼마인지 보고합니다. 이를 통해 앞서 언급한 두 가지 원인 중 무엇이 문제인지 파악할 수 있습니다.

Exit node는 트래픽의 출구를 옮길 뿐 제거하지 않습니다

Exit node는 기본 경로인 0.0.0.0/0 및 ::/0을 사용하여 기기의 모든 공용 인터넷 트래픽을 tailnet 내의 다른 기기로 라우팅합니다. Linux 환경에서 서비스를 제공하는 머신은 이를 광고(advertise)하며, 각 클라이언트는 이를 선택적으로 사용합니다:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Exit node는 관리자 콘솔에서 소유자(Owner), 관리자(Admin) 또는 네트워크 관리자(Network admin)의 승인을 받아야 하며, 클라이언트가 이를 사용하려면 정책에서 autogroup:internet 권한을 부여해야 합니다. 이 두 단계는 의도적으로 설계되었습니다. 승인되지 않은 머신이 전체 tailnet의 통로로 임의로 지정될 수 없도록 하기 위함입니다.

이제 신뢰 문제를 살펴보겠습니다. 트래픽은 노트북에서 exit node까지 암호화된 상태로 전달됩니다. 이후 해당 머신을 떠나는 트래픽은 일반적인 인터넷 트래픽이 되며, 해당 머신의 IP 주소를 사용합니다. 따라서 exit node의 운영자는 사용자의 목적지를 확인할 수 있으며, 해당 머신의 호스팅 제공업체와 상위 네트워크도 마찬가지입니다. 즉, 관찰 지점을 삭제한 것이 아니라 위치를 옮긴 것입니다. 원격지 서버를 직접 제어하는 경우에는 VPS에서 직접 exit node를 운영하는 것이 합리적인 선택이지만, 그렇지 않은 경우에는 보안상 불리할 수 있습니다.

기본 정책은 평면 네트워크입니다

새로운 tailnet은 허용적인 상태로 출시됩니다. Tailscale의 접근 제어 문서에 따르면 기본 정책 파일은 "tailnet 내의 모든 장치 간 통신을 활성화"합니다. 모든 장치가 모든 포트에서 다른 모든 장치에 접근할 수 있습니다. 이것이 평면 네트워크입니다. 외부 공격자로부터는 보호되지만, 감염된 노트북으로부터는 아무런 보호를 하지 못하는 터널 내부로 네트워크를 옮긴 셈입니다.

tailnet 정책 파일에서 이를 강화하십시오. 이 파일은 접근 제어 목록(ACL)이나 더 새로운 방식인 grants를 허용하며, 두 방식 모두 주석을 지원하는 JSON 방언으로 작성됩니다.

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

이 정책은 특정 그룹이 운영 서버의 SSH에 접근하도록 허용하고, 구성원이 exit node를 사용하도록 하며, 그 외의 모든 접근은 생략을 통해 거부합니다. Tailscale은 요금제별로 사용 가능한 규칙 대상을 명시하고 있으므로, 태그나 autogroup을 기반으로 설계하기 전에 이를 확인하십시오. 또한 무료 요금제에 실제로 포함된 기능을 참조하십시오. 개인 휴대폰과 같이 들어오는 연결을 절대 허용해서는 안 되는 장치의 경우, tailscale set --shields-up을 사용하여 클라이언트 측에서 차단하십시오.

Headscale을 사용하여 컨트롤 플레인을 자체 호스팅할 때 달라지는 점

Headscale은 "Tailscale 컨트롤 서버를 오픈 소스로 직접 구현한 것"입니다. README에서는 그 범위를 솔직하게 밝히고 있습니다. "개인 용도나 소규모 오픈 소스 조직에 적합한 단일 Tailscale 네트워크(tailnet)라는 좁은 범위만을 구현합니다." 기능 목록에는 ACL 및 권한 부여, 서브넷 라우터, 엑셀 노드, 내장 DERP 서버, Tailscale SSH, Taildrop이 포함됩니다. 만약 이 좁은 범위가 걸림돌이라면, 자체 호스팅 가능한 컨트롤 플레인을 제공하는 또 다른 메시 네트워크인 NetBird를 고려할 수 있으며, 직접 VPS에서 NetBird 서버를 운영하면 동일한 등록 결정권을 본인 소유의 하드웨어로 옮길 수 있습니다.

달라지는 점은 비정상 노드를 등록할 수 있는 주체의 신원입니다. Headscale을 사용하면 키 디렉터리와 정책이 본인의 서버에 저장됩니다. 제3자는 귀하의 기기 공개 키 목록을 보유하지 않으며, 제3자가 이를 제출하도록 강요받거나 임의로 서명할 수도 없습니다.

달라지지 않는 점은 데이터 플레인입니다. 동일한 종단 간 암호화(end-to-end encryption)를 사용하는 동일한 WireGuard이며, 직접 경로가 불가능할 때 사용하는 릴레이 폴백 방식도 같습니다. 또한 가동 시간 유지, 패치, 백업, 서버의 물리적 보안과 같이 Tailscale이 수행하던 작업도 직접 관리해야 합니다. Headscale 호스트가 침해되면 공격자는 조정 서버가 침해되었을 때와 동일하게 노드를 등록하고 정책을 배포할 권한을 얻게 됩니다. Tailnet lock은 Headscale의 기능 목록에 없으므로, 해당 위험에 대한 보완책은 사용할 수 없습니다. 소유권 문제가 결정적인 요소라면, Headscale을 이용한 컨트롤 플레인 자체 호스팅 가이드를 통해 설정을 진행할 수 있습니다.

Tailscale이 보호하는 대상

• 공개 리스닝 포트. tailnet 주소에 바인딩된 서비스는 인터넷에서 접근할 수 없으므로, 모든 VPS의 22번 포트를 훑는 스캐너는 해당 서비스를 발견할 수 없습니다. 예외는 사용자가 직접 활성화한 경우뿐입니다. Funnel은 의도적으로 tailnet 서비스를 공개 인터넷에 노출하므로, 명령을 실행하기 전에 serve와 funnel의 차이를 이해하는 것이 중요합니다. Docker 포트를 공개하면 자체 규칙을 작성하여 공개 인터페이스에서 ufw를 우회하므로, 호스트 방화벽은 그대로 유지하십시오.
• 노출된 로그인에 대한 비밀번호 추측. 포트가 터널 내부에서만 응답하면 공격자가 시도할 대상이 없습니다. 이는 열린 포트에 rate limiting을 적용하는 것보다 강력한 방어 수단이지만, 공개 상태를 유지해야 하는 서비스에는 여전히 Ubuntu 24.04의 fail2ban을 실행하는 것이 좋습니다.
• 경로상의 신뢰할 수 없는 네트워크. 기기 간 트래픽은 카페 네트워크나 공유 제공업체 LAN을 통과할 때 종단 간 암호화되며, 릴레이될 때도 암호화 상태가 유지됩니다.
• 수동 키 관리. WireGuard 설정에 피어를 수동으로 추가할 때마다 주소를 재사용하거나 잘못된 키를 붙여넣을 위험이 있습니다. Tailscale 메시는 이러한 관리를 자동으로 처리하며, 이것이 WireGuard와 Tailscale의 실질적인 차이 대부분을 차지합니다.

Tailscale이 보호하지 못하는 영역

• 손상된 엔드포인트. tailnet은 등록된 장치를 신뢰합니다. 승인된 노트북에 악성코드가 감염되면 해당 장치의 터널, tailnet 주소, 그리고 정책상 허용된 모든 권한을 악성코드가 탈취할 수 있습니다. 이는 가장 큰 보안 공백이며, 어떤 VPN도 이를 완전히 해결할 수는 없습니다.
• 악의적이거나 부주의한 관리자. 정책 파일을 수정할 수 있는 사람은 누구든 자신에게 모든 접근 권한을 부여할 수 있으며, 소유자(Owner) 계정을 탈취한 사람도 동일한 작업을 수행할 수 있습니다. 코드 리뷰를 수행하는 것과 같은 방식으로 정책 변경 사항을 검토하십시오.
• 트래픽 분석. ISP(인터넷 서비스 제공업체)는 엔드포인트로 향하는 암호화된 UDP 패킷의 흐름, 타이밍, 데이터 양을 확인할 수 있습니다. Tailscale의 흐름 로그(flow logs)에는 어떤 피어들이 언제 통신했는지 기록됩니다. 두 경우 모두 데이터의 내용은 볼 수 없지만, 연결 사실 자체는 숨겨지지 않습니다. 따라서 해당 목적을 위해 도구를 선택하기 전에 Tor와 VPN의 차이점을 먼저 읽어보시기 바랍니다.
• 이미 분실한 장치. 키 만료(Key expiry)는 기본값이 180일로 설정되어 있어 즉각적인 대응책이 되기 어렵습니다. 관리 콘솔에서 장치를 삭제하는 것이 가장 빠른 대응 방법이므로, 긴급 상황이 발생하기 전에 해당 버튼의 위치를 미리 확인해 두십시오.

본인의 tailnet 점검하기

1. 장치에서 tailscale status를 실행하여 피어 목록을 확인합니다. 이름을 알 수 없는 장치가 있다면, 이는 바로 장치 승인 기능이 방지하고자 하는 상황입니다.
2. tailscale lock status를 실행하여 tailnet lock이 활성화되어 있는지 확인한 다음, 모든 새 장치에 서명하는 비용을 감수할 가치가 있는지 결정합니다.
3. 관리 콘솔을 열어 키 만료가 비활성화된 모든 장치와 여전히 존재하는 모든 재사용 가능한 인증 키를 기록합니다. 두 경우 모두 타이머가 없는 자격 증명입니다.
4. 정책 파일을 읽어봅니다. 기본 설정 상태라면 모든 장치가 모든 포트에서 다른 모든 장치에 접근할 수 있으므로, 감염된 노트북 하나가 모든 장치에 접근할 수 있게 됩니다.

Tailscale은 데이터 평면에서의 설계 덕분에 운영자가 사용자의 트래픽을 읽을 수 없다는 평판을 얻었습니다. 이 주장을 벤더의 문서대로 받아들이되, 본인의 영역인 ID 계정, 승인 설정, 만료 목록, 정책 파일은 직접 감사해야 합니다. Tailscale의 보안 페이지는 SOC 2 Type II 인증과 Latacora와의 지속적인 보안 작업을 보고하고 있는데, 이는 그들의 프로세스에 대한 증거일 뿐 사용자의 구성에 대한 보증은 아닙니다.

FAQ

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

아니요. 트래픽은 각 기기에서 생성된 WireGuard 키로 암호화됩니다. Tailscale 보안 페이지에 따르면 "개인 키는 기기를 절대 떠나지 않으며, 모든 트래픽은 항상 종단 간 암호화(end-to-end encrypted)됩니다." 이는 DERP 릴레이를 거치는 연결에도 동일하게 적용됩니다. 릴레이는 "이미 암호화된 트래픽을 한 기기에서 다른 기기로 맹목적으로 전달"할 뿐이며, 복호화에 필요한 키를 보유하지 않기 때문입니다. Tailscale 인프라가 확인하는 정보는 메타데이터뿐입니다. 어떤 기기가 존재하는지, 그리고 어떤 기기들이 언제 서로 연결되었는지에 대한 정보만 기록됩니다.

Tailscale 조정 서버가 침해당하면 실제로 무엇을 할 수 있습니까?

노드를 등록할 수 있습니다. Tailscale의 tailnet lock 공지사항은 몰래 추가된 노드가 "기존 노드와 트래픽을 송수신"할 수 있는 위험을 설명합니다. 이 경우 상대 노드 자체가 악의적일 수 있으므로 암호화는 도움이 되지 않습니다. 침해된 제어 평면은 기기들의 접근 대상을 변경하는 정책을 배포할 수도 있으며, tailnet lock 백서에 따르면 새로운 노드 키 배포를 실패하게 만들어 연결을 끊을 수도 있습니다. 하지만 기존 기기 간의 트래픽은 복호화할 수 없습니다. 해당 기기들의 개인 키를 보유한 적이 없기 때문입니다.

Exit node를 사용하면 ISP로부터 내 브라우징 기록을 숨길 수 있습니까?

사용 중인 네트워크(가정용 또는 카페 ISP 포함)로부터 목적지를 숨길 수 있습니다. 모든 트래픽이 Exit node를 향하는 암호화된 상태로 기기를 떠나기 때문입니다. 다만 이것이 익명성을 보장하지는 않습니다. 대신 Exit node가 목적지를 확인하게 되며, 해당 노드의 호스팅 제공업체와 상위 네트워크도 이를 알 수 있습니다. 방문하는 사이트는 사용자의 IP가 아닌 Exit node의 IP 주소를 보게 됩니다. 관찰자를 다른 대상으로 바꾼 것이므로, 실제로 신뢰할 수 있는 대상을 선택해야 합니다.

Headscale이 Tailscale 조정 서버보다 더 안전합니까?

엄밀히 더 안전하다기보다는 신뢰에 대한 결정이 다른 것입니다. Headscale을 사용하면 키 디렉터리와 정책을 직접 관리하므로, 외부 당사자가 강제로 귀하의 tailnet에 기기를 등록할 수 없습니다. 대신 서버 운영(패치, 가동 시간, 백업, 호스트 자체의 보안)에 대한 책임을 직접 져야 합니다. 침해된 Headscale 호스트는 공격자에게 침해된 조정 서버와 동일한 등록 권한을 제공합니다. 또한 tailnet lock은 Headscale의 기능 목록에 없으므로, 해당 호스트를 그에 맞춰 적절히 보호해야 합니다.

tailnet에 포함된 VPS에도 방화벽이 여전히 필요합니까?

네. 공용 네트워크 인터페이스는 여전히 존재하며, 0.0.0.0에 바인딩된 모든 서비스는 Tailscale 실행 여부와 관계없이 인터넷에서 접근할 수 있습니다. 서비스를 tailnet 주소에 바인딩하고, 공용 인터페이스에는 기본 거부(default deny) 정책을 유지하십시오. 또한 Docker가 자체 규칙을 삽입하여 닫혔다고 생각한 포트를 노출할 수 있으므로, 게시된 컨테이너 포트를 반드시 확인하십시오.