Tailscale subnet router sa VPS: setup at routing

Ano ang ginagawa ng Tailscale subnet router

Ang Tailscale subnet router ay isang machine na nag-a-advertise ng buong range ng private IP address papunta sa tailnet, kaya maaabot ng bawat device sa tailnet ang mga address sa range na iyon kahit walang Tailscale na tumatakbo sa mga iyon.
Ang tailnet ay ang private Tailscale network mo: ang set ng mga device na naka-sign in sa isang account o organisation.
Ang exit node ang feature na kadalasang napagkakamalan dito, 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 ng exit node kung saan lumalabas ang public traffic mo.
Kung ang pangalawa ang kailangan mo, basahin ang kung paano magpatakbo ng Tailscale exit node sa isang VPS sa halip.
Magkahiwalay ang mga flag ng mga ito, at maaaring gawin ng isang VPS ang dalawang function nang sabay, pero magkaiba ang problemang nilulutas nila at magkaiba rin ang mga paraan ng pag-fail nila.

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 second interface ito sa isang private segment. Walang public address ang ibang server sa segment na iyon: may database sa 10.0.0.20 at backup target sa 10.0.0.30. Mag-install ng Tailscale sa isang VPS at i-advertise ang 10.0.0.0/24. Maaabot ng iyong laptop ang mga private address na iyon nang direkta. Walang ibang kailangang baguhin sa segment, at mananatiling walang public address ang database.

Ang isa pang sitwasyon ay isang network na nasa kabilang panig ng VPS. Maaaring home o office LAN (local area network) ito na nasa likod ng sarili nitong router, o 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 magiging subnet router para sa lahat ng iba pang device doon.

Pareho sa mga sitwasyong ito ang isang requirement. Dapat kaya nang maabot ng subnet router ang range na ina-advertise nito, gamit ang sarili nitong routing table at firewall. Hindi ginagawa ng Tailscale ang connection na iyon. Dinadala nito ang traffic sa router at ipinapasa ito sa kernel para i-forward.

I-install ang Tailscale at suriin muna ang local route

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

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

Bago ang lahat, tiyaking naaabot 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 mismong router, walang Tailscale flag na makalulutas nito. Ang problema ay nasa network configuration ng VPS o sa firewall ng target host. Ayusin muna ito dahil nakadepende rito ang lahat ng susunod na test.

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

Dina-drop ng Linux machine ang anumang packet na hindi nakatalaga rito maliban kung naka-on ang forwarding. Ang pagpapasa ng mga packet ng ibang machine ang pangunahing tungkulin ng subnet router, kaya hindi optional 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 kalahati lang ang tama sa hakbang na ito. Agad gumagana ang sudo sysctl -w net.ipv4.ip_forward=1, pero nawawala ito sa susunod na boot. Dahil dito, tumatakbo nang ilang linggo ang subnet router at humihinto sa umaga matapos ang 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, pero dini-drop ang mga ito ng kernel nang walang anumang log. Ang pagsusulat ng mga value sa /etc/sysctl.d/99-tailscale.conf ang nagbabalik sa mga ito pagkatapos ng reboot.

Kung nag-a-advertise ka ng mga route habang naka-off pa ang forwarding, magbibigay ng warning ang tailscale up sa oras na iyon, na may linyang kahawig ng Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. Basahin ang output ng command na iyon sa halip na laktawan 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 ang setting sa mismong lugar:

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

Gamitin ang tailscale set para sa lahat ng susunod na pagbabago. Kapag muling pinatakbo ang tailscale up gamit ang isang flag lang, mare-reset ang mga flag na hindi mo isinama. Ihihinto ka ng CLI at magpapakita ng error na nagsasabing kailangang banggitin ang lahat ng non-default flag kapag ganitong paraan ang ginagamit sa pagbabago ng mga setting. Binabago ng tailscale set ang isang setting at hindi nito ginagalaw ang iba.

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

Aprubahan ang route sa admin console

Ang pag-advertise ng route ay isang request, hindi pagbabago. Hangga't hindi ito inaaprubahan ng isang admin, walang client na makakatanggap ng route at walang maaabot sa loob ng range. Sinasadya ito dahil maaaring makuha ng isang machine na puwedeng magdagdag ng sarili nito sa routing table ng lahat ang traffic para sa kahit anong 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, lagyan ng check ang route, at i-save.

Bawat prefix ay hiwalay na inaaprubahan. I-advertise ang 10.0.0.0/24 ngayon at ang 192.168.50.0/24 sa susunod na buwan, at mananatiling hindi aprubado ang bagong prefix habang patuloy na gumagana ang luma. Magkapareho ang itsura ng approved route at ignored route mula sa VPS, kaya tingnan muna ang console bago mag-debug ng iba pa.

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-boot 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 sandaling ma-advertise ito. Kailangang umiiral 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 magsisimulang hindi aprubado ang mga route nito.

Bakit binabalewala ng mga Linux client ang route kapag walang --accept-routes

Na-advertise at naaprubahan na ang route. Maa-access ng phone at Mac mo ang 10.0.0.20. Hindi ito ma-access ng Linux laptop mo, at walang ipinapakitang problema ang admin console.

Ang pagtanggap ng subnet route ay nangangahulugang paglalagay 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 kadalasang server o router ang Linux machine, at sadyang kino-configure ng administrator ang routing table nito. 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 napunta 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 katugmang route sa table na iyon. Kaya hindi kailanman ililista ng ip route show lamang ang 10.0.0.0/24. Kung ang command na iyon lang ang susuriin ng reader, iisipin niyang walang ginawa ang --accept-routes. Ang ip route show table 52 ang command na nagpapakita ng aktuwal na resulta, at dapat nitong ilista ang advertised range sa tailscale0.

May isang exception na dapat malaman. Kung ang Linux node na ito ay siya ring second subnet router para sa sarili nitong local network, ipapadala ng --accept-routes ang traffic para sa sarili nitong directly connected subnet sa kabilang router sa halip na palabasin ito sa sarili nitong interface. Sa isang standby router na bahagi ng high availability pair, iwanang naka-off ang --accept-routes at mag-advertise lamang.

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

Hindi dapat mag-anunsyo ang dalawang subnet router ng magkakaparehong range. Pinapayagan ang mga range na nag-o-overlap pero magkaiba ang prefix length, at pinipili ng Tailscale ang pinakatukoy na match. Kapag ina-advertise ng router A ang 10.0.0.0/24 at ng router B ang 10.0.0.0/16, napupunta sa A ang traffic para sa 10.0.0.20.

Ang nakakagulat ay ang behavior kapag offline si A. Hindi nagfa-fallback ang Tailscale sa route na hindi gaanong tukoy. Humihinto ang traffic para sa 10.0.0.20, habang patuloy na gumagana sa pamamagitan ni B ang traffic para sa 10.1.0.20. Para bang kalahati ng private network ang down, pero ang sanhi ay isang offline node na may hawak ng mas tukoy na prefix. Kung kailangan mo ng failover, ipa-advertise rin sa mas malawak na router ang mas makikitid na prefix, para pareho nilang masaklaw ang parehong address.

Mas malapit sa client ang isa pang uri ng overlap. Kapag nasa hotel network ka sa 192.168.1.0/24 habang ina-advertise ng subnet router mo ang 192.168.1.0/24, nagkukumpitensya ang dalawa para sa parehong destination, at depende sa platform kung alin ang mananalo. Sa Linux, mag-install ng rule bago ang sariling rule ng Tailscale para gamitin ng mga local address ang main table:

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

Hindi persistent ang rule na iyon at mawawala sa susunod na boot. Ang tamang solusyon ay pumili ng private range na hindi mo karaniwang makikita sa ibang network. 192.168.0.0/24 at 192.168.1.0/24 ang mga default sa karamihan ng home router, kaya pumili ng range sa loob ng 10.0.0.0/8 na sinadya mong gamitin. Pareho ring nasisira ng collision na ito ang plain WireGuard VPN na mano-mano mong kino-configure, sa parehong dahilan: nananalo ang mas tukoy na local route, kaya hindi pumapasok sa tunnel ang traffic.

Failure mode: DNS nagre-resolve sa address na walang sakop na route

Mahirap i-debug ang kasong ito dahil walang nag-uulat ng error. Nare-resolve ang pangalan. Nagti-time out ang connection.

Ipagpalagay na nare-resolve ang db.internal.example.com sa 10.0.5.20 sa pamamagitan ng private nameserver, at inanunsyo 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 tumutugmang route sa tailnet para sa packet papunta sa 10.0.5.20, kaya lumalabas ito sa default gateway ng client at nawawala.

Gamitin ang dalawang command na ito upang paghiwalayin ang dalawang bahaging ito:

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-anunsyo ng range na sumasaklaw sa address, alinman sa 10.0.0.0/16 o isang ikalawang explicit prefix, pagkatapos ay aprubahan ang bagong prefix sa console.

May katumbas na trap sa mismong nameserver. Kung nagtakda ka ng global nameserver sa admin console sa isang private address gaya ng 10.0.0.53, kailangang nasa loob ng approved route ang address na iyon; kung hindi, hindi maaabot ng iyong mga device ang resolver. Kapag ini-on mo ang option na nag-o-override sa mga local DNS server habang tumuturo sa resolver na hindi maabot ng mga device, sabay-sabay mawawalan ng name resolution ang bawat device sa tailnet, kabilang ang mga gumagana isang sandali pa lang ang nakalipas. I-advertise at aprubahan muna ang route papunta sa resolver, saka baguhin ang DNS setting. Kung DNS sa loob ng tunnel ang paulit-ulit mong inaayos, ipinapaliwanag ng kung paano nasisira ang DNS sa WireGuard tunnel ang parehong mechanism nang walang dagdag na 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. Iyon ang SNAT (source network address translation). Ginagawa ito para gumana ang mga reply nang walang kailangang baguhin sa private network: sumasagot ang database sa 10.0.0.20 sa VPS, na alam na nitong maabot. Ang kapalit nito, nakikita ng database na mula sa VPS ang bawat tailnet connection. Kaya walang silbi ang per-source firewall rules at access logs para tukuyin ang orihinal na source.

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

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

Kailangang may route pabalik sa 100.64.0.0/10 ang mga host sa private network. Ito ang range na itinatalaga ng Tailscale sa mga device. Dapat tumuro ang route sa subnet router. Kung wala ang return route na ito, ipinapadala ang mga reply sa default gateway at hindi nakararating. Dahil dito, nagha-hang ang mga connection pagkatapos ng unang packet. Idagdag ang static route sa gateway ng private network, o panatilihing naka-on ang SNAT.

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

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

Patakbuhin ang katumbas na command sa kabilang router 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 pagitan. Inaayos 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 key 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 in-advertise na range. Walang configuration change sa ibang lugar 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 gusto ng Tailscale ang direct connection sa pagitan ng mga peer at gumagamit ito ng relay server kapag hindi ito makakuha ng direct connection. 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 para direktang makakonekta ang karamihan sa mga peer. Kung ufw ang nagma-manage ng firewall, saklaw ng mga ufw rule na aktuwal na kailangan ng VPS ang syntax.

Ang access rule ang kabilang bahagi. Sa default na tailnet, maaaring ma-access ng bawat device mo ang lahat ng iba pang device, kaya gumagana agad ang isang approved route. Kapag nagsulat ka ng ACL policy, kailangang tukuyin 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 nakasulat batay sa tailnet IP o tag.

Panghuli, magpasya kung gusto mo ng coordination server na hindi ikaw ang nagpapatakbo. Hosted service ang control plane ng Tailscale. Nananatili ang mga key mo sa sarili mong machine, pero nasa service na iyon ang account at policy file. Sa pamamagitan ng Headscale, ang self-hosted Tailscale control server, nananatili ito sa sarili mong VPS, kapalit ng responsibilidad na i-maintain ito. Ang isa pang sagot sa parehong alalahanin ay iwanan din ang mga client ng Tailscale at gamitin ang self-hosting ng NetBird VPN server, na naglalagay ng coordination layer at sarili nitong mesh client sa isang machine na kontrolado mo. Kung pinagpapasyahan mo pa kung gagamitin ang modelong ito o ang mano-manong configuration, ipinapaliwanag ng paghahambing ng WireGuard at Tailscale kung ano ang ibinibigay ng coordination layer at 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, kaya maaabot 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 palabas sa public address ng node na iyon. Maaaring gampanan ng isang VPS ang parehong papel. Magkahiwalay na flag ang mga ito, --advertise-routes at --advertise-exit-node, at kailangan ng bawat isa ng sariling approval sa admin console.

Bakit binabalewala ng Linux client ko ang advertised 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. Dahil dito, hindi nakalista ang mga ito sa main table at maaaring magmukhang nawawala ang gumaganang route.

Huminto sa paggana ang subnet ko matapos ang reboot. Ano ang nasira?

Malamang, IP forwarding. Hindi nananatili matapos ang 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 ngunit hindi pa rin reachable ang range, tingnan ang node sa admin console. Nag-e-expire ang node key makalipas ang 180 days bilang default. Kapag nag-expire ang subnet router, nagmumukha itong network fault sa halip na problema sa account.

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

Hindi kung eksaktong magkapareho ang mga range. Ayos ang magkakapatong na range na magkaiba ang prefix length, at mananalo ang pinakaspesipiko. Kailangan ng maingat na configuration para sa failover: kapag offline ang router na may mas spesipikong 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 magkakaparehong spesipikong prefix.

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

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