Chạy Tailscale subnet router trên VPS

Tailscale subnet router làm gì

Tailscale subnet router là một máy quảng bá toàn bộ dải địa chỉ IP private vào tailnet, để mọi thiết bị trong tailnet có thể truy cập các địa chỉ trong dải đó dù không có thiết bị nào ở đó chạy Tailscale. Tailnet là mạng Tailscale private của bạn, gồm các thiết bị đã đăng nhập vào cùng một account hoặc organisation. Exit node là tính năng thường bị nhầm với subnet router và có nhiệm vụ ngược lại. Nó gửi toàn bộ traffic của một thiết bị ra Internet thông qua VPS, nên VPS trở thành route của thiết bị đó đến Internet public.

Mỗi khái niệm có thể tóm tắt trong một câu. Subnet router giúp một mạng private có thể truy cập được từ tailnet. Exit node thay đổi nơi traffic public của bạn đi ra Internet. Nếu bạn cần tính năng thứ hai, hãy đọc cách chạy Tailscale exit node trên VPS thay vì phần này. Đây là hai flag riêng biệt; một VPS có thể chạy cả hai cùng lúc, nhưng chúng giải quyết các vấn đề khác nhau và cũng gặp lỗi theo những cách khác nhau.

Khi VPS cần làm subnet router

Trường hợp phổ biến là một private network đã được nhà cung cấp cấp sẵn. VPS có một địa chỉ public và một interface thứ hai trong một private segment. Các server khác trong segment đó hoàn toàn không có địa chỉ public: một database tại 10.0.0.20 và một backup target tại 10.0.0.30. Cài Tailscale trên một VPS, quảng bá 10.0.0.0/24, rồi laptop của bạn có thể truy cập trực tiếp các địa chỉ private đó. Không cần thay đổi gì trên các server khác trong segment, và database vẫn không có địa chỉ public. Nếu bạn chỉ cần truy cập một web app duy nhất trên một port duy nhất trong segment đó, quảng bá toàn bộ dải mạng là quá mức cần thiết; Tailscale serve đặt HTTPS trực tiếp trên port duy nhất đó. Lập luận tương tự áp dụng cho một daemon cố ý chỉ bind vào localhost, chẳng hạn dsh chạy headless dưới systemd, khi địa chỉ tailnet trên VPS đó thay thế SSH tunnel mà bạn thường phải duy trì để truy cập UI của daemon.

Trường hợp còn lại là một mạng ở phía bên kia của VPS. Đó có thể là mạng LAN gia đình hoặc văn phòng nằm sau router riêng, hoặc một rack gồm các thiết bị hoàn toàn không thể chạy Tailscale, chẳng hạn như managed switch hoặc NAS cũ có firmware bị khóa. Một máy Linux trong mạng đó sẽ làm subnet router cho tất cả thiết bị còn lại. Router gia đình ở phía trước máy này không cần forward port cho cấu hình này. cách Tailscale vượt NAT mà không cần mở port trên router giải thích vì sao cách này hoạt động và khi nào Tailscale chuyển sang relay. Ở nhà, máy đó thường là một VM trên hypervisor mà bạn đã có sẵn. bài toán chi phí của một host Proxmox tại nhà so với VPS thuê là điều cần giải quyết trước khi quyết định service nên đặt ở đầu nào của tunnel.

Cả hai trường hợp đều có chung một yêu cầu. Subnet router phải truy cập được dải mạng mà nó quảng bá, bằng routing table và firewall của chính nó. Tailscale không tạo kết nối đó. Tailscale chuyển traffic đến router rồi giao cho kernel forward.

Cài đặt Tailscale và kiểm tra route cục bộ trước

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

Script xác định bản phân phối, thêm package repository của Tailscale, cài đặt command tailscale và daemon tailscaled, sau đó enable service. Xác nhận bằng systemctl is-active tailscaled. Kết quả phải hiển thị active.

Trước tiên, hãy xác minh VPS có thể truy cập network mà bạn dự định quảng bá.

ip route show
ping -c3 10.0.0.20

ip route show phải liệt kê private range trên một interface thực, chẳng hạn như 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Nếu ping thất bại tại đây, ngay trên router, thì không có flag Tailscale nào có thể khắc phục. Nguyên nhân nằm ở cấu hình network của VPS hoặc firewall trên host đích. Hãy sửa lỗi đó trước, vì mọi test tiếp theo đều phụ thuộc vào nó.

Bật IP forwarding và giữ nguyên sau khi reboot

Máy Linux sẽ loại bỏ mọi packet không được gửi đến chính nó nếu forwarding chưa được bật. Chuyển tiếp packet của các máy khác là chức năng chính của subnet router, vì vậy không thể bỏ qua bước này.

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

Kiểm tra bằng sysctl net.ipv4.ip_forward. Kết quả phải là net.ipv4.ip_forward = 1.

Nhiều người chỉ hoàn tất một nửa bước này. sudo sysctl -w net.ipv4.ip_forward=1 có hiệu lực ngay lập tức nhưng sẽ mất sau lần boot tiếp theo. Khi đó subnet router có thể chạy nhiều tuần rồi dừng vào buổi sáng sau khi reboot để nâng cấp kernel. Phần gây nhầm lẫn là không có dấu hiệu rõ ràng cho thấy hệ thống bị lỗi. tailscale status vẫn hiển thị node đang online, admin console vẫn hiển thị route đã được phê duyệt, và các client vẫn cài route đó. Packet đến VPS nhưng kernel loại bỏ chúng mà không ghi log. Ghi các giá trị vào /etc/sysctl.d/99-tailscale.conf sẽ khôi phục chúng sau khi reboot.

Nếu bạn quảng bá route khi forwarding vẫn tắt, tailscale up sẽ cảnh báo ngay lúc đó. Trên Linux, dòng này gần giống Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.. Hãy đọc output của lệnh đó thay vì bỏ qua nó.

Quảng bá các route

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

Trên VPS đã đăng nhập vào tailnet, thay đổi cấu hình tại chỗ:

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

Dùng tailscale set cho mọi thay đổi sau đó. Chạy lại tailscale up với một flag duy nhất sẽ reset các flag bạn không lặp lại. CLI sẽ dừng và báo lỗi rằng khi thay đổi cấu hình theo cách này, bạn phải chỉ định tất cả các flag không mặc định. tailscale set chỉ thay đổi một cấu hình và giữ nguyên các cấu hình còn lại.

Đặt nhiều dải mạng trong một danh sách phân tách bằng dấu phẩy, không có khoảng trắng: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Mỗi mục phải là một network address ở dạng CIDR (classless inter-domain routing, dạng 10.0.0.0/24). Nếu ghi nhầm địa chỉ host của chính bạn, 10.0.0.5/24, lệnh sẽ bị từ chối vì các bit sau prefix không bằng 0. Thông báo lỗi sẽ nêu prefix mà bạn có thể đã định dùng. Để dừng quảng bá, đặt danh sách rỗng bằng sudo tailscale set --advertise-routes=.

Phê duyệt route trong admin console

Quảng bá một route chỉ là một yêu cầu, không phải thay đổi đã được áp dụng. Cho đến khi admin phê duyệt, không client nào nhận được route và không tài nguyên nào trong dải đó có thể truy cập. Đây là cơ chế có chủ đích, vì một máy có thể tự thêm mình vào routing table của mọi người sẽ có thể thu thập traffic của bất kỳ dải nào nó muốn.

Phê duyệt route trên trang Machines của admin console. VPS sẽ được liệt kê cùng subnet badge. Mở dòng tương ứng, tìm phần subnets, chỉnh sửa route settings, chọn route rồi lưu.

Việc phê duyệt áp dụng cho từng prefix. Hôm nay bạn quảng bá 10.0.0.0/24 và tháng sau quảng bá 192.168.50.0/24, prefix mới sẽ xuất hiện ở trạng thái chưa được phê duyệt, còn prefix cũ vẫn hoạt động. Từ VPS, route đã được phê duyệt và route bị bỏ qua trông giống hệt nhau, vì vậy hãy kiểm tra console trước khi debug vấn đề khác.

Bạn có thể bỏ qua bước thủ công bằng block autoApprovers trong file tailnet policy:

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

Sau đó khởi động node với tag đó, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, và route sẽ được phê duyệt ngay khi được quảng bá. Tag này trước hết phải tồn tại trong phần tagOwners của cùng file policy. Cách này đáng thiết lập nếu bạn rebuild VPS bằng script, vì node sau khi rebuild là một node mới và các route của nó lại bắt đầu ở trạng thái chưa được phê duyệt.

Vì sao client Linux bỏ qua route nếu không có --accept-routes

Route đã được quảng bá và phê duyệt. Điện thoại và Mac của bạn truy cập được 10.0.0.20. Laptop Linux không truy cập được, nhưng admin console không cho thấy vấn đề nào.

Chấp nhận subnet route nghĩa là ghi các entry vào routing table của client. Trên Android, iOS, macOS, tvOS và Windows, Tailscale client tự làm việc này cho bạn. Trên Linux thì không, vì máy Linux thường là server hoặc router có routing table đã được cấu hình có chủ đích. Tự động chèn một /24 học được từ network có thể làm hỏng traffic mà máy đó đang xử lý. Vì vậy, trên Linux, bạn phải bật tùy chọn này trên từng client:

sudo tailscale set --accept-routes

Sau đó kiểm tra route đã được ghi vào đâu:

ip route show table 52
ip route get 10.0.0.20

Tailscale trên Linux không đặt các route đã chấp nhận vào main routing table. Nó đặt chúng vào routing table 52 và cài policy rule. Các rule này hiển thị bằng ip rule show trong dải priority từ 5210 đến 5270 và chuyển các packet không khớp đến table đó. Vì vậy, ip route show tự nó sẽ không bao giờ liệt kê 10.0.0.0/24. Người đọc chỉ kiểm tra lệnh đó sẽ kết luận rằng --accept-routes không có tác dụng. ip route show table 52 mới là lệnh hiển thị trạng thái thực tế, và kết quả phải liệt kê dải đã quảng bá trên tailscale0.

Có một ngoại lệ cần biết. Nếu node Linux này cũng là subnet router thứ hai cho local network của chính nó, --accept-routes sẽ khiến node gửi traffic đến subnet được kết nối trực tiếp của nó qua router kia thay vì qua interface của chính nó. Trên router dự phòng trong một cặp high availability, hãy tắt --accept-routes và chỉ quảng bá route.

Chế độ lỗi: hai router quảng bá các dải địa chỉ chồng lấn

Hai subnet router có thể quảng bá các dải địa chỉ giống hệt nhau. Đây là cách một cặp high availability hoạt động: mỗi router quảng bá chính xác cùng các prefix, và client có thể chuyển sang router còn lại khi router hiện tại lỗi. Các dải địa chỉ chồng lấn với độ dài prefix khác nhau cũng được phép, và Tailscale chọn route cụ thể nhất. Khi router A quảng bá 10.0.0.0/24 còn router B quảng bá 10.0.0.0/16, traffic đến 10.0.0.20 sẽ đi qua A.

Điểm dễ gây bất ngờ là hành vi khi A offline. Tailscale không chuyển sang route ít cụ thể hơn, vì router offline không thể rút quảng bá của nó và client vẫn ưu tiên prefix cụ thể hơn. Traffic đến 10.0.0.20 dừng lại, trong khi traffic đến 10.0.1.20, chỉ được /16 của B bao phủ, vẫn hoạt động qua B. Triệu chứng trông giống như một phần private network bị down. Nguyên nhân là một node offline vẫn giữ prefix cụ thể hơn. Nếu muốn có failover, hãy để router có dải rộng hơn cũng quảng bá các prefix hẹp hơn, để cả hai router cùng bao phủ các địa chỉ đó.

Một dạng chồng lấn khác xảy ra gần client hơn. Khi bạn đang dùng network khách sạn tại 192.168.1.0/24 trong lúc subnet router quảng bá 192.168.1.0/24, hai route sẽ cạnh tranh cho cùng đích đến. Route nào thắng còn tùy vào platform. Trên Linux, hãy thêm một rule đứng trước rule riêng của Tailscale để các địa chỉ local sử dụng main table:

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

Rule này không persistent và sẽ mất sau lần boot tiếp theo. Cách khắc phục thực sự là chọn một private range mà bạn sẽ không gặp trên các network khác. 192.168.0.0/24 và 192.168.1.0/24 là các giá trị mặc định trên hầu hết home router, nên hãy chọn một dải bên trong 10.0.0.0/8 theo cách có chủ đích. Xung đột tương tự cũng làm hỏng plain WireGuard VPN mà bạn tự cấu hình, vì cùng một lý do: route local cụ thể hơn sẽ thắng, nên traffic không bao giờ đi vào tunnel.

Chế độ lỗi: DNS phân giải thành địa chỉ không có route bao phủ

Trường hợp này khó debug vì không có thành phần nào báo lỗi. Tên được phân giải thành công. Kết nối bị timeout.

Giả sử db.internal.example.com được phân giải thành 10.0.5.20 thông qua nameserver riêng của bạn và bạn đã quảng bá 10.0.0.0/24. Lookup thành công vì DNS (domain name system) resolution và IP routing là 2 bước riêng biệt, đồng thời không bước nào kiểm tra bước còn lại. Sau đó, packet đến 10.0.5.20 không tìm thấy route phù hợp trên tailnet, nên rời mạng qua default gateway của client rồi biến mất.

2 lệnh dưới đây giúp tách riêng 2 phần:

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

Nếu lookup trả về một địa chỉ nhưng ip route get không phản hồi với dev tailscale0, tên không có vấn đề và client này đang thiếu route. Trên Linux client, trước tiên xác nhận --accept-routes đang bật, vì nếu không có nó thì subnet route sẽ không được cài đặt, ngay cả khi đã có approved prefix bao phủ địa chỉ đó. Nếu tùy chọn này đang bật nhưng không có approved prefix nào bao phủ địa chỉ, hãy quảng bá một range bao phủ địa chỉ đó, dùng 10.0.0.0/16 hoặc thêm một prefix tường minh thứ 2, rồi approve prefix mới trong console.

Nameserver cũng có một lỗi tương tự. Nếu bạn đặt global nameserver trong admin console tại một private address như 10.0.0.53, địa chỉ đó phải nằm trong một approved route. Nếu không, các device không nằm trên private network đó sẽ hoàn toàn không thể truy cập resolver. Nếu bật tùy chọn ghi đè local DNS servers trong khi trỏ đến một resolver mà không device nào truy cập được, mọi device trong tailnet sẽ mất name resolution ngay lập tức, kể cả những device vừa hoạt động trước đó. Hãy quảng bá và approve route đến resolver trước, rồi mới thay đổi DNS setting. Nếu DNS bên trong tunnel là phần bạn liên tục phải xử lý, cách DNS bị lỗi qua WireGuard tunnel trình bày cùng cơ chế này nhưng không có thêm lớp điều phối.

Source NAT và liên kết site-to-site

Theo mặc định, subnet router viết lại địa chỉ nguồn của mọi packet được forward thành địa chỉ private của chính nó. Đây là SNAT (source network address translation). Cơ chế này giúp packet phản hồi hoạt động mà không cần thay đổi gì trên private network: database tại 10.0.0.20 trả lời VPS, vì nó đã biết cách truy cập VPS. Đổi lại, database thấy mọi kết nối từ tailnet đều đến từ VPS. Vì vậy, firewall rule theo source và access log không còn cho biết client thực sự là ai.

Tắt SNAT trên Linux khi bạn muốn giữ địa chỉ tailnet thực của client:

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

Khi đó, các host trên private network cần có route quay về 100.64.0.0/10, là dải địa chỉ mà Tailscale cấp cho các device, và route này phải trỏ đến subnet router. Nếu không có route quay về, packet phản hồi sẽ đi đến default gateway và không bao giờ đến nơi. Kết nối sẽ treo ngay sau packet đầu tiên. Thêm static route trên gateway của private network, hoặc giữ SNAT.

Liên kết site-to-site là mô hình trong đó 2 subnet router thực hiện việc này đồng thời. Mỗi router quảng bá network của mình và chấp nhận network của router còn lại:

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

Chạy command tương ứng trên router còn lại với dải địa chỉ của router đó. 2 dải địa chỉ phải khác nhau. Nếu các lần truyền dữ liệu lớn bị treo trong khi ssh và ping vẫn hoạt động bình thường, nguyên nhân là MSS (maximum segment size), tức kích thước lớn nhất của phần dữ liệu mà một TCP packet mang theo. Overhead của tunnel khiến packet được forward quá lớn đối với một link nào đó trên đường truyền. Clamping sẽ khắc phục vấn đề này:

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

Lưu rule đó bằng iptables-persistent, nếu không rule sẽ biến mất sau lần boot tiếp theo.

Bảo trì để hệ thống hoạt động ổn định

Việc key của máy này hết hạn hay không phụ thuộc vào cách bạn đăng nhập. Node được khởi tạo dưới một tag, như trong ví dụ autoApprovers ở trên, mặc định đã tắt thời hạn key ngay từ lần đầu được gắn tag và xác thực, nên cấu hình đó không cần làm gì thêm ở đây. Node đăng nhập dưới danh nghĩa bạn sẽ tuân theo thời hạn key của tailnet. Tailnet mới mặc định có thời hạn 180 ngày và có thể đặt từ 1 đến 180 ngày, tính đến tháng 10 năm 2026. Khi key của một subnet router như vậy hết hạn, các kết nối đến và đi qua node đó sẽ dừng, toàn bộ dải địa chỉ được quảng bá trở nên không thể truy cập, nhưng không có thay đổi cấu hình nào ở nơi khác để giải thích nguyên nhân. Với router đăng nhập dưới danh nghĩa người dùng, hãy tắt thời hạn key từ menu ở cuối dòng tương ứng trên trang Machines của admin console, rồi ghi lại việc bạn đã làm.

Tailscale ưu tiên kết nối trực tiếp giữa các peer và chuyển sang relay server khi không thiết lập được kết nối trực tiếp. Relay vẫn hoạt động, nhưng làm tăng latency. VPS có public address là trường hợp đơn giản: cho phép UDP inbound trên cổng 41641 thì hầu hết peer sẽ kết nối trực tiếp. Khi traffic đến private range chậm hơn mức mà đường truyền đến VPS đáng lẽ phải đáp ứng, kiểm tra client kết nối trực tiếp đến subnet router hay đi qua relay là việc đầu tiên cần loại trừ. Nếu firewall do ufw quản lý, các ufw rule mà VPS thực sự cần giải thích cú pháp.

Access rule là phần còn lại. Trên tailnet mặc định, mọi thiết bị của bạn đều có thể truy cập mọi thiết bị khác, nên route đã được phê duyệt sẽ hoạt động ngay. Khi bạn viết ACL policy, phần đích của rule phải bao phủ private range. Bạn có thể chỉ rõ range đó hoặc dùng wildcard *. Wildcard này bao gồm các subnet route đã được phê duyệt, vì 10.0.0.20 không phải là địa chỉ tailnet và không được các rule áp dụng cho tailnet IP hoặc tag bao phủ.

Cuối cùng, hãy quyết định bạn có chấp nhận dùng một coordination server do bên khác vận hành hay không. Control plane của Tailscale là một hosted service. Các key vẫn nằm trên máy của bạn, nhưng account và policy file được lưu tại đó. Trước khi cấp cho nó đường vào private network, bạn nên xác định rõ một control plane bị compromise hoặc thông tin đăng nhập identity bị đánh cắp thực sự có thể gây ra những gì. Mô hình trust của Tailscale chỉ ra ranh giới này. Chi phí hiếm khi là lý do khiến người dùng rời bỏ Tailscale, vì free plan hỗ trợ tối đa sáu user với số lượng device không giới hạn của chính họ. Tuy nhiên, subnet router được tạo dưới một tag được tính khác với subnet router đăng nhập bằng chính account của bạn. Sau mốc đó, hóa đơn được tính theo số người thay vì số máy. Vì vậy, bạn nên tính trước một hộ gia đình hoặc team năm người thực sự phải trả bao nhiêu khi free plan hết phạm vi hỗ trợ trước khi thêm account khiến bạn vượt giới hạn.

Vận hành Headscale, control server Tailscale tự host sẽ giữ thành phần này trên VPS của bạn, nhưng bạn phải tự bảo trì. Một cách khác để giải quyết cùng mối lo ngại là không dùng cả client của Tailscale. Tự host VPN server NetBird đưa coordination layer và các mesh client của nó lên một máy do bạn kiểm soát. Cả hai đều dùng WireGuard bên dưới, nên khi chuyển đổi, các phần thay đổi là những điểm được bài so sánh NetBird và Tailscale cân nhắc: ai vận hành control plane, bạn viết access rule bao phủ private range như thế nào, và traffic được relay ra sao khi các peer không thể kết nối trực tiếp. Nếu bạn vẫn đang cân nhắc giữa mô hình này và cấu hình viết thủ công, bài so sánh WireGuard và Tailscale giải thích coordination layer cung cấp những gì và chi phí của nó.

FAQ

Subnet router khác exit node như thế nào?

Subnet router quảng bá một dải private address, để các thiết bị trong tailnet có thể truy cập những máy không chạy Tailscale. Exit node quảng bá chính nó như route đến toàn bộ Internet, để thiết bị gửi toàn bộ traffic ra ngoài qua public address của node đó. Một VPS có thể làm cả hai. Đây là 2 flag riêng, --advertise-routes và --advertise-exit-node, và mỗi flag cần được phê duyệt riêng trong admin console.

Vì sao Linux client không sử dụng subnet route đã quảng bá?

Linux client không chấp nhận subnet route nếu bạn không yêu cầu. Chạy sudo tailscale set --accept-routes trên client. Sau đó kiểm tra bằng ip route show table 52, không dùng ip route show. Tailscale cài các route đã được chấp nhận vào routing table 52 và đi đến chúng thông qua policy rule, nên main table không liệt kê các route này. Vì vậy, một route đang hoạt động có thể trông như bị thiếu.

Subnet của tôi ngừng hoạt động sau khi reboot. Nguyên nhân là gì?

Nhiều khả năng là IP forwarding. Giá trị được đặt bằng sysctl -w sẽ không tồn tại sau reboot, nên hãy ghi giá trị đó vào /etc/sysctl.d/99-tailscale.conf và xác nhận bằng sysctl net.ipv4.ip_forward. Nếu forwarding đã bật nhưng range vẫn không thể truy cập, hãy kiểm tra node trong admin console. Router đăng nhập dưới danh nghĩa người dùng mặc định có key hết hạn sau 180 ngày. Subnet router hết hạn key thường trông giống như lỗi mạng thay vì lỗi account. Router được khởi tạo dưới một tag mặc định đã tắt thời hạn key, nên với router đó, hãy tìm nguyên nhân ở nơi khác.

Hai subnet router có thể quảng bá cùng một range không?

Có. Hai router quảng bá cùng range là cách triển khai một cặp high availability: cả hai phải quảng bá chính xác cùng các prefix. Các range chồng lấn nhưng có độ dài prefix khác nhau cũng được, và prefix cụ thể hơn sẽ được ưu tiên. Tuy nhiên, failover cần được xử lý cẩn thận: khi router giữ prefix cụ thể hơn offline, Tailscale không chuyển sang route rộng hơn, nên traffic đó sẽ dừng. Với một cặp standby thực sự, hãy để cả hai router quảng bá cùng các prefix cụ thể.

Hostname phân giải được nhưng kết nối bị timeout. Vì sao?

DNS resolution và routing là 2 bước riêng biệt. Một name có thể phân giải thành address nhưng không có approved route nào bao phủ address đó. Khi đó packet sẽ đi qua default gateway của client. Chạy ip route get <address> trên client. Nếu kết quả trên Linux client không chứa dev tailscale0, trước tiên hãy kiểm tra --accept-routes đã bật chưa. Nếu đã bật, hãy quảng bá một range bao phủ address đó và phê duyệt prefix mới trong admin console.