Ubuntu Tailscale 설치 오류 해결 방법

Ubuntu에서 Tailscale 설치 오류가 apt 오류인 이유

Ubuntu에서 발생하는 Tailscale 설치 오류는 대부분 Tailscale 코드가 실행되기 전에 발생합니다. 이는 apt 오류입니다. Ubuntu는 자체적으로 tailscale 패키지를 제공하지 않습니다. 2026년 8월 기준으로 Ubuntu 패키지 아카이브를 확인한 결과, 일치하는 항목은 Go 헬퍼 라이브러리와 python3-tailscale뿐이므로, 데몬은 반드시 pkgs.tailscale.com에 있는 Tailscale의 자체 apt 저장소에서 가져와야 합니다.

해당 저장소를 추가하면 두 개의 파일이 생성됩니다. 하나는 apt에 패키지 위치를 알려주는 파일이고, 다른 하나는 apt가 저장소 인덱스의 서명을 확인하는 데 사용하는 공개 키를 담고 있습니다. 아래에 나열된 거의 모든 실패 사례는 이 두 파일 중 하나가 잘못되었거나, apt와 저장소 사이의 장비가 요청을 거부하여 발생합니다.

다음은 Tailscale이 Ubuntu 24.04를 위해 게시한 명령어입니다.

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

noble는 Ubuntu 24.04의 코드네임이며, 두 URL 모두에 포함되어 있습니다. 두 번째 명령어는 /etc/apt/sources.list.d/tailscale.list 파일에 주석 한 줄과 deb 한 줄을 작성하며, cat을 실행하면 해당 파일에 정확히 무엇이 기록되었는지 확인할 수 있습니다.

cat /etc/apt/sources.list.d/tailscale.list

해당 deb 줄을 네 개의 필드로 구성된 주소로 읽어 보십시오. 대괄호로 묶인 옵션 [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], https를 통해 접근하는 저장소 베이스인 pkgs.tailscale.com/stable/ubuntu, 스위트(suite)인 noble, 그리고 컴포넌트인 main입니다. apt는 베이스와 스위트를 하나의 URL로 결합하여 가져옵니다: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. 만약 수동으로 해당 URL을 가져올 수 있다면, apt도 가져올 수 있습니다. 이것이 진단의 전부입니다.

설정을 변경하기 전에 apt 오류 메시지 확인하기

오류 메시지가 화면에서 사라지지 않도록 업데이트 명령을 단독으로 실행합니다.

sudo apt update

실패한 타르트 파티(third-party) 저장소는 다음과 같이 표시됩니다. 코드네임과 IP 주소는 사용자의 시스템 환경에 따라 다를 수 있습니다.

E: Failed to fetch https://pkgs.tailscale.com/stable/ubuntu/dists/wilma/InRelease  404  Not Found [IP: 203.0.113.9 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.

출력된 내용 중 다음 단계의 조치를 결정하는 요소는 상태 코드와 E: Failed to fetch 줄에 표시된 전체 URL입니다. 하단 요약 줄만 보고 섣불리 판단하지 마십시오. URL을 복사하여 서버에 직접 요청을 보내 확인해야 합니다.

curl -sS -o /dev/null -w '%{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

이 명령은 Tailscale이 게시한 코드네임에 대해 200을 출력합니다. 2026년 8월 확인 결과, noble은 Origin: Tailscale 및 Codename: noble가 포함된 서명된 인덱스를 반환합니다. noble을 본인의 오류 메시지에 나타난 코드네임으로 바꾸어 다시 실행하십시오. 만약 apt에서는 오류가 발생했으나 curl 명령으로 200을 정상적으로 받아온다면, 저장소는 정상이며 문제는 apt 자체 설정에 있는 것입니다.

상태 코드가 의미하는 것

• 404 Not Found는 해당 경로에 파일이 없음을 의미합니다. pkgs.tailscale.com의 경우, 이는 거의 항상 URL에 포함된 코드네임을 의미합니다.
• 403 Forbidden는 서버가 응답했으나 요청을 거부했음을 의미합니다. 2026년 8월 기준으로 이 저장소는 존재하지 않는 경로에 대해 404를 반환하므로, 403이 발생했다면 귀하의 서버와 Tailscale 사이에 있는 프록시, 필터링 장비 또는 방화벽이 원인일 가능성이 높습니다.
• 401 Unauthorized 또는 407 Proxy Authentication Required은 프록시가 자격 증명을 요구하지만 apt가 이를 전송하지 않고 있음을 의미합니다.
• 연결 오류나 이름 해석 오류는 HTTP 통신 자체가 전혀 이루어지지 않았음을 의미합니다. IPv6 섹션으로 넘어가 확인하십시오.

URL에 포함된 코드네임은 Tailscale이 공개하지 않는 값입니다

Tailscale은 Ubuntu 코드네임별로 별도의 디렉터리를 구축합니다. 존재하지 않는 코드네임을 요청하면 서버에 제공할 dists/<codename>이 없으므로 404 오류가 발생합니다. pkgs.tailscale.com/stable에 있는 공급업체의 목록에서 존재하는 코드네임을 확인할 수 있습니다. 2026년 8월 기준으로 해당 목록은 16.04부터 Ubuntu 26.04인 resolute까지 포함합니다.

잘못된 코드네임이 입력되는 일반적인 원인은 Ubuntu 기반이지만 Ubuntu는 아닌 배포판에서 lsb_release -cs를 실행하는 경우입니다. Linux Mint 22에서 해당 명령을 실행하면 Mint 자체 코드네임인 wilma이 출력되는데, Tailscale은 이를 위한 패키지를 제공하지 않습니다. 대신 기반이 되는 Ubuntu 버전을 확인하십시오.

. /etc/os-release
echo "$VERSION_CODENAME $UBUNTU_CODENAME"

Ubuntu에서는 두 값이 동일합니다. 파생 배포판의 경우 VERSION_CODENAME은 파생 배포판의 이름이고 UBUNTU_CODENAME는 기반이 되는 Ubuntu 릴리스입니다. 두 URL 모두에 UBUNTU_CODENAME을 사용하십시오.

두 번째 원인은 릴리스 업그레이드입니다. Ubuntu 업그레이드 도구는 실행 시 타사 소스를 비활성화합니다. 따라서 Ubuntu 24.04에서 26.04로 업그레이드한 후에는 /etc/apt/sources.list.d/tailscale.list가 주석 처리되어 있거나, 현재 resolute인 시스템에서 여전히 noble를 가리키고 있는 것을 발견하게 됩니다. 새로운 코드네임으로 두 개의 curl 명령을 다시 실행하여 파일을 덮어쓰면 문제가 해결됩니다.

세 번째 원인은 시점 문제입니다. 새로운 Ubuntu 릴리스가 출시된 후 몇 주 동안은 Canonical에는 코드네임이 존재하지만 Tailscale에는 아직 없을 수 있습니다. 패키지 의존성이 적기 때문에 이전 LTS 코드네임을 지정해도 일반적으로 설치는 진행되지만, 이 경우 이전 릴리스용으로 빌드된 패키지를 실행하게 됩니다. apt policy tailscale을 사용하여 실제로 설치된 버전을 확인하고, 실제 코드네임이 추가되면 파일을 다시 수정하십시오.

키링이 비어 있고, 이를 작성한 명령어가 아무런 출력을 내놓지 않는 경우

이 문제는 조용히 발생하며, 대부분의 오류가 여기서 끝납니다. 키링 명령어를 다시 확인하십시오.

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null

셸은 두 프로그램이 실행되기 전에 전체 파이프라인을 구성하므로, sudo tee은 키링 경로를 열고 즉시 0바이트로 잘라냅니다(truncate). 만약 curl이 실패하고 -f가 HTTP 오류 발생 시 curl을 실패하게 만들면, curl은 아무것도 쓰지 않고 0이 아닌 값으로 종료됩니다. 파일은 0바이트 상태로 남습니다. 파이프라인의 종료 상태는 마지막 명령어의 상태를 따르는데, 이는 tee이며 성공한 것으로 간주됩니다. 아무것도 출력되지 않으므로, 사용자는 키가 설치되었다고 믿고 다음 명령어로 넘어갑니다.

명령어가 아닌 파일을 직접 확인하십시오.

ls -l /usr/share/keyrings/tailscale-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg

정상적인 키링은 pub 라인과 Tailscale을 명시하는 uid 라인을 출력합니다. 0바이트 파일은 gpg: no valid OpenPGP data found.만 출력하고 아무것도 보여주지 않습니다. HTML 오류 페이지가 저장된 파일도 동일하게 출력하며, 해당 파일에 head -c 80를 실행하면 바이너리 키 데이터 대신 웹 페이지의 시작 부분이 나타납니다.

사용 가능한 키가 없는 키링을 사용하면, sudo apt update는 인덱스를 다운로드한 후 이를 거부합니다. Tailscale 저장소와 해당 제품군을 명시하는 W: GPG error 라인, The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 텍스트와 16자 길이의 키 ID, 그리고 그 아래에 저장소가 서명되지 않았다는 오류 메시지가 표시됩니다. apt가 무엇을 알리고 있는지 주목하십시오. 인덱스는 정상적으로 다운로드되었으나 서명을 확인할 수 없다는 뜻입니다. 이는 네트워크 문제가 아니라 키 문제입니다. 키링 파일이 아예 존재하지 않는 경우에는 메시지가 달라지며, Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg을 통해 경로를 직접 명시합니다.

다운로드 실패로 인해 정상 작동하던 키링이 손상되지 않도록, 키를 두 단계로 나누어 작성하십시오.

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg -o /tmp/tailscale.gpg
gpg --show-keys /tmp/tailscale.gpg
sudo install -m 0644 -o root -g root /tmp/tailscale.gpg /usr/share/keyrings/tailscale-archive-keyring.gpg

중간 라인이 관문 역할을 합니다. Tailscale uid가 출력되지 않는다면, 작업을 멈추고 파일을 복사하지 마십시오. 모드 0644이 중요한 이유는 apt가 데이터를 가져오고 검증하기 위해 권한이 없는 _apt 사용자로 전환하기 때문입니다. 따라서 root만 읽을 수 있는 키링은 apt가 사용할 수 없습니다.

.list 파일과 .sources 파일이 동일한 저장소를 가리키는 경우

Ubuntu는 24.10 버전부터 자체 소스 형식을 deb822로 전환했으며, 이 과정에서 /etc/apt/sources.list가 /etc/apt/sources.list.d/ubuntu.sources으로 변경되었습니다. Tailscale은 여전히 한 줄 형식(one line format)으로 배포합니다. 2026년 8월 확인 결과, pkgs.tailscale.com에서 다운로드할 수 있는 .sources 파일은 존재하지 않으며 해당 URL은 404 오류를 반환합니다. 따라서 시스템에 tailscale.sources 파일이 있다면 사용자가 직접 작성했거나 가이드에 따라 생성된 것이며, 만약 tailscale.list 파일도 함께 존재한다면 apt는 동일한 저장소가 두 번 정의된 것으로 인식합니다.

경미한 경우에는 업데이트 시마다 다음과 같은 경고가 출력됩니다.

W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/tailscale.list:1 and /etc/apt/sources.list.d/tailscale.sources:1

심각한 문제는 두 파일이 서로 다른 키링(keyring) 경로를 지정할 때 발생합니다. apt가 어떤 키가 해당 저장소를 관장하는지 결정할 수 없기 때문입니다. 이 경우 E: Conflicting values set for option Signed-By regarding source 메시지와 함께 저장소 및 제품군 정보, 그리고 !=로 구분된 두 개의 키링 경로가 출력되며 작업이 중단됩니다.

E: The list of sources could not be read.

이 오류는 파일 중 하나를 제거하기 전까지 업데이트뿐만 아니라 모든 apt 명령을 차단합니다. 동일한 오류가 Ubuntu 자체 저장소에서도 발생할 수 있으며, deb822 마이그레이션 후 발생하는 중복 apt 소스 오류 문서에서 일반적인 해결 방법을 확인할 수 있습니다.

파일을 삭제하기 전에 Tailscale을 언급하는 모든 파일을 찾으십시오.

grep -RIn tailscale /etc/apt/sources.list /etc/apt/sources.list.d/

파일 하나만 남겨두십시오. 다른 파일을 삭제하지 않고 비활성화하려면 이름을 변경하십시오. apt는 .list 또는 .sources로 끝나는 파일만 읽으므로, tailscale.list.bak로 이름을 바꾸면 apt는 이를 무시하며 파일은 참조용으로 디스크에 남게 됩니다.

deb822 소스 파일을 올바르게 작성하기

새로운 형식을 선호한다면, 저장소 주소를 다시 입력하지 말고 기존 파일을 변환하십시오. 오타가 발생하면 위에서 언급한 오류가 시작되기 때문입니다. 최근 apt 릴리스에는 .list 파일을 deb822 스탠자로 다시 작성하고 signed-by 옵션을 Signed-By로 옮겨주는 변환기가 포함되어 있습니다.

apt modernize-sources --help
sudo apt modernize-sources

Ubuntu 24.04에는 해당 하위 명령이 포함되기 이전 버전의 apt가 탑재되어 있으므로, 도움말 라인을 확인하면 사용 중인 버전에 해당 기능이 있는지 즉시 알 수 있습니다. 기능이 없다면 디스크에 이미 존재하는 라인에서 스탠자를 구성하십시오. 이렇게 하면 직접 입력하는 대신 공급업체의 파일에서 기본값을 가져올 수 있습니다.

. /etc/os-release
{
  echo 'Types: deb'
  echo "URIs: $(awk '/^deb /{print $3}' /etc/apt/sources.list.d/tailscale.list)"
  echo "Suites: $UBUNTU_CODENAME"
  echo 'Components: main'
  echo 'Signed-By: /usr/share/keyrings/tailscale-archive-keyring.gpg'
} | sudo tee /etc/apt/sources.list.d/tailscale.sources
sudo rm /etc/apt/sources.list.d/tailscale.list

이 명령은 작성된 스탠자를 출력하므로, 다음 apt update을 실행하기 전에 필드 내용을 검토할 수 있습니다. 각 필드가 서로 다른 방식으로 실패할 수 있으므로 다음 네 가지 필드를 자세히 알아두는 것이 좋습니다.

• URIs은 저장소의 기본 경로에서 멈춥니다. 여기에 dists/noble 부분을 붙여넣으면 404 오류가 발생합니다. apt가 스스로 dists/<suite>를 추가하여 dists/noble/dists/noble을 요청하기 때문입니다.
• Suites은 코드네임이며, 한 줄 형식의 중간에 있던 값과 정확히 일치합니다.
• Signed-By는 키링 파일의 절대 경로를 사용합니다. 또한 그 아래에 인라인으로 아머드 키를 입력할 수도 있는데, 이때 키의 모든 라인은 공백 한 칸으로 들여쓰기해야 하며 키 내부의 빈 줄은 점 하나로 표기합니다.
• Enabled: no은 소스를 삭제하지 않고 비활성화합니다. 이는 이름을 변경하는 것보다 되돌리기 쉽고 다음 관리자에게 설명하기도 더 수월합니다.

타사 저장소의 경우 파일당 하나의 스탠자만 유지하고, 여러 스탠자를 함께 관리할 때는 스탠자 사이에 빈 줄을 넣으십시오. 저장소 인덱스는 아키텍처 목록에 amd64와 arm64를 포함하므로, ARM VPS에서 별도의 Architectures 필드는 필요하지 않습니다.

중간 프록시가 403 오류를 반환하는 경우

저장소의 경로가 존재하지 않으면 404 오류가 발생하므로, 403 오류는 다른 무언가가 대신 응답했음을 의미합니다. apt 설정에 프록시가 지정되어 있으면 대화형 curl 명령이 아닌 apt에만 적용되므로, 우선 apt 자체 설정을 확인하십시오.

grep -RIn -i proxy /etc/apt/apt.conf.d/ /etc/apt/apt.conf
sudo apt-config dump | grep -i 'acquire::http'

그다음 apt가 실제로 전송하는 내용을 확인하십시오.

sudo apt -o Debug::Acquire::http=1 update

이 명령은 요청 라인, apt가 보낸 헤더, 그리고 연결된 프록시가 있다면 해당 프록시 정보를 출력합니다. 동일한 URL에 대해 일반 curl 명령을 실행한 결과와 비교하십시오. curl은 200을 반환하는데 apt는 403을 반환한다면, 두 요청은 중간 장비가 중요하게 여기는 부분에서 차이가 있는 것이며, 일반적으로는 사용자 에이전트(user agent)가 원인입니다.

curl -sS -o /dev/null -w '%{http_code}\n' -A 'Debian APT-HTTP/1.3' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

위 명령이 403을 반환하고 기본 curl은 200을 반환한다면, 필터링 장비가 apt라는 이름 때문에 접근을 거부하는 것입니다. 이 경우 해결책은 서버가 아닌 해당 장비에서 찾아야 합니다. TLS를 검사하는 기업용 프록시는 다르게 동작합니다. apt가 수신한 인증서가 Tailscale의 인증 기관이 아닌 프록시에서 발급된 것이므로, 상태 코드 대신 인증서 검증 실패를 보고합니다. Ubuntu 미러만 허용하는 클라우드 송신(egress) 방화벽도 흔한 원인이며, 이 경우 방화벽에서 pkgs.tailscale.com를 허용하는 것이 해결책입니다.

IPv6 전용 송신(egress) 및 상태 코드가 아닌 오류

apt가 HTTP 응답을 전혀 받지 못한다면, 각 프로토콜을 개별적으로 테스트하십시오.

curl -4 -sS -o /dev/null -w 'v4 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease
curl -6 -sS -o /dev/null -w 'v6 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

IPv4는 응답하지만 IPv6에서 응답이 없거나 Network is unreachable 오류가 발생한다면, 리졸버 라이브러리가 IPv6를 우선시하는데 해당 서버에 정상적인 IPv6 경로가 없기 때문에 apt가 실패하는 것입니다. IPv4로 한 번 실행하여 이 가설을 확인하십시오.

sudo apt -o Acquire::ForceIPv4=true update

해당 업데이트가 성공한다면, 설정을 영구적으로 적용하십시오.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

반대의 경우도 명확히 인지해야 합니다. IPv4 주소가 전혀 없는 VPS에서는 IPv4를 강제해도 아무것도 해결되지 않습니다. 트래픽을 보낼 IPv4 경로 자체가 없기 때문입니다. 이 경우에는 제공업체에서 제공하는 NAT64와 DNS64를 사용하거나, IPv4 주소를 보유한 프록시를 사용해야 합니다. 이 경우 IPv6 주소를 가리키는 연결 오류가 발생하며, curl -6 줄이 그 원인을 정확히 알려줍니다.

대안과 각 방식의 비용

벤더 설치 스크립트. curl -fsSL https://tailscale.com/install.sh | sh는 Tailscale이 홍보하는 명령어입니다. 스크립트를 읽어보면 /etc/os-release에서 배포판을 감지한 뒤, 이 가이드에서 수정하고 있는 두 경로인 /usr/share/keyrings/tailscale-archive-keyring.gpg와 /etc/apt/sources.list.d/tailscale.list에 동일한 URL로부터 파일을 작성합니다. 이는 기대치와 관련하여 중요한 점입니다. 프록시가 차단 중인 저장소를 우회하지 못하기 때문입니다. 결과적으로 동일한 방식으로 실패하며 출력되는 정보는 더 적습니다. 다운로드한 스크립트를 root 권한으로 셸에 파이프(|)로 전달하는 것은 해결책이 아니라 거래입니다. 해당 시점에 서버가 반환하는 내용을 무조건 신뢰해야 하며, 실행된 코드의 사본을 보관하지 않기 때문입니다. 이 거래를 선택한다면, 위험을 인지하고 진행하십시오.

curl -fsSL https://tailscale.com/install.sh -o install.sh
less install.sh
sh install.sh

정적 바이너리. 동일한 서버가 pkgs.tailscale.com/stable의 정적 바이너리 섹션에 일반 tarball을 게시합니다. 2026년 8월 기준으로 안정화 릴리스는 1.102.2이며, 64비트 x86 파일은 tailscale_1.102.2_amd64.tgz입니다. 사용자가 직접 tailscale 클라이언트와 tailscaled 데몬을 배치하고 데몬을 직접 관리해야 하므로 apt upgrade 경로는 존재하지 않으며, 향후 모든 업데이트는 사용자가 직접 기억하고 다운로드해야 합니다. 이 방식은 인터넷이 차단된(air gapped) 호스트나 특정 버전을 고정해야 할 때 적합합니다.

Ubuntu 자체 패키지. 존재하지 않습니다. 벤더 저장소를 구성하지 않은 상태에서 sudo apt install tailscale을 실행하면 E: Unable to locate package tailscale에서 종료되며, apt update를 아무리 실행해도 결과는 바뀌지 않습니다. Tailscale이 호스팅하는 서버가 아닌 직접 제어하는 조정 서버를 원한다면 이는 별개의 결정입니다. 직접 제어 서버로 Headscale 운영하기에서 이를 다루며, Tailscale과 일반 WireGuard 비교에서 이러한 도구가 필요한지 여부를 다룹니다.

패키지는 설치되었으나 tailscaled가 시작되지 않는 경우

apt 작업이 성공적으로 완료된 후에도 데몬에서 오류가 발생할 수 있습니다.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

LXC나 OpenVZ와 같이 호스트 커널을 공유하는 컨테이너 가상화 환경의 VPS를 사용하는 경우, 로그에 /dev/net/tun이 존재하지 않는다는 내용이 기록됩니다. 데몬은 tailscale0 인터페이스를 생성하기 위해 TUN 장치가 필요하지만, 컨테이너에 해당 장치가 할당되지 않았기 때문입니다. 서비스 제공업체에 컨테이너의 TUN 활성화를 요청하거나, 자체 커널을 사용할 수 있는 KVM 플랜으로 전환하십시오. KVM 환경에서는 별도의 설정 없이 정상적으로 작동합니다.

그 후 sudo tailscale up를 실행하면 로그인 URL이 출력되며, tailscale status을 통해 100.64.0.0/10 범위의 주소를 가진 장치 목록을 확인할 수 있습니다. 목록에 장치가 나타나면 해당 장치를 기반으로 VPS에서 사설 서브넷을 광고하거나 VPS를 엑시트 노드로 사용하는 등의 작업을 수행할 수 있습니다.

FAQ

apt가 Tailscale 저장소가 서명되지 않았다고 하는 이유는 무엇입니까?

apt가 저장소 인덱스를 다운로드했으나 /usr/share/keyrings/tailscale-archive-keyring.gpg을(를) 통해 서명을 확인할 수 없기 때문입니다. 일반적으로 키링 파일의 크기가 0바이트인 경우가 원인입니다. sudo tee이(가) 파일을 잘라냈고, tee이(가) 성공하면서 파이프라인이 성공으로 보고되었기 때문입니다. gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg을(를) 실행하십시오. 정상적인 키링은 pub 줄과 Tailscale이 명시된 uid 줄을 출력하지만, 비어 있거나 손상된 키링은 gpg: no valid OpenPGP data found.을(를) 출력합니다. 키를 임시 파일로 다운로드하여 확인한 뒤, _apt 사용자가 읽을 수 있도록 0644 모드로 복사하십시오.

Tailscale URL에는 어떤 Ubuntu 코드네임을 넣어야 합니까?

/etc/os-release의 UBUNTU_CODENAME 값을 사용하십시오. Ubuntu 24.04에서는 noble이며, Ubuntu 26.04에서는 resolute입니다. Ubuntu 기반 배포판에서 lsb_release -cs을(를) 사용하지 마십시오. Linux Mint 22에서는 wilma을(를) 출력하는데, Tailscale은 해당 이름으로 게시하는 내용이 없으므로 apt는 dists/wilma/InRelease에서 404 오류를 보고합니다. 설정을 편집하기 전에 https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease을(를) 대상으로 curl -sS -o /dev/null -w '%{http_code}\n'을(를) 실행하여 인덱스를 직접 가져와 선택한 값이 올바른지 확인하십시오.

Tailscale 설치 스크립트를 셸로 파이프하여 실행해도 안전합니까?

이는 신중하게 결정해야 할 선택입니다. 해당 스크립트는 Tailscale에서 제공하며 수동 설치 단계와 동일한 작업을 수행합니다. 즉, /etc/os-release을(를) 읽고, 동일한 키링과 /etc/apt/sources.list.d/tailscale.list을(를) 작성한 뒤 패키지를 설치합니다. 단점은 서버가 해당 시점에 반환하는 내용을 root 권한으로 실행하게 되며, 실행 기록이 남지 않는다는 점입니다. -o install.sh을(를) 사용하여 스크립트를 다운로드하고 내용을 읽은 뒤 실행하면, 맹목적인 실행 없이 편리함을 누릴 수 있습니다. 또한 이미 실패한 URL을 사용하므로 저장소가 차단된 경우에는 이 방법으로도 해결할 수 없습니다.

apt 저장소 없이 Ubuntu에 Tailscale을 어떻게 설치합니까?

pkgs.tailscale.com에 게시된 정적 tarball을 사용하십시오. 2026년 8월 기준 버전은 1.102.2이며, amd64 파일 이름은 tailscale_1.102.2_amd64.tgz입니다. tailscale 및 tailscaled 프로그램을 직접 설치하고 systemd를 통해 데몬을 직접 실행해야 합니다. 단점은 업그레이드입니다. 새 버전을 가져올 apt 패키지가 없으므로 모든 업데이트를 수동으로 수행해야 합니다. Ubuntu 아카이브에는 자체적인 tailscale 패키지가 포함되어 있지 않으므로, 벤더 저장소가 없는 시스템에서 sudo apt install tailscale을(를) 실행하면 E: Unable to locate package tailscale에서 중단됩니다.