Paano Magpatakbo ng Tailscale Subnet Router sa VPS

Ano ang ginagawa ng Tailscale subnet router

Ang Tailscale subnet router ay isang machine na nag-a-advertise ng buong range ng mga private IP address papunta sa iyong tailnet, kaya maaabot ng bawat device sa tailnet ang mga address sa range na iyon kahit walang Tailscale na tumatakbo sa alinman sa mga iyon. Ang tailnet ay ang private Tailscale network mo: ang hanay ng mga device na naka-sign in sa iisang account o organisation. Ang exit node ang feature na madalas napagkakamalang kapareho nito, pero kabaligtaran ang ginagawa nito. Ipinapadaan nito sa VPS ang lahat ng traffic ng isang device, kaya ang VPS ang nagiging route ng device na iyon papunta sa public internet.

Isang pangungusap bawat isa. Ginagawang reachable ng subnet router mula sa tailnet ang isang private network. Binabago naman ng exit node kung saan lumalabas ang iyong public traffic. Kung ang pangalawa ang kailangan mo, basahin ang kung paano magpatakbo ng Tailscale exit node sa isang VPS sa halip. Magkaibang flag ang mga ito, at maaaring gawin ng isang VPS ang pareho nang sabay, pero magkaiba ang problemang nilulutas ng mga ito at magkaiba rin ang paraan ng pag-fail ng mga ito.

Kapag kailangan ng VPS ng subnet router

Ang karaniwang sitwasyon ay isang private network na ibinigay na ng iyong provider. May public address ang iyong VPS at may pangalawang interface ito sa isang private segment. Walang public address ang ibang server sa segment na iyon: isang database sa 10.0.0.20 at isang backup target sa 10.0.0.30. I-install ang Tailscale sa isang VPS at i-advertise ang 10.0.0.0/24. Pagkatapos, direktang maaabot ng iyong laptop ang mga private address na iyon. Walang ibang kailangang baguhin sa segment, at mananatiling walang public address ang database. Kung isang web app lamang sa isang port ang kailangan mo mula sa segment na iyon, sobra para sa pangangailangan ang pag-advertise ng buong range. Sa halip, naglalagay ang Tailscale serve ng HTTPS sa iisang port na iyon. Ganoon din ang dahilan para sa isang daemon na sadyang nagbi-bind lamang sa localhost, gaya ng dsh na tumatakbo nang headless sa ilalim ng systemd. Sa ganitong setup, pinapalitan ng tailnet address sa VPS na iyon ang SSH tunnel na kailangan mo sanang panatilihing bukas para maabot ang UI nito.

Ang isa pang sitwasyon ay isang network na nasa kabilang panig ng VPS. Maaaring ito ay isang home o office LAN (local area network) na nasa likod ng sarili nitong router, o isang rack ng mga appliance na hindi kayang magpatakbo ng Tailscale, gaya ng managed switch o lumang NAS na may naka-lock na firmware. Isang Linux box sa network na iyon ang magsisilbing subnet router para sa lahat ng iba pang device dito. Sa bahay, madalas itong isang maliit na VM sa hypervisor na pinapatakbo mo na. Bago magpasya kung saang dulo ng tunnel dapat ilagay ang iyong mga serbisyo, kailangan munang ayusin ang paghahambing ng gastos ng Proxmox host sa bahay at rented VPS.

Pareho ang dalawang sitwasyon sa isang kinakailangan. Dapat maaabot na ng subnet router ang range na ina-advertise nito gamit ang sarili nitong routing table at firewall. Hindi binubuo ng Tailscale ang koneksiyong iyon. Dinadala nito ang traffic sa router at ipinapasa ito sa kernel para i-forward.

I-install ang Tailscale at suriin muna ang lokal na route

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

Tinutukoy ng script ang distribution, idinaragdag ang package repository ng Tailscale, ini-install ang command na tailscale at ang daemon na tailscaled, at pagkatapos ay ini-enable ang service. Kumpirmahin ito gamit ang systemctl is-active tailscaled, na dapat mag-print ng active.

Bago ang lahat, tiyaking maaabot ng VPS ang network na plano mong i-advertise.

ip route show
ping -c3 10.0.0.20

Dapat ilista ng ip route show ang private range sa isang aktuwal na interface, gaya ng 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Kung mabigo ang ping dito, sa router mismo, walang Tailscale flag na makapaglulutas nito. Ang problema ay nasa network configuration ng VPS o sa firewall ng target host. Ayusin muna iyon, dahil nakadepende rito ang bawat susunod na test.

I-on ang IP forwarding at panatilihin itong naka-enable pagkatapos ng reboot

Idini-drop ng Linux machine ang anumang packet na hindi para sa sarili nito maliban kung naka-on ang forwarding. Ang pagpapasa ng mga packet ng ibang machine ang pangunahing tungkulin ng isang subnet router, kaya hindi opsyonal ang hakbang na ito.

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

Suriin ito gamit ang sysctl net.ipv4.ip_forward, na dapat mag-print ng net.ipv4.ip_forward = 1.

Madalas na bahagyang tama lang ang pagkakagawa sa hakbang na ito. Agad gumagana ang sudo sysctl -w net.ipv4.ip_forward=1 ngunit nawawala sa susunod na boot. Dahil dito, maaaring tumakbo nang ilang linggo ang subnet router at biglang huminto kinaumagahan pagkatapos ng reboot dahil sa kernel upgrade. Nakalilito ito dahil walang mukhang sira. Ipinapakita pa rin ng tailscale status na online ang node, ipinapakita pa rin ng admin console na approved ang route, at naka-install pa rin sa mga client ang route. Dumarating ang mga packet sa VPS, ngunit dini-drop ng kernel ang mga ito nang walang anumang log. Ang pagsusulat ng mga value sa /etc/sysctl.d/99-tailscale.conf ang nagpapanatili sa mga ito pagkatapos ng reboot.

Kung nag-a-advertise ka ng mga route habang naka-off pa ang forwarding, magbibigay ng babala ang tailscale up sa oras na iyon, na may linyang malapit sa Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. Basahin ang output ng command na iyon sa halip na lampasan ito.

I-anunsyo ang mga route

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

Sa isang VPS na naka-sign in na sa iyong tailnet, baguhin na lang mismo ang setting:

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

Gamitin ang tailscale set sa bawat susunod na pagbabago. Kapag muling pinatakbo ang tailscale up gamit ang isang flag lang, nire-reset nito ang mga flag na hindi mo inulit. Hihinto rin ang CLI at magpapakita ng error na nagsasabing kailangang banggitin ang lahat ng non-default flag kapag ganitong paraan ang gamit sa pagbabago ng mga setting. Binabago ng tailscale set ang isang setting at iniiwan ang iba sa dati nilang halaga.

Ilagay ang maraming range sa isang comma-separated list na walang space: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Kailangang network address ang bawat entry at nasa CIDR notation (classless inter-domain routing, ang anyong 10.0.0.0/24). Kapag hindi sinasadyang isinulat ang sarili mong host address, 10.0.0.5/24, tatanggihan ito dahil hindi zero ang mga bit pagkatapos ng prefix. Babanggitin sa error ang prefix na malamang na dapat mong gamitin. Para ihinto ang pag-anunsyo, magtakda ng empty list gamit ang sudo tailscale set --advertise-routes=.

Aprubahan ang route sa admin console

Ang pag-advertise ng route ay isang request, hindi isang pagbabago. Hangga't hindi ito inaaprubahan ng admin, walang client na makakatanggap ng route at walang maaabot sa loob ng range. Sinasadya ito dahil maaaring makuha ng isang machine na kayang idagdag ang sarili nito sa routing table ng lahat ang traffic para sa anumang range na gusto nito.

Aprubahan ito sa Machines page ng admin console. Nakalista ang VPS na may subnet badge. Buksan ang row nito, hanapin ang subnets section, i-edit ang route settings, piliin ang route, at i-save.

Bawat prefix ay kailangang aprubahan nang hiwalay. Kung ia-advertise mo ang 10.0.0.0/24 ngayon at ang 192.168.50.0/24 sa susunod na buwan, mananatiling hindi approved ang bagong prefix habang patuloy na gumagana ang luma. Magkapareho ang itsura ng approved route at ignored route mula sa VPS, kaya suriin muna ang console bago mag-debug ng iba.

Maaari mong laktawan ang manual na hakbang gamit ang autoApprovers block sa tailnet policy file:

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

Pagkatapos, i-up ang node gamit ang tag na iyon, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, at maaaprubahan ang route sa oras na ma-advertise ito. Kailangang mayroon muna ang tag sa tagOwners section ng parehong policy file. Mainam itong i-set up kung nire-rebuild mo ang VPS gamit ang script, dahil bagong node ang rebuilt node at muling magiging hindi approved ang mga route nito.

Bakit binabalewala ng Linux clients ang route kapag walang --accept-routes

Na-advertise at naaprubahan na ang route. Maaabot ng iyong phone at Mac ang 10.0.0.20. Hindi ito maabot ng iyong Linux laptop, at walang ipinapakitang problema ang admin console.

Ang pagtanggap ng subnet route ay nangangahulugang pagsusulat ng mga entry sa routing table ng client. Sa Android, iOS, macOS, tvOS, at Windows, awtomatikong ginagawa ito ng Tailscale client. Sa Linux, hindi ito ginagawa dahil madalas na server o router ang Linux machine na ang routing table ay sadyang na-configure ng administrator. Maaaring makasira sa kasalukuyang traffic ng machine ang tahimik na paglalagay ng /24 na natutuhan mula sa network. Kaya sa Linux, kailangan mong mag-opt in sa bawat client:

sudo tailscale set --accept-routes

Pagkatapos, tingnan kung saan nailagay ang route:

ip route show table 52
ip route get 10.0.0.20

Hindi inilalagay ng Tailscale sa Linux ang mga tinanggap na route sa main routing table. Inilalagay nito ang mga ito sa routing table 52 at nag-i-install ng policy rules. Makikita ang mga rule na ito gamit ang ip rule show sa priority range na 5210 hanggang 5270. Ipinapadala ng mga ito ang mga packet na walang tumugmang route sa table na iyon. Kaya hindi kailanman ililista ng ip route show nang mag-isa ang 10.0.0.0/24. Maaaring isipin ng mambabasa na walang ginawa ang --accept-routes kung iyon lamang ang command na susuriin. Ang ip route show table 52 ang command na nagpapakita ng aktuwal na kalagayan. Dapat nitong ilista ang na-advertise na range sa tailscale0.

May isang exception na dapat malaman. Kung ang Linux node na ito ay isa ring second subnet router para sa sarili nitong local network, gagawin ng --accept-routes na ipadala ang traffic para sa sarili nitong direktang nakakonektang subnet sa kabilang router sa halip na palabasin ito sa sarili nitong interface. Sa standby router ng high availability pair, panatilihing naka-off ang --accept-routes at mag-advertise lamang.

Failure mode: dalawang router ang nag-a-advertise ng magkakapatong na range

Hindi dapat mag-advertise ang dalawang subnet router ng magkakaparehong range. Pinapayagan ang magkakapatong na range na may magkaibang prefix length, at pinipili ng Tailscale ang pinakatukoy na match. Kung nag-a-advertise ang router A ng 10.0.0.0/24 at ang router B ng 10.0.0.0/16, mapupunta sa A ang traffic papunta sa 10.0.0.20.

Ang nakapagtataka sa mga user ay ang behavior kapag offline si A. Hindi awtomatikong gumagamit ang Tailscale ng route na hindi gaanong partikular. Hihinto ang traffic papunta sa 10.0.0.20, habang magpapatuloy ang traffic papunta sa 10.1.0.20 sa pamamagitan ni B. Mukhang kalahati ng private network ang down, pero ang sanhi ay isang offline node na may hawak ng mas partikular na prefix. Kung kailangan mo ng failover, ipa-advertise rin sa mas malawak na router ang mas makikitid na prefix para pareho nilang saklaw ang parehong address.

Ang isa pang overlap ay mas malapit sa client. Kung nakakonekta ka sa hotel network sa 192.168.1.0/24 habang nag-a-advertise ang subnet router mo ng 192.168.1.0/24, maglalaban ang dalawang route para sa parehong destination. Depende sa platform kung alin ang mananalo. Sa Linux, mag-install ng rule bago ang sariling rule ng Tailscale para gumamit ang mga local address ng main table:

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

Hindi persistent ang rule na ito at mawawala sa susunod na boot. Ang tamang ayusin ay pumili ng private range na hindi mo makakasalamuha sa ibang network. Ang 192.168.0.0/24 at 192.168.1.0/24 ang default sa karamihan ng home router, kaya pumili ng range sa loob ng 10.0.0.0/8 na sinadya mong gamitin. Parehong problema ang sumisira sa plain WireGuard VPN na mano-mano mong kino-configure, dahil nananalo ang mas partikular na local route at hindi kailanman pumapasok sa tunnel ang traffic.

Failure mode: Nagre-resolve ang DNS sa address na walang route na sumasaklaw dito

Mahirap i-debug ang failure mode na ito dahil walang nag-uulat ng error. Nare-resolve ang pangalan, pero nagti-time out ang connection.

Ipagpalagay na ang db.internal.example.com ay nare-resolve sa 10.0.5.20 sa pamamagitan ng private nameserver, at in-advertise mo ang 10.0.0.0/24. Matagumpay ang lookup dahil magkahiwalay na hakbang ang DNS (domain name system) resolution at IP routing, at hindi sinusuri ng alinman sa mga ito ang isa pa. Pagkatapos, walang matching route sa tailnet para sa packet papunta sa 10.0.5.20, kaya lumalabas ito sa default gateway ng client at nawawala.

Paghiwalayin ang dalawang bahaging ito gamit ang dalawang command:

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

Kung nagbabalik ng address ang lookup pero hindi sumasagot ang ip route get gamit ang dev tailscale0, maayos ang pangalan at nawawala ang route. Mag-advertise ng range na sumasaklaw sa address, alinman sa 10.0.0.0/16 o sa isa pang explicit prefix, at pagkatapos ay i-approve ang bagong prefix sa console.

May katumbas na problema sa nameserver mismo. Kung nag-set ka ng global nameserver sa admin console sa isang private address gaya ng 10.0.0.53, dapat nasa loob ng approved route ang address na iyon. Kung hindi, hindi maaabot ng mga device ang resolver. Kapag in-on mo ang option na nag-o-override sa mga local DNS server habang nakaturo ito sa resolver na hindi maabot, mawawalan agad ng name resolution ang bawat device sa tailnet, kabilang ang mga gumagana isang segundo bago nito. I-advertise at i-approve muna ang route papunta sa resolver, saka baguhin ang DNS setting. Kung ang DNS sa loob ng tunnel ang paulit-ulit mong inaayos, ipinapaliwanag ng kung paano nasisira ang DNS sa WireGuard tunnel ang parehong mekanismo nang walang karagdagang coordination layer.

Source NAT at mga site-to-site link

Bilang default, nire-rewrite ng subnet router ang source address ng bawat forwarded packet gamit ang sarili nitong private address. Ito ang SNAT (source network address translation). Ginagawa ito upang gumana ang mga reply nang walang pagbabago sa private network: sinasagot ng database sa 10.0.0.20 ang VPS, na alam na nitong maabot. Ang kapalit nito, nakikita ng database na mula sa VPS ang bawat koneksyon sa tailnet. Dahil dito, walang silbi para sa iyo ang per-source firewall rules at access logs.

I-off ito sa Linux kapag gusto mong mapanatili ang tunay na tailnet address ng client:

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

Kailangan naman ng mga host sa private network ng route pabalik sa 100.64.0.0/10, ang range na itinatalaga ng Tailscale sa mga device, na nakaturo sa subnet router. Kung wala ang return route na ito, ipinapadala ng mga host ang kanilang reply sa default gateway at hindi ito nakararating. Dahil dito, nagha-hang ang mga koneksyon matapos ang unang packet. Idagdag ang static route sa gateway ng private network, o panatilihing naka-on ang SNAT.

Ang site-to-site link ay binubuo ng dalawang subnet router na sabay na gumagawa nito. Ang bawat isa ay nag-a-advertise ng sarili nitong network at tumatanggap ng network ng kabilang router:

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

Patakbuhin sa kabilang router ang katumbas na command gamit ang sarili nitong range. Dapat magkaiba ang dalawang range. Kung nagha-hang ang malalaking transfer habang maayos ang ssh at ping, MSS (maximum segment size) ang sanhi. Ito ang pinakamalaking data chunk na maaaring dalhin ng isang TCP packet. Dahil sa overhead ng tunnel, nagiging masyadong malaki ang mga forwarded packet para sa ilang link sa gitna. Maaayos ito ng clamping:

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

I-save ang rule na iyon gamit ang iptables-persistent, kung hindi mawawala ito sa susunod na boot.

Housekeeping para patuloy itong gumana

Nag-e-expire ang node keys pagkalipas ng 180 days bilang default, simula August 2026. Kapag nag-expire ang key sa isang subnet router, nagsa-sign out ang node at nagiging unreachable ang buong advertised range. Walang configuration change sa ibang bahagi ng system na magpapaliwanag dito. I-disable ang key expiry para sa machine na ito sa Machines page ng admin console, at itala na ginawa mo ito.

Mas pinipili ng Tailscale ang direktang connection sa pagitan ng peers. Kapag hindi ito makapagtatag ng direktang connection, gumagamit ito ng relay servers. Gumagana ang mga relay, pero nagdaragdag ang mga ito ng latency. Madali ang setup kapag may public address ang VPS: payagan ang inbound UDP 41641, at direktang makakakonekta ang karamihan sa mga peer. Kung ufw ang namamahala sa firewall, saklaw ng mga ufw rule na aktuwal na kailangan ng VPS ang syntax.

Ang access rules ang kabilang bahagi nito. Sa default na tailnet, maaaring kumonekta ang bawat device mo sa lahat ng iba mo pang device, kaya gagana agad ang isang aprubadong route. Kapag nagsulat ka ng ACL policy, kailangang pangalanan ng destination side ng rule ang private range, dahil ang 10.0.0.20 ay hindi tailnet address at hindi saklaw ng mga rule na ginawa batay sa tailnet IP o tags.

Panghuli, magpasya kung gusto mong gumamit ng coordination server na hindi mo pinapatakbo. Hosted service ang control plane ng Tailscale. Nananatili sa mga machine mo ang mga key mo, pero naroon ang account at policy file. Ang dapat mong suriin bago mo ito bigyan ng route papunta sa private network mo ay kung ano ang maaaring magawa ng isang taong nakompromiso ang control plane o nakakuha ng identity login. Tinutukoy ng trust model ng Tailscale kung saan nakalagay ang boundary na iyon. Bihirang gastos ang dahilan kung bakit iniiwan ito ng mga tao, dahil saklaw ng free plan ang hanggang anim na user na may walang limitasyong sariling device, bagaman iba ang pagbilang sa subnet router na inilunsad gamit ang tag kumpara sa subnet router na naka-sign in bilang ikaw. Paglampas sa limitasyong iyon, batay sa mga tao ang singil, hindi sa mga machine. Kaya makabubuting alamin muna kung magkano talaga ang babayaran ng isang household o five-person team kapag naubos na ang free plan bago idagdag ang account na magtutulak sa iyo lampas sa limitasyon. Sa pamamagitan ng Headscale, ang self-hosted Tailscale control server, mananatili ito sa sarili mong VPS, kapalit ng responsibilidad na i-maintain ito. Ang isa pang sagot sa parehong alalahanin ay ang pag-iwan din sa mga client ng Tailscale. Sa pamamagitan ng self-hosting ng NetBird VPN server, nasa isang machine na kontrolado mo ang coordination layer at ang sarili nitong mesh clients. Kung pinagpapasiyahan mo pa rin kung gagamitin ang modelong ito o ang mano-manong paggawa ng config, ipinapaliwanag ng paghahambing ng WireGuard at Tailscale kung ano ang ibinibigay ng coordination layer at kung ano ang kapalit nito.

FAQ

Ano ang pagkakaiba ng subnet router at exit node?

Ang subnet router ay nag-a-advertise ng range ng mga private address upang maabot ng mga device sa tailnet ang mga machine na hindi nagpapatakbo ng Tailscale. Ang exit node naman ay nag-a-advertise ng sarili nito bilang route papunta sa buong internet, kaya ipinapadala ng isang device ang lahat ng traffic nito sa public address ng node na iyon. Maaaring gumanap ang isang VPS bilang pareho. Magkahiwalay na flag ang --advertise-routes at --advertise-exit-node, at kailangan ng bawat isa ang sarili nitong approval sa admin console.

Bakit binabalewala ng Linux client ko ang ina-advertise na subnet route?

Hindi awtomatikong tumatanggap ng subnet route ang mga Linux client. Kailangan mo itong i-enable. Patakbuhin ang sudo tailscale set --accept-routes sa client. Pagkatapos, tingnan gamit ang ip route show table 52, hindi ang ip route show. Ini-install ng Tailscale ang mga tinanggap na route sa routing table 52 at inaabot ang mga ito sa pamamagitan ng policy rules. Kaya hindi lumalabas ang mga ito sa main table, at maaaring magmukhang nawawala ang gumaganang route.

Hindi na gumana ang subnet ko pagkatapos ng reboot. Ano ang nasira?

Malamang, IP forwarding. Hindi nananatili pagkatapos ng reboot ang value na itinakda gamit ang sysctl -w. Kaya isulat ito sa /etc/sysctl.d/99-tailscale.conf at kumpirmahin gamit ang sysctl net.ipv4.ip_forward. Kung naka-enable ang forwarding at hindi pa rin maabot ang range, tingnan ang node sa admin console. Bilang default, nag-e-expire ang node keys pagkalipas ng 180 days. Kapag nag-expire ang subnet router, para itong network fault sa halip na problema sa account.

Maaari bang mag-advertise ng parehong range ang dalawang subnet router?

Hindi kung eksaktong magkapareho ang mga range. Ayos ang mga overlapping range na magkaiba ang prefix length, at ang pinaka-specific na route ang ginagamit. Kailangan ng pag-iingat sa failover: kapag offline ang router na may mas specific na prefix, hindi awtomatikong lilipat ang Tailscale sa mas malawak na route. Kaya hihinto ang traffic na iyon. Para sa aktuwal na standby pair, ipa-advertise sa parehong router ang parehong specific prefixes.

Nagre-resolve ang hostname pero nagti-time out ang connection. Bakit?

Magkahiwalay na hakbang ang DNS resolution at routing. Maaaring mag-resolve ang isang pangalan sa address na hindi sakop ng anumang approved route. Pagkatapos, dadaan ang packet sa default gateway ng client. Patakbuhin ang ip route get <address> sa client. Kung hindi kasama sa resulta ang dev tailscale0, mag-advertise ng range na sumasaklaw sa address na iyon at aprubahan ang bagong prefix sa admin console.