가이드

작성자 Matt Connor 2026-09-16

Tailscale 사용법: Ubuntu VPS에 첫 테일넷 만들기

Q: VPS에 tailscale up을 실행했는데 브라우저가 없습니다. 어떻게 로그인하나요?

sudo tailscale up이 출력하는 https://login.tailscale.com/a/... 주소를 노트북 브라우저에 붙여 넣고 로그인하면 됩니다. 승인이 끝나면 VPS 터미널에 Success.가 찍힙니다. URL은 한 번만 쓸 수 있고 시간이 지나면 만료되므로, 만료됐다면 명령을 다시 실행해 새 URL을 받으세요.

Q: tailscale ping이 계속 DERP로만 나옵니다. VPS 설정이 잘못된 건가요?

대부분 노트북이 있는 망 때문이고, VPS 설정 때문인 경우는 드뭅니다. 노트북에서 tailscale netcheck를 실행해 UDP:가 false이면 그 망이 UDP를 막는 것이고, MappingVariesByDestIP: true이면 NAT 종류가 직접 연결을 어렵게 만드는 것입니다. VPS 쪽에서는 sudo ufw allow 41641/udp로 UDP 41641이 열려 있는지만 확인하면 됩니다.

Ubuntu 24.04 VPS와 노트북에 Tailscale을 설치하고 tailscale up으로 첫 테일넷을 만든 뒤, 100.x 주소와 MagicDNS 이름으로 SSH 접속하고 ufw에서 공인 IP의 22번 포트를 닫는 순서까지 그대로 따라 합니다.

Tailscale 사용법: 순서대로 세 단계

Tailscale 사용법은 세 단계로 끝납니다. VPS와 노트북에 각각 Tailscale을 설치하고, 두 기기에서 같은 계정으로 sudo tailscale up을 실행하고, 노트북에서 VPS의 100.x.y.z 주소나 MagicDNS 이름으로 SSH 접속하면 됩니다. 공유기 포트 포워딩도, 방화벽에 새로 낼 구멍도 없습니다. 아래에서는 그 순서를 터미널을 열어 둔 채로 그대로 따라 합니다. 마지막에는 테일넷 접속이 확인된 뒤에 공인 IP의 22번 포트를 ufw에서 닫아, SSH가 테일넷 안에서만 열리게 만듭니다.

Tailscale이 무엇인지, WireGuard와 어떻게 다른지는 Tailscale이 무엇이고 어떻게 동작하는지 설명한 글에서 다뤘습니다. 여기서는 설명을 반복하지 않고 바로 만듭니다. 명령은 Ubuntu 24.04 VPS 기준입니다.

VPS를 첫 노드로 고르는 데는 이유가 있습니다. Tailscale은 두 기기 사이에 WireGuard 터널을 직접 뚫으려고 시도합니다. 노트북은 집의 iptime 같은 공유기 뒤에, 카페 와이파이 뒤에, 또는 휴대폰 테더링의 통신사 NAT(network address translation) 뒤에 있어서 밖에서 먼저 찾아 들어가기 어렵습니다. VPS는 공인 IP를 갖고 항상 켜져 있으므로, 노트북이 어디에 있든 VPS 쪽으로는 패킷이 곧장 도달합니다. 그래서 VPS가 테일넷에서 가장 연결이 쉬운 노드가 됩니다.

먼저 로그인 계정 정하기: 카카오와 네이버는 안 됩니다

Tailscale에는 이메일 가입이 없고, Tailscale 비밀번호도 없습니다. Tailscale은 스스로 ID 제공자(identity provider)가 되지 않기로 설계됐기 때문에, 로그인은 언제나 다른 서비스의 계정을 빌려서 합니다. 2026년 9월 16일 기준으로 Tailscale 공식 문서(tailscale.com/kb/1013)가 나열하는 방법은 Google, Microsoft, GitHub, Apple, Okta, OneLogin, 직접 설정하는 OIDC(OpenID Connect) 제공자, 그리고 패스키입니다.

카카오 계정과 네이버 계정은 이 목록에 없습니다. 커스텀 OIDC는 조직용 테일넷에 관리자가 직접 등록하는 방식이라, 개인 사용자가 첫 로그인에 쓰는 경로가 아닙니다. 개인 VPS 하나를 연결하는 용도라면 Google 계정이나 GitHub 계정으로 시작하는 것이 가장 짧은 길입니다. 어느 계정으로 시작했는지 기억해 두세요. 이후 노트북에서도, 휴대폰에서도 같은 계정으로 로그인해야 같은 테일넷에 들어옵니다.

요금은 걱정할 필요가 없습니다. Personal 플랜은 VPS 한 대와 노트북 한 대를 연결하는 규모에서는 무료이고, 어디까지가 무료인지는 Tailscale 무료 플랜의 한도를 정리한 글에 있습니다.

VPS에 Tailscale 설치하기 (Ubuntu 24.04)

Ubuntu 기본 저장소에는 Tailscale 패키지가 없습니다. Tailscale이 직접 운영하는 apt 저장소 pkgs.tailscale.com을 추가하고 거기서 설치합니다. 아래 네 줄은 Tailscale의 Ubuntu 24.04 설치 안내 페이지에 있는 것과 같습니다. VPS에 SSH로 들어간 뒤 그대로 실행하세요.

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 -y tailscale

첫 줄은 저장소 서명 키를 둘 디렉터리를 만듭니다. 둘째 줄은 Tailscale의 GPG 키를 받아 그 디렉터리에 저장합니다. 셋째 줄은 noble(Ubuntu 24.04의 코드명) 전용 저장소 정의를 /etc/apt/sources.list.d/tailscale.list에 씁니다. 이 파일은 signed-by=로 둘째 줄의 키를 가리키므로, 그 키로 서명되지 않은 패키지는 apt가 거부합니다. 넷째 줄이 실제 설치입니다.

한 줄짜리 설치 스크립트 curl -fsSL https://tailscale.com/install.sh | sh도 있습니다. 이 스크립트는 배포판을 알아낸 뒤 위와 똑같은 저장소 설정과 apt-get install을 대신 해 줍니다. 결과는 같으므로 어느 쪽을 써도 됩니다. 네 줄을 직접 치는 쪽을 먼저 보여 준 이유는, 저장소가 어느 파일에 추가됐는지 알아야 나중에 apt 오류가 났을 때 어디를 볼지 알 수 있기 때문입니다.

설치가 끝나면 데몬이 떠 있는지 확인합니다.

tailscale version
systemctl status tailscaled --no-pager

tailscale version은 버전 번호를 찍습니다. systemctl status tailscaled는 Active: active (running)이어야 합니다. 패키지가 설치되면서 tailscaled 서비스를 자동으로 활성화하므로, 재부팅 뒤에도 따로 켤 필요가 없습니다. apt-get update에서 NO_PUBKEY나 does not have a Release file 같은 오류가 나면 둘째 줄이나 셋째 줄이 제대로 실행되지 않은 것입니다. 이런 설치 오류의 원인과 해결은 Ubuntu에서 Tailscale 설치 오류를 고치는 글에 모아 두었으니, 여기서는 넘어갑니다.

노트북에 Tailscale 설치하기

노트북이 Linux라면 VPS와 같은 방법입니다. Ubuntu 24.04 노트북은 위의 네 줄을 그대로 쓰고, 다른 배포판은 curl -fsSL https://tailscale.com/install.sh | sh 한 줄이면 됩니다. macOS와 Windows는 tailscale.com/download에서 설치 파일을 받아 실행하고, 메뉴 막대 또는 트레이 아이콘에서 로그인합니다. Windows는 설치 후 PowerShell에서 tailscale 명령을 바로 쓸 수 있습니다. macOS의 App Store 버전은 CLI가 /Applications/Tailscale.app/Contents/MacOS/Tailscale 경로에 있으므로, 이 경로를 tailscale이라는 별칭(alias)으로 잡아 두면 아래 명령을 그대로 쓸 수 있습니다.

순서는 VPS 먼저, 노트북 다음입니다. VPS를 먼저 테일넷에 넣어 두면 노트북이 로그인하는 순간 tailscale status에 VPS가 나타나므로, 어느 단계에서 문제가 생겼는지 바로 알 수 있습니다.

tailscale up: 첫 테일넷 만들기

VPS에서 실행합니다.

sudo tailscale up

VPS에는 브라우저가 없으므로, 명령이 로그인 URL을 출력하고 기다립니다.

To authenticate, visit:

	https://login.tailscale.com/a/1a2b3c4d5e6f7

이 URL을 노트북의 브라우저에 붙여 넣고, 앞에서 정한 계정으로 로그인합니다. 처음 로그인하는 계정이면 이 순간 테일넷이 만들어지고, VPS가 첫 번째 기기로 등록됩니다. 브라우저에서 승인이 끝나면 VPS 터미널에 Success.가 찍히고 프롬프트가 돌아옵니다. URL은 한 번만 쓸 수 있고 시간이 지나면 만료되므로, 만료됐다면 sudo tailscale up을 다시 실행해 새 URL을 받으면 됩니다.

이제 노트북에서 같은 계정으로 로그인합니다. Linux 노트북은 sudo tailscale up을 실행하면 같은 형식의 URL이 나오고, macOS와 Windows는 앱의 로그인 버튼이 브라우저를 엽니다. 두 기기가 같은 테일넷에 들어왔는지 VPS에서 확인합니다.

tailscale status
tailscale ip -4

tailscale status는 테일넷의 모든 기기를 한 줄씩 보여 줍니다.

100.101.102.103 my-vps       user@  linux   -
100.104.105.106 my-laptop    user@  macOS   -

첫 열이 각 기기의 테일넷 주소입니다. 100.64.0.0/10 범위의 주소이고, 기기가 테일넷에 남아 있는 한 바뀌지 않습니다. 둘째 열은 기기 이름, 셋째 열은 로그인한 계정, 넷째 열은 운영체제입니다. 마지막 열은 지금의 연결 상태인데, 아직 서로 통신한 적이 없으면 -입니다. tailscale ip -4는 이 VPS의 IPv4 테일넷 주소 한 줄만 찍으므로 스크립트에서 쓰기 좋습니다.

기기 이름은 기본적으로 호스트명입니다. VPS의 호스트명이 ubuntu처럼 흔한 이름이면 노트북과 겹칠 수 있고, 그러면 Tailscale이 나중에 들어온 기기에 ubuntu-1처럼 숫자를 붙입니다. 알아보기 쉬운 이름을 주려면 VPS에서 바꾸면 됩니다.

sudo tailscale set --hostname=my-vps

이 이름이 곧 다음 절에서 쓰는 MagicDNS 이름이 됩니다.

100.x 주소와 MagicDNS 이름으로 VPS에 SSH 접속하기

노트북 터미널에서 VPS의 테일넷 주소로 SSH 접속합니다. 계정 이름은 평소 VPS에 들어갈 때 쓰던 것과 같습니다.

ssh ubuntu@100.101.102.103

처음 접속이면 호스트 키 확인 질문이 나옵니다. 공인 IP로 접속할 때와 주소가 다르므로 known_hosts에는 새 항목으로 저장됩니다. 로그인이 되면 VPS 안에서 who를 실행해 보세요. 접속 출발지가 노트북의 테일넷 주소 100.104.105.106으로 보이면, 이 SSH 세션은 WireGuard 터널을 지나온 것입니다. 공인 IP는 거치지 않았습니다.

주소 대신 이름으로도 접속됩니다. MagicDNS는 테일넷의 각 기기 이름을 DNS 이름으로 만들어 주는 기능이고, 새로 만든 테일넷에는 기본으로 켜져 있습니다.

ssh ubuntu@my-vps
ssh ubuntu@my-vps.tail1234.ts.net

짧은 이름 my-vps는 Tailscale이 노트북의 DNS 설정에 끼워 넣은 검색 도메인 덕분에 풀립니다. 긴 이름은 <기기 이름>.<테일넷 이름>.ts.net 형식이고, 테일넷 이름은 관리 콘솔의 DNS 탭에서 볼 수 있습니다. ssh: Could not resolve hostname my-vps가 나오면 관리 콘솔 DNS 탭에서 MagicDNS가 꺼져 있거나, 노트북의 리졸버가 Tailscale의 DNS 설정을 받지 않은 것입니다. 이때 100.x 주소로는 접속이 되는지 먼저 확인하면, 터널 문제인지 DNS 문제인지가 갈립니다. 여기까지 되면 첫 테일넷은 완성입니다. 이 뒤로는 이 연결을 더 빠르고 더 안전하게 만드는 일입니다.

연결이 직접인지 릴레이인지: tailscale netcheck 읽는 법

Tailscale은 두 기기를 가능하면 직접 연결하고, 안 되면 DERP라는 Tailscale의 릴레이 서버를 거쳐 연결합니다. 직접 연결이면 지연이 낮고, 릴레이면 두 기기 사이에 서버가 하나 더 끼므로 느립니다. 어느 쪽인지 노트북에서 확인합니다.

tailscale ping 100.101.102.103
tailscale status

tailscale ping은 Tailscale 계층의 핑이고, ICMP ping과는 다릅니다. 처음 몇 번은 릴레이를 거치다가 직접 경로가 잡히면 아래처럼 바뀝니다.

pong from my-vps (100.101.102.103) via 203.0.113.10:41641 in 38ms

via 뒤에 VPS의 공인 IP와 포트가 보이면 직접 연결입니다. via DERP(xxx)처럼 지역 코드가 보이면 릴레이입니다. 여러 번 시도해도 계속 DERP로만 나오면 tailscale status의 마지막 열에도 relay "xxx"가 표시됩니다. 직접 연결이면 그 자리에 direct 203.0.113.10:41641이 나옵니다.

왜 릴레이가 되는지는 tailscale netcheck가 알려 줍니다. 노트북에서 실행하세요.

tailscale netcheck

출력은 여러 줄의 보고서입니다. 읽을 줄은 넷입니다. UDP: true는 이 네트워크에서 UDP가 나가고 들어온다는 뜻입니다. false이면 지금 있는 와이파이나 회사망이 UDP를 막고 있는 것이고, WireGuard는 UDP 위에서만 동작하므로 이 경우 직접 연결은 불가능하고 항상 릴레이가 됩니다. IPv4: yes, <주소>:<포트>는 밖에서 보이는 내 공인 주소와 포트입니다. MappingVariesByDestIP: true이면 공유기나 통신사 NAT가 목적지마다 다른 포트를 배정하는 종류라서 직접 연결을 뚫기 어렵습니다. Nearest DERP:와 그 아래 DERP latency: 목록은 어느 릴레이 지역이 가장 가깝고 각 지역까지 지연이 몇 ms인지입니다. 이 값은 노트북이 어느 통신사, 어느 망에 있느냐에 따라 달라지므로 직접 실행해서 읽는 것이 맞습니다.

결론은 하나입니다. VPS 쪽은 공인 IP가 있어서 대체로 문제가 없고, 릴레이로 떨어지는 원인은 거의 항상 노트북이 있는 망입니다. 계속 릴레이로만 연결되고 그 이유와 대처가 필요하면 Tailscale이 직접 연결 대신 릴레이를 타는 이유와 고치는 방법을 보세요. 여기서 다시 설명하지는 않습니다.

VPS를 항상 켜진 노드로 다듬기

VPS는 한 번 설정하면 몇 달씩 손대지 않는 기기입니다. 그 조건에서 두 가지를 미리 해 두면 나중에 갑자기 끊기는 일을 막을 수 있습니다.

첫째, 키 만료를 끕니다. Tailscale은 기기의 노드 키를 기본 180일마다 만료시키고, 만료되면 그 기기에서 다시 브라우저 로그인을 해야 합니다. 노트북에서는 자연스러운 일이지만, VPS는 만료되는 순간 테일넷에서 사라지고, 공인 IP의 22번 포트를 이미 닫아 두었다면 들어갈 길이 없어집니다. 관리 콘솔의 Machines 탭에서 VPS 항목의 메뉴를 열고 Disable key expiry를 선택하세요. 기기 상세 화면의 Key expiry 항목이 disabled로 바뀌면 된 것입니다.

둘째, UDP 41641을 방화벽에서 엽니다. Tailscale은 WireGuard 트래픽에 UDP 41641 포트를 씁니다. VPS의 ufw가 들어오는 UDP를 기본으로 막고 있으면, 노트북이 VPS로 먼저 보낸 패킷은 버려지고 VPS가 노트북 쪽으로 보낸 패킷의 응답만 통과합니다. 대부분은 그래도 직접 연결이 잡히지만, 노트북 쪽 NAT가 까다로운 종류일 때는 이 한 줄이 직접 연결과 릴레이를 가릅니다.

sudo ufw allow 41641/udp

VPS가 공인 IP를 갖고 이 포트를 열어 두면, 노트북이 어떤 NAT 뒤에 있든 노트북에서 VPS로 보내는 첫 패킷이 도달합니다. VPS가 연결이 쉬운 노드인 이유가 정확히 이것입니다. 열어 두어도 이 포트는 WireGuard 키로 인증되지 않은 패킷에 응답하지 않으므로, 포트 스캔에 드러나는 서비스가 하나 늘어나는 것은 아닙니다.

SSH를 테일넷으로만 열기: ufw에서 공인 IP의 22번 포트 닫기

여기까지 오면 VPS에 들어가는 길이 둘입니다. 공인 IP의 22번 포트와 테일넷 주소의 22번 포트입니다. 공인 쪽을 닫으면 인터넷 전체에서 오던 SSH 무차별 대입 시도가 그 자리에서 사라집니다. 순서를 지키면 스스로를 잠글 일이 없습니다.

먼저 노트북에서 테일넷 주소로 접속한 SSH 세션을 하나 열어 두고, 그 세션은 끝날 때까지 닫지 마세요. 이 세션 안에서 아래 명령을 실행합니다. 현재 규칙부터 확인합니다.

sudo ufw status numbered

일반적인 VPS라면 이런 모양입니다.

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 41641/udp                  ALLOW IN    Anywhere
[ 3] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 4] 41641/udp (v6)             ALLOW IN    Anywhere (v6)

22/tcp 대신 OpenSSH라는 앱 프로필 이름이 보일 수도 있습니다. 같은 것입니다. Status: inactive라면 ufw가 꺼져 있는 것이고, 그 경우는 이 절의 끝에서 따로 다룹니다. 이제 tailscale0 인터페이스로 들어오는 22번만 허용하는 규칙을 먼저 추가합니다.

sudo ufw allow in on tailscale0 to any port 22 proto tcp

tailscale0은 tailscaled가 만드는 가상 네트워크 인터페이스입니다. ip addr show tailscale0으로 보면 100.101.102.103/32 주소가 붙어 있습니다. 테일넷에서 오는 패킷은 이 인터페이스로 들어오고, 공인 IP로 오는 패킷은 eth0이나 enp1s0 같은 실제 인터페이스로 들어옵니다. in on tailscale0 조건이 그 둘을 가릅니다.

이제 공인 규칙을 지웁니다.

sudo ufw delete allow 22/tcp
sudo ufw status numbered

앱 프로필을 썼다면 sudo ufw delete allow OpenSSH입니다. 번호로 지울 수도 있는데, 하나를 지우면 번호가 다시 매겨지므로 번호로 지울 때는 sudo ufw status numbered를 매번 다시 보고 지우세요. 결과에 22/tcp on tailscale0만 남고 Anywhere에서 오는 22/tcp가 사라졌으면 됩니다.

확인 차례입니다. 열어 둔 세션은 그대로 두고, 노트북에서 새 터미널을 열어 테일넷 주소로 다시 접속합니다. 되어야 합니다. 그다음 공인 IP로 접속을 시도합니다.

ssh -o ConnectTimeout=5 ubuntu@203.0.113.10

이 명령은 5초 뒤에 ssh: connect to host 203.0.113.10 port 22: Connection timed out으로 끝나야 합니다. timed out으로 끝나는 이유는 ufw가 막은 패킷에 답을 보내지 않고 조용히 버리기 때문입니다. 포트가 열려 있는데 서비스만 없을 때 나오는 Connection refused와는 다릅니다. 스캐너 입장에서는 22번 포트가 있는지조차 알 수 없습니다.

ufw가 inactive였다면 순서가 조금 다릅니다. tailscale0 규칙과 41641/udp 규칙을 먼저 추가한 뒤 sudo ufw enable을 실행하면, ufw의 기본 정책인 들어오는 연결 차단이 켜지면서 공인 22번은 저절로 닫힙니다. 이때도 테일넷 SSH 세션을 열어 둔 채로 실행하고, enable 직후 새 테일넷 접속이 되는지 확인하세요.

한 가지를 기억해 두세요. 이제 VPS에 들어가는 유일한 길은 테일넷입니다. tailscaled가 죽거나 키가 만료되면 들어갈 수 없습니다. 앞 절에서 키 만료를 끈 이유가 이것입니다. 그래도 불안하면 VPS 제공사의 웹 콘솔(브라우저에서 여는 가상 터미널)이 마지막 비상구입니다. 그 콘솔에서 sudo ufw allow 22/tcp를 치면 원래대로 돌아옵니다. SSH 자체를 한 번 정리해 두고 싶다면 SSH가 무엇이고 키 인증이 어떻게 동작하는지도 같이 읽어 두면 좋습니다.

자주 만나는 문제와 확인 방법

tailscale status가 Logged out.만 찍는다. tailscale up이 출력한 URL에서 로그인을 끝내지 않은 상태입니다. sudo tailscale up을 다시 실행해 새 URL을 받고 브라우저에서 승인하세요.

tailscale 명령이 failed to connect to local tailscaled로 시작하는 오류를 낸다. 데몬이 떠 있지 않습니다. 오래된 버전은 같은 상황에서 tailscaled.sock: connect: no such file or directory를 찍습니다. sudo systemctl start tailscaled로 올리고 systemctl status tailscaled에서 active (running)을 확인하세요. 설치 직후에 이 오류가 나면 패키지 설치가 중간에 실패한 것이니, apt-get install 출력의 오류를 다시 읽어야 합니다.

노트북의 tailscale status에 VPS가 안 보인다. 두 기기가 다른 계정으로 로그인했을 가능성이 가장 큽니다. Google로 시작했는데 노트북은 GitHub로 로그인하면, 같은 사람이어도 Tailscale에게는 다른 테일넷입니다. 관리 콘솔의 Machines 탭에서 두 기기가 모두 보이는지 확인하세요. 하나만 보이면 다른 하나는 다른 테일넷에 있습니다. 그쪽에서 sudo tailscale logout을 실행한 뒤 올바른 계정으로 sudo tailscale up을 다시 하면 됩니다.

테일넷 주소로 SSH는 안 되는데 tailscale ping은 된다. 터널은 정상이고 VPS의 sshd나 방화벽 문제입니다. ufw에 22/tcp on tailscale0 규칙이 있는지, sshd가 모든 주소에서 듣고 있는지 sudo ss -tlnp | grep :22로 확인하세요. ListenAddress를 공인 IP 하나로 고정해 둔 서버라면 테일넷 주소로 오는 접속은 sshd가 받지 않습니다.

다음 단계

첫 테일넷이 만들어졌으니 이 VPS를 더 쓸 길이 몇 가지 열립니다. 여기서는 다루지 않고 각각 따로 정리했습니다. 카페 와이파이에서 VPS를 통해 인터넷에 나가고 싶다면 VPS를 Tailscale 출구 노드로 만드는 방법을 보세요. VPS와 같은 사설망에 있는 다른 서버를 테일넷에 넣지 않고도 노트북에서 닿게 하려면 VPS를 서브넷 라우터로 쓰는 방법입니다. VPS 위의 Docker 컨테이너를 테일넷에 붙이는 방법은 Docker Compose 안에서 Tailscale을 돌리는 글에 있습니다. 집에 있는 NAS나 휴대폰까지 넣어 공유기 포트 포워딩을 없애는 이야기는 포트 포워딩 대신 Tailscale을 쓰는 글에서 다룹니다.

FAQ

Tailscale은 카카오나 네이버 계정으로 로그인할 수 있나요?

없습니다. Tailscale은 이메일 가입과 자체 비밀번호가 없고, 로그인은 Google, Microsoft, GitHub, Apple, Okta, OneLogin, 직접 등록한 OIDC 제공자, 패스키 중 하나로만 합니다(2026년 9월 16일 기준). 개인 VPS 용도라면 Google 계정이나 GitHub 계정으로 시작하고, 이후 모든 기기를 같은 계정으로 로그인하면 됩니다.

VPS에 tailscale up을 실행했는데 브라우저가 없습니다. 어떻게 로그인하나요?

sudo tailscale up이 출력하는 https://login.tailscale.com/a/... 주소를 노트북 브라우저에 붙여 넣고 로그인하면 됩니다. 승인이 끝나면 VPS 터미널에 Success.가 찍힙니다. URL은 한 번만 쓸 수 있고 시간이 지나면 만료되므로, 만료됐다면 명령을 다시 실행해 새 URL을 받으세요.

공인 IP의 22번 포트를 닫으면 Tailscale이 죽었을 때 VPS에 못 들어가지 않나요?

맞습니다. 그래서 두 가지를 먼저 해 둡니다. 관리 콘솔에서 VPS의 키 만료를 끄고, 공인 규칙을 지우기 전에 테일넷 SSH 세션을 열어 둔 채로 새 규칙이 통하는지 확인합니다. 그래도 들어갈 수 없게 되면 VPS 제공사의 웹 콘솔에서 sudo ufw allow 22/tcp를 실행해 공인 접속을 다시 열 수 있습니다.

tailscale ping이 계속 DERP로만 나옵니다. VPS 설정이 잘못된 건가요?

대부분 노트북이 있는 망 때문이고, VPS 설정 때문인 경우는 드뭅니다. 노트북에서 tailscale netcheck를 실행해 UDP:가 false이면 그 망이 UDP를 막는 것이고, MappingVariesByDestIP: true이면 NAT 종류가 직접 연결을 어렵게 만드는 것입니다. VPS 쪽에서는 sudo ufw allow 41641/udp로 UDP 41641이 열려 있는지만 확인하면 됩니다.

#tailscale #wireguard #vpn #ssh #remote-access #ubuntu