Tailscale 서브넷 라우터 설정 및 VPS 라우팅 가이드

Tailscale 서브넷 라우터의 역할

Tailscale 서브넷 라우터는 특정 사설 IP 대역 전체를 tailnet에 광고하는 장비입니다. 이를 통해 Tailscale이 설치되지 않은 장비라도 tailnet 내의 모든 기기에서 해당 대역의 주소로 접근할 수 있습니다. tailnet은 동일한 계정이나 조직으로 로그인한 기기들로 구성된 개인용 Tailscale 네트워크를 의미합니다. 사용자들이 흔히 혼동하는 기능인 exit node는 이와 정반대의 역할을 수행합니다. exit node는 기기의 모든 트래픽을 VPS를 거쳐 외부로 내보내며, 결과적으로 해당 VPS가 기기의 공용 인터넷 경로가 됩니다.

각 기능을 한 문장으로 설명합니다. 서브넷 라우터는 하나의 사설 네트워크를 tailnet에서 접근할 수 있도록 만듭니다. exit node는 공용 트래픽이 나가는 경로를 변경합니다. 만약 exit node 기능이 필요한 경우, Tailscale exit node를 VPS에서 실행하는 방법을 대신 읽어보시기 바랍니다. 두 기능은 서로 다른 플래그를 사용하며, 하나의 VPS가 두 기능을 동시에 수행할 수도 있지만, 해결하는 문제와 발생할 수 있는 오류의 유형이 서로 다릅니다.

VPS에 서브넷 라우터가 필요한 경우

일반적인 사례는 서비스 제공업체로부터 이미 할당받은 사설 네트워크를 사용하는 경우입니다. VPS는 공인 IP 주소와 사설 대역의 두 번째 인터페이스를 가지며, 해당 대역의 다른 서버들은 공인 IP 주소가 전혀 없습니다. 예를 들어 10.0.0.20에 데이터베이스가 있고 10.0.0.30에 백업 대상이 있는 경우입니다. VPS 중 하나에 Tailscale을 설치하고 10.0.0.0/24를 광고(advertise)하면, 사용자의 노트북에서 해당 사설 IP 주소로 직접 접근할 수 있습니다. 네트워크 세그먼트의 다른 설정은 변경할 필요가 없으며, 데이터베이스는 여전히 공인 IP 주소를 갖지 않습니다.

다른 사례는 VPS 너머의 네트워크를 사용하는 경우입니다. 자체 라우터 뒤에 있는 가정용 또는 사무실용 LAN(Local Area Network)이나, 관리형 스위치 또는 펌웨어가 잠겨 있어 Tailscale을 전혀 실행할 수 없는 구형 NAS와 같은 장비들이 이에 해당합니다. 해당 네트워크의 Linux 장비 한 대가 그 안의 모든 장치를 위한 서브넷 라우터 역할을 수행하게 됩니다.

두 사례 모두 한 가지 공통된 요구 사항이 있습니다. 서브넷 라우터는 자체 라우팅 테이블과 방화벽을 사용하여 광고하려는 대역에 이미 도달할 수 있어야 합니다. Tailscale은 해당 연결을 직접 생성하지 않습니다. Tailscale은 트래픽을 라우터까지 전달하고, 이를 커널에 넘겨 포워딩하도록 합니다.

Tailscale을 설치하고 로컬 경로를 먼저 확인합니다

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

스크립트는 배포판을 감지하고 Tailscale 패키지 저장소를 추가한 뒤, tailscale 명령어와 tailscaled 데몬을 설치하고 서비스를 활성화합니다. systemctl is-active tailscaled 명령어로 이를 확인하면 active가 출력되어야 합니다.

다른 작업을 수행하기 전에, VPS가 광고하려는 네트워크에 도달할 수 있는지 먼저 확인하십시오.

ip route show
ping -c3 10.0.0.20

ip route show 명령어를 실행하면 실제 인터페이스에서 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5와 같은 사설 대역이 나열되어야 합니다. 여기서 라우터 자체에 대한 ping이 실패한다면, 어떤 Tailscale 플래그를 사용해도 해결되지 않습니다. 문제는 VPS 네트워크 설정이나 대상 호스트의 방화벽에 있습니다. 이후의 모든 테스트는 이 연결 상태에 의존하므로, 이 문제를 먼저 해결하십시오.

IP 포워딩 활성화 및 재부팅 후 유지 설정

Linux 시스템은 포워딩이 활성화되지 않은 경우 자신을 목적지로 하지 않는 모든 패킷을 폐기합니다. 다른 시스템의 패킷을 전달하는 것은 서브넷 라우터의 핵심 역할이므로, 이 단계는 필수적입니다.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

sysctl net.ipv4.ip_forward 명령으로 설정을 확인하십시오. 결과값으로 net.ipv4.ip_forward = 1이 출력되어야 합니다.

이 단계에서 설정을 절반만 완료하는 경우가 많습니다. sudo sysctl -w net.ipv4.ip_forward=1 명령은 즉시 적용되지만 재부팅 시 초기화되므로, 서브넷 라우터가 수주간 정상 작동하다가 커널 업데이트 후 재부팅된 다음 날 아침에 갑자기 중단되는 상황이 발생합니다. 혼란스러운 점은 겉으로 보기에 아무런 문제가 없어 보인다는 것입니다. tailscale status 명령은 여전히 노드가 온라인 상태임을 보여주고, 관리 콘솔은 경로가 승인된 것으로 표시하며, 클라이언트에도 경로는 설치되어 있습니다. 패킷은 VPS에 도달하지만 커널이 아무런 로그도 남기지 않고 이를 폐기합니다. /etc/sysctl.d/99-tailscale.conf 파일에 값을 기록해야만 재부팅 후에도 설정이 유지됩니다.

포워딩이 꺼진 상태에서 경로를 광고하면 tailscale up 명령이 실행 시점에 Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.과 유사한 문구로 경고를 표시합니다. 해당 명령의 출력을 무시하고 지나치지 말고 반드시 읽어보십시오.

경로 광고하기

sudo tailscale up --advertise-routes=10.0.0.0/24

이미 tailnet에 로그인된 VPS에서는 설정을 직접 변경하십시오:

sudo tailscale set --advertise-routes=10.0.0.0/24

이후 모든 변경 사항에는 tailscale set를 사용하십시오. 단일 플래그와 함께 tailscale up을 다시 실행하면 반복하지 않은 플래그가 초기화됩니다. 이 방식으로 설정을 변경할 때 기본값이 아닌 모든 플래그를 명시해야 한다는 오류 메시지가 CLI에 표시됩니다. tailscale set은 하나의 설정만 변경하고 나머지는 그대로 유지합니다.

여러 대역을 쉼표로 구분하여 공백 없이 하나의 목록으로 입력하십시오: --advertise-routes=10.0.0.0/24,192.168.50.0/24. 각 항목은 CIDR 표기법(classless inter-domain routing, 10.0.0.0/24 형식)을 따르는 네트워크 주소여야 합니다. 실수로 호스트 주소를 직접 입력하면(예: 10.0.0.5/24) 접두사 뒤의 비트가 0이 아니라는 이유로 거부되며, 오류 메시지에 의도했을 것으로 추정되는 접두사가 표시됩니다. 광고를 중단하려면 sudo tailscale set --advertise-routes=를 사용하여 빈 목록을 설정하십시오.

관리자 콘솔에서 경로 승인하기

경로를 광고하는 것은 요청일 뿐, 즉각적인 변경 사항이 아닙니다. 관리자가 승인하기 전까지는 어떤 클라이언트도 해당 경로를 수신하지 않으며, 해당 범위 내의 그 어떤 대상에도 접근할 수 없습니다. 이는 의도된 동작입니다. 임의의 기기가 모든 기기의 라우팅 테이블에 스스로를 추가할 수 있다면, 원하는 모든 범위의 트래픽을 가로챌 수 있기 때문입니다.

관리자 콘솔의 Machines 페이지에서 경로를 승인하십시오. 해당 VPS는 서브넷 배지와 함께 표시됩니다. 해당 행을 열고 subnets 섹션을 찾은 뒤, 경로 설정을 편집하여 해당 경로를 체크하고 저장하십시오.

승인은 프리픽스 단위로 이루어집니다. 오늘 10.0.0.0/24을 광고하고 다음 달에 192.168.50.0/24을 광고한다면, 기존 경로는 계속 작동하지만 새로운 프리픽스는 승인되지 않은 상태로 추가됩니다. VPS 입장에서는 승인된 경로와 무시된 경로가 동일하게 보이므로, 다른 문제를 디버깅하기 전에 콘솔을 먼저 확인하십시오.

tailnet 정책 파일에 autoApprovers 블록을 추가하면 수동 단계를 생략할 수 있습니다.

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

그런 다음 해당 태그인 sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router를 사용하여 노드를 시작하면, 경로가 광고되는 즉시 승인됩니다. 태그는 반드시 동일한 정책 파일의 tagOwners 섹션에 먼저 정의되어 있어야 합니다. 스크립트로 VPS를 재구축하는 경우 이 설정을 사용하는 것이 좋습니다. 재구축된 노드는 새로운 노드로 간주되어 경로가 다시 승인되지 않은 상태로 시작되기 때문입니다.

Linux 클라이언트가 --accept-routes 없이 경로를 무시하는 이유

경로가 광고되고 승인되었습니다. 이제 휴대폰과 Mac에서 10.0.0.20에 접근할 수 있습니다. 하지만 Linux 노트북은 접근할 수 없으며, 관리 콘솔에도 문제로 보이는 항목은 없습니다.

서브넷 경로를 수락한다는 것은 클라이언트의 라우팅 테이블에 항목을 기록한다는 의미입니다. Android, iOS, macOS, tvOS 및 Windows에서는 Tailscale 클라이언트가 이 작업을 자동으로 수행합니다. 그러나 Linux에서는 그렇지 않습니다. Linux 머신은 종종 누군가 의도적으로 라우팅 테이블을 구성한 서버나 라우터인 경우가 많기 때문입니다. 네트워크에서 학습한 /24를 자동으로 삽입하면 해당 머신이 이미 처리 중인 트래픽에 문제가 발생할 수 있습니다. 따라서 Linux에서는 각 클라이언트에서 다음과 같이 직접 선택해야 합니다.

sudo tailscale set --accept-routes

그런 다음 경로가 어디에 적용되었는지 확인합니다.

ip route show table 52
ip route get 10.0.0.20

Linux용 Tailscale은 수락된 경로를 메인 라우팅 테이블에 넣지 않습니다. 대신 라우팅 테이블 52에 넣고 정책 규칙을 설치합니다. 이는 ip rule show을 통해 우선순위 범위 5210에서 5270 사이에서 확인할 수 있으며, 일치하지 않는 패킷을 해당 테이블로 보냅니다. 따라서 ip route show만으로는 10.0.0.0/24를 절대 나열하지 않으며, 해당 명령어만 확인하는 사용자는 --accept-routes이 아무 작업도 하지 않았다고 결론 내릴 수 있습니다. ip route show table 52은 실제 상태를 보여주는 명령어이며, 여기서 광고된 범위를 tailscale0에서 확인할 수 있어야 합니다.

알아두어야 할 예외 사항이 하나 있습니다. 이 Linux 노드가 자체 로컬 네트워크를 위한 두 번째 서브넷 라우터인 경우, --accept-routes를 사용하면 자체 인터페이스가 아닌 다른 라우터를 통해 직접 연결된 서브넷의 트래픽을 보내게 됩니다. 고가용성 쌍으로 구성된 대기 라우터에서는 --accept-routes을 끄고 광고만 수행하십시오.

실패 모드: 두 라우터가 중첩된 대역을 광고하는 경우

두 서브넷 라우터가 동일한 대역을 광고해서는 안 됩니다. 접두사 길이가 다른 중첩 대역은 허용되며, Tailscale은 가장 구체적인 일치 항목을 선택합니다. 라우터 A가 10.0.0.0/24을 광고하고 라우터 B가 10.0.0.0/16를 광고하는 경우, 10.0.0.20으로 향하는 트래픽은 A로 전달됩니다.

사용자들이 당황하는 지점은 A가 오프라인 상태가 되었을 때의 동작입니다. Tailscale은 덜 구체적인 경로로 대체(fallback)하지 않습니다. 10.0.0.20로 향하는 트래픽은 중단되지만, 10.1.0.20로 향하는 트래픽은 B를 통해 계속 작동합니다. 이 증상은 사설 네트워크의 절반이 다운된 것처럼 보이며, 원인은 오프라인 상태인 노드가 더 구체적인 접두사를 점유하고 있기 때문입니다. 장애 조치(failover)를 원한다면, 더 넓은 범위를 담당하는 라우터가 더 좁은 범위의 접두사도 함께 광고하도록 설정하여 두 라우터가 동일한 주소를 커버하게 해야 합니다.

다른 형태의 중첩은 클라이언트와 더 가까운 곳에서 발생합니다. 192.168.1.0/24의 호텔 네트워크에 접속한 상태에서 서브넷 라우터가 192.168.1.0/24을 광고하면, 두 경로가 동일한 목적지를 두고 경쟁하게 되며 승자는 플랫폼에 따라 달라집니다. Linux에서는 Tailscale의 규칙보다 우선하는 규칙을 설치하여 로컬 주소가 메인 테이블을 사용하도록 설정하십시오.

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

해당 규칙은 영구적이지 않으며 재부팅 시 사라집니다. 근본적인 해결책은 외부 네트워크에서 마주칠 일이 없는 사설 대역을 선택하는 것입니다. 192.168.0.0/24과 192.168.1.0/24는 대부분의 가정용 라우터에서 기본값으로 사용되므로, 10.0.0.0/8 내부에서 의도적으로 선택한 대역을 사용하십시오. 동일한 이유로, 직접 설정한 일반 WireGuard VPN에서도 동일한 충돌이 발생하여 연결이 끊어집니다. 더 구체적인 로컬 경로가 우선순위를 가지므로 트래픽이 터널로 진입하지 못하기 때문입니다.

실패 모드: DNS는 해결되지만 경로가 없는 주소로 연결되는 경우

이 문제는 오류가 보고되지 않기 때문에 디버깅이 어렵습니다. 도메인 이름은 정상적으로 해결되지만 연결에서 타임아웃이 발생합니다.

db.internal.example.com이 사설 네임서버를 통해 10.0.5.20로 해결되고, 사용자가 10.0.0.0/24을 광고(advertise)했다고 가정해 보겠습니다. DNS(domain name system) 해결과 IP 라우팅은 별개의 단계이며 서로를 확인하지 않기 때문에 이름 조회는 성공합니다. 이후 10.0.5.20로 향하는 패킷은 tailnet 내에서 일치하는 경로를 찾지 못하고, 클라이언트의 기본 게이트웨이를 통해 외부로 나가 사라지게 됩니다.

두 단계를 구분하려면 다음 명령어를 사용하십시오.

nslookup db.internal.example.com
ip route get 10.0.5.20

조회 결과 주소는 반환되지만 ip route get가 dev tailscale0으로 응답하지 않는다면, 이름 해결은 정상이며 경로가 누락된 것입니다. 해당 주소를 포함하는 범위인 10.0.0.0/16을 광고하거나 두 번째 명시적 프리픽스를 광고한 뒤, 콘솔에서 해당 새 프리픽스를 승인하십시오.

네임서버 자체에도 이와 유사한 함정이 있습니다. 관리 콘솔에서 10.0.0.53과 같은 사설 주소를 전역 네임서버로 설정하는 경우, 해당 주소는 반드시 승인된 경로 내에 위치해야 합니다. 그렇지 않으면 장치들이 리졸버에 전혀 도달할 수 없습니다. 도달할 수 없는 리졸버를 가리키는 상태에서 로컬 DNS 서버를 재정의하는 옵션을 켜면, 직전까지 작동하던 장치를 포함하여 tailnet 내 모든 장치의 이름 해결 기능이 즉시 중단됩니다. 먼저 리졸버로 향하는 경로를 광고하고 승인한 뒤, DNS 설정을 변경하십시오. 터널 내부의 DNS 문제로 계속 어려움을 겪고 있다면, WireGuard 터널에서 DNS가 중단되는 방식 문서를 참조하십시오. 이 문서에서는 조정 계층 없이 동일한 메커니즘을 다룹니다.

Source NAT 및 사이트 간 연결

기본적으로 서브넷 라우터는 전달되는 모든 패킷의 출발지 주소를 자신의 사설 주소로 재작성합니다. 이를 SNAT(Source Network Address Translation)라고 하며, 사설 네트워크의 설정을 변경하지 않고도 응답이 정상적으로 전달되도록 하기 위해 존재합니다. 즉, 10.0.0.20에 있는 데이터베이스는 이미 도달 방법을 알고 있는 VPS로 응답을 보냅니다. 이 방식의 단점은 데이터베이스가 모든 tailnet 연결을 VPS에서 오는 것으로 인식한다는 점입니다. 따라서 출발지별 방화벽 규칙이나 접근 로그를 통해 정보를 얻을 수 없습니다.

클라이언트의 실제 tailnet 주소를 유지하려면 Linux에서 이 기능을 끕니다.

sudo tailscale set --snat-subnet-routes=false

이후 사설 네트워크의 호스트들은 Tailscale이 장치에 할당하는 대역인 100.64.0.0/10으로 향하는 경로를 서브넷 라우터를 가리키도록 설정해야 합니다. 이러한 반환 경로가 없으면 응답 패킷이 기본 게이트웨이로 전송되어 목적지에 도달하지 못하며, 첫 번째 패킷 이후 연결이 중단됩니다. 사설 네트워크 게이트웨이에 정적 경로를 추가하거나, SNAT를 그대로 유지하십시오.

사이트 간 연결은 두 서브넷 라우터가 동시에 이 작업을 수행하며, 각자 자신의 네트워크를 광고하고 상대방의 네트워크를 수락하는 방식입니다.

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

상대 라우터에서도 각자의 대역을 사용하여 동일한 명령을 실행하십시오. 두 대역은 서로 달라야 합니다. ssh 및 ping는 정상인데 대용량 전송이 멈춘다면, 원인은 TCP 패킷이 운반하는 최대 데이터 단위인 MSS(Maximum Segment Size) 때문입니다. 터널의 오버헤드로 인해 전달되는 패킷이 중간 링크에서 허용하는 크기보다 커지게 되며, 이를 클램핑(clamping)으로 해결할 수 있습니다.

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

해당 규칙을 iptables-persistent으로 저장하십시오. 그렇지 않으면 재부팅 시 규칙이 사라집니다.

운영을 지속하기 위한 유지보수

2026년 8월 기준으로 노드 키는 기본적으로 180일 후에 만료됩니다. 서브넷 라우터의 키가 만료되면 해당 노드는 로그아웃되며, 설정 변경 사항이 없음에도 광고된 전체 대역에 접근할 수 없게 됩니다. 관리 콘솔의 Machines 페이지에서 해당 장비의 키 만료 기능을 비활성화하고, 이 작업을 수행했음을 기록해 두십시오.

Tailscale은 피어 간의 직접 연결을 선호하며, 직접 연결이 불가능할 경우 릴레이 서버를 사용합니다. 릴레이 서버는 정상적으로 작동하지만 지연 시간이 추가됩니다. 공인 IP를 가진 VPS는 가장 쉬운 경우에 해당합니다. UDP 41641 포트의 인바운드 트래픽을 허용하면 대부분의 피어가 직접 연결됩니다. ufw로 방화벽을 관리 중이라면 VPS에 실제로 필요한 ufw 규칙에서 구문을 확인할 수 있습니다.

접근 규칙은 나머지 절반을 담당합니다. 기본 tailnet에서는 모든 장치가 서로 통신할 수 있으므로 승인된 경로는 즉시 작동합니다. 하지만 ACL 정책을 작성하면 규칙의 대상 측에 사설 대역을 명시해야 합니다. 10.0.0.20는 tailnet 주소가 아니며, tailnet IP나 태그를 기준으로 작성된 규칙으로는 커버되지 않기 때문입니다.

마지막으로, 직접 운영하지 않는 조정 서버를 사용할지 결정해야 합니다. Tailscale의 컨트롤 플레인은 호스팅 서비스입니다. 키는 사용자의 장비에 저장되지만, 계정과 정책 파일은 해당 서버에 위치합니다. 직접 호스팅하는 Tailscale 컨트롤 서버인 Headscale을 운영하면 이를 자신의 VPS에 둘 수 있지만, 직접 유지보수해야 하는 비용이 발생합니다. 동일한 우려에 대한 다른 대안은 Tailscale 클라이언트를 사용하지 않는 것이며, NetBird VPN 서버를 직접 호스팅하면 조정 계층과 자체 메시 클라이언트를 직접 제어하는 한 대의 장비에 통합할 수 있습니다. 이 모델과 수동 설정 방식 사이에서 고민 중이라면, WireGuard와 Tailscale 비교 문서를 통해 조정 계층이 제공하는 기능과 그에 따른 비용을 확인하십시오.

FAQ

서브넷 라우터와 엑시트 노드의 차이점은 무엇입니까?

서브넷 라우터는 사설 주소 대역을 광고하여 Tailscale이 설치되지 않은 장비도 tailnet 내 장치들이 접근할 수 있게 합니다. 엑시트 노드는 자신을 전체 인터넷으로 향하는 경로로 광고하며, 이를 통해 장치의 모든 트래픽이 해당 노드의 공인 IP 주소를 거쳐 나가게 합니다. 하나의 VPS가 두 역할을 동시에 수행할 수도 있습니다. 이들은 각각 --advertise-routes와 --advertise-exit-node이라는 별도의 플래그를 사용하며, 관리자 콘솔에서 각각 승인 절차를 거쳐야 합니다.

Linux 클라이언트가 광고된 서브넷 경로를 무시하는 이유는 무엇입니까?

Linux 클라이언트는 사용자가 명시적으로 허용하지 않으면 서브넷 경로를 수락하지 않습니다. 클라이언트에서 sudo tailscale set --accept-routes을 실행하십시오. 그 후 ip route show가 아닌 ip route show table 52을 사용하여 확인하십시오. Tailscale은 수락된 경로를 라우팅 테이블 52에 설치하고 정책 규칙을 통해 접근하도록 하므로, 메인 테이블에는 해당 경로가 나타나지 않아 마치 경로가 누락된 것처럼 보일 수 있습니다.

재부팅 후 서브넷이 작동하지 않습니다. 무엇이 문제입니까?

IP 포워딩 설정이 해제되었을 가능성이 가장 높습니다. sysctl -w으로 설정한 값은 재부팅 시 유지되지 않으므로, /etc/sysctl.d/99-tailscale.conf에 해당 값을 기록하고 sysctl net.ipv4.ip_forward로 설정을 확인하십시오. 포워딩이 활성화되어 있는데도 해당 대역에 접근할 수 없다면 관리자 콘솔에서 해당 노드를 확인하십시오. 노드 키는 기본적으로 180일 후에 만료되며, 만료된 서브넷 라우터는 계정 문제임에도 불구하고 네트워크 장애처럼 보일 수 있습니다.

두 대의 서브넷 라우터가 동일한 대역을 광고할 수 있습니까?

완전히 동일한 대역은 광고할 수 없습니다. 접두사 길이가 다른 겹치는 대역은 허용되며, 더 구체적인 경로가 우선순위를 갖습니다. 장애 조치(failover) 시에는 주의가 필요합니다. 더 구체적인 접두사를 가진 라우터가 오프라인 상태가 되면 Tailscale은 더 넓은 범위의 경로로 자동 전환하지 않으므로 트래픽이 차단됩니다. 실제 대기(standby) 구성을 하려면 두 라우터가 모두 동일한 구체적 접두사를 광고하도록 설정해야 합니다.

호스트 이름은 확인되는데 연결 시간 초과가 발생합니다. 왜 그렇습니까?

DNS 확인과 라우팅은 별개의 과정입니다. 이름은 확인되더라도 승인된 경로에 포함되지 않은 주소로 해석될 수 있으며, 이 경우 패킷은 클라이언트의 기본 게이트웨이를 통해 외부로 나갑니다. 클라이언트에서 ip route get <address>을 실행하십시오. 결과에 dev tailscale0가 포함되어 있지 않다면 해당 주소를 포함하는 대역을 광고하고 관리자 콘솔에서 새로운 접두사를 승인하십시오.