Paano gawing Tailscale exit node ang iyong VPS

Ano ang ginagawa ng Tailscale exit node

Ang Tailscale exit node ay isang machine sa iyong tailnet na nagdadala ng lahat ng internet traffic para sa iba mong device. Mainam na exit node ang isang VPS (virtual private server) dahil mayroon itong fixed public address at patuloy itong online. Limang hakbang ang pag-set up nito: i-install ang Tailscale sa server, i-advertise ang exit node, i-enable ang IP forwarding, aprubahan ang route sa admin console, at piliin ang node sa iyong laptop. Ang ikaapat na hakbang ay isang toggle sa web page at hindi isang command. Dito kadalasang natitigil ang mga user.

Kapag naka-enable na ito, ini-encrypt ng iyong laptop ang bawat packet at ipinapadala ito sa VPS. Isinasagawa ng VPS ang source NAT (network address translation) at ipinapadala ang packet gamit ang sarili nitong public IP address. Ang nakikita ng mga website ay ang VPS. Isang encrypted UDP flow lang papunta sa VPS ang nakikita ng café Wi-Fi, at wala nang iba.

Ang Tailscale ay WireGuard para sa data path, kasama ang isang coordination server na namamahagi ng mga key at tumutulong sa dalawang machine na mahanap ang isa’t isa sa pamamagitan ng NAT. Dahil sa coordination server na iyon, walang kailangang kopyahang key sa mga susunod na hakbang. Para sa mas kumpletong paliwanag ng mga trade-off, basahin ang paghahambing ng Tailscale at plain WireGuard. Kung mas gusto mong ikaw ang mamahala sa bawat bahagi ng tunnel, mag-self-host ng plain WireGuard VPN sa iyong VPS.

Ipinapalagay sa mga hakbang sa ibaba na tumatakbo na ang Tailscale sa iyong laptop at parehong naka-sign in ang dalawang machine sa iisang tailnet. Ang tailnet ay ang iyong pribadong Tailscale network, at bawat device dito ay nakakakuha ng stable na address sa loob ng 100.64.0.0/10.

I-install ang Tailscale sa iyong VPS

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

Pinipili ng install script ang package repository para sa iyong distribution at ini-install ang tailscaled daemon. Pagkatapos, nagpi-print ang tailscale up ng authentication URL. Buksan ito sa browser at mag-sign in gamit ang parehong account na ginagamit ng iyong laptop, dahil hindi makapagsisilbi sa iyong laptop ang VPS na naka-sign in sa ibang tailnet.

tailscale status
tailscale ip -4

Dapat nang ilista ng tailscale status ang dalawang machine. Ipinapakita ng tailscale ip -4 ang tailnet address ng VPS. Ito ang ibibigay mo sa client sa susunod.

Kailangan ng Tailscale ng TUN device para mabuo ang tunnel. Sa KVM VPS, naroon ang device. Sa mga planong gumagamit ng container virtualisation at nakikibahagi sa host kernel, kung minsan ay wala ang /dev/net/tun, kaya hindi magawa ng tailscaled ang tailscale0 interface. Patakbuhin ang ls -l /dev/net/tun bago magpatuloy.

I-enable ang IP forwarding, kung hindi, ibabagsak ng VPS ang bawat packet

Ibinabagsak ng Linux machine ang anumang packet na hindi nakatalaga sa sarili nito, dahil 0 ang default na value ng net.ipv4.ip_forward. Tatanggapin ng exit node ang traffic mo, ide-decrypt ito, at pagkatapos ay ibabagsak. Isulat ang setting sa isang file para manatili ito pagkatapos ng reboot.

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

Nag-a-append ang tee -a, kaya kapag pinatakbo mo ulit ang mga linyang ito, dalawang beses nitong isusulat ang parehong settings. Gagana pa rin ang resulta, pero magiging kakaiba ang itsura ng cat /etc/sysctl.d/99-tailscale.conf. Kumpirmahin ang live value sa halip na basta umasa sa file:

sysctl net.ipv4.ip_forward

Dapat nitong i-print ang net.ipv4.ip_forward = 1. Kung lalaktawan mo ito at gagamitin ang tailscale up --advertise-exit-node, sasabihin sa iyo ng client:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

Hindi ginagawa ng tailscale set --advertise-exit-node ang check na iyon, kaya ang walang output mula sa set ay hindi patunay na naka-enable ang forwarding. Basahin mismo ang sysctl value.

Hindi mo kailangang manu-manong magsulat ng masquerade rule. Nag-i-install ang tailscaled ng sarili nitong firewall chains na pinangalanang ts-input, ts-forward, at ts-postrouting. Nasa ts-postrouting ang NAT rule para sa exit node traffic. Tingnan ang mga ito gamit ang sudo iptables-save | grep ts-, o sudo nft list ruleset kung nftables ang ginagamit ng system.

I-anunsyo ang VPS bilang exit node

sudo tailscale set --advertise-exit-node

Binabago ng tailscale set ang isang preference at iniiwan ang iba sa kasalukuyang setting. Ina-anunsyo rin ng tailscale up --advertise-exit-node ang node, ngunit may side effect ito: itinuturing ng up na ang mga flag sa command line nito ang kumpletong set ng mga setting na hindi default. Dahil dito, tatangging tumakbo ang kasunod na bare sudo tailscale up at ipi-print nito ang

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Gamitin ang set para sa mga kasunod na pagbabago at hindi mo makikita ang mensaheng iyon.

Ang pag-anunsyo ay isang alok. Sinasabi na ngayon ng VPS sa coordination server na handa itong maging exit node. Hindi pa ito magagamit ng anumang client.

Aprubahan ang Tailscale exit node sa admin console

Ito ang hakbang na walang command. Buksan ang Machines page sa admin console, hanapin ang VPS, buksan ang three-dot menu sa dulo ng row nito, piliin ang Edit route settings, at i-on ang Use as exit node.

Hangga't hindi naka-on ang toggle na ito, iniimbak ng control plane ang offer at hindi ito ibinibigay sa kahit kanino. Walang ipinapakita ang tailscale exit-node list sa laptop mo, at nananatili sa normal na route ang traffic mo. Wala ring error message sa alinmang machine. Hindi lang lumilitaw ang exit node.

Maaari mong awtomatikong aprubahan ang exit nodes gamit ang entry sa tailnet policy file:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

Ang device na na-bring up gamit ang --advertise-tags=tag:exit ay awtomatikong maaaprubahan, basta nakadefine ang tag:exit sa ilalim ng tagOwners sa parehong policy file. Binabago ng tagging ang ownership: kabilang ang tagged device sa tailnet sa halip na sa user account mo, at nagbabago rin ang mga access rule na nalalapat dito. Para sa isang VPS, mas simple ang toggle.

Piliin ang exit node sa iyong laptop

Sa Linux client:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

Ipinapakita ng exit-node list ang mga aprubadong exit node sa iyong tailnet kasama ang mga address ng mga ito. Kapag walang laman ang listahan, hindi naisagawa ang approval step. Sa macOS, Windows, iOS, at Android, makikita ang parehong pagpipilian bilang menu item sa ilalim ng Exit Node sa Tailscale app.

I-verify ito mula sa client, hindi mula sa server:

curl -4 https://ifconfig.me

Patakbuhin ito nang isang beses bago piliin ang exit node at isang beses pagkatapos nito. Dapat magbago ang address mula sa iyong lokal na address patungo sa public IP ng VPS. Para ihinto ang paggamit ng exit node:

sudo tailscale set --exit-node=

May isa pang flag na mahalaga sa unang araw. Kapag may napiling exit node, ipinapadala ng client ang lahat ng traffic sa tunnel, kabilang ang mga packet na nakalaan para sa 192.168.1.50, kaya hindi na sasagot ang iyong printer at network storage. Panatilihin ang lokal na network sa lokal na route:

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

Bakit nagbabago ang DNS kapag naka-on ang exit node

Bilang default, ginagamit din ng device na gumagamit ng exit node ang exit node na iyon bilang DNS (domain name system) resolver para sa bawat domain. Ino-override nito ang global at split DNS nameserver na naka-configure para sa iyong tailnet. Sinasadya ang behavior na ito. Kung patuloy na pupunta ang mga query sa resolver ng local network, makikita pa rin ng café router ang pangalan ng bawat site na binibisita mo kahit private ang mismong traffic. Dapat sa iisang lugar manggaling ang mga pangalan at packet.

May isang epekto ito para sa mga nagpapatakbo ng internal resolver: hindi na ginagamit ang tailnet nameserver na kailangan mo habang naka-on ang exit node. I-on ang Use with exit node para sa nameserver na iyon sa DNS page ng admin console upang magamit itong muli.

Patuloy na gumagana ang mga MagicDNS name dahil lokal na sinasagot ng Tailscale client ang mga ito sa 100.100.100.100 bago makarating ang anumang bagay sa exit node. Suriin ito gamit ang dig @100.100.100.100 your-vps.your-tailnet.ts.net, o sa systemd-resolved client gamit ang resolvectl status, kung saan inililista ng Tailscale interface ang 100.100.100.100 bilang DNS server nito.

Kung idi-disable mo ang DNS handling ng Tailscale gamit ang --accept-dns=false, pananatilihin ng client ang resolver na natutuhan nito mula sa local network. Tunnelle ang traffic ngunit hindi ang mga query, kaya ito ang parehong DNS leak na nakaaapekto sa mga manually built na WireGuard tunnel. Huwag baguhin ang --accept-dns maliban kung mayroon kang partikular na dahilan.

IPv6 sa exit node

Ina-advertise ng exit node ang parehong default route, 0.0.0.0/0 at ::/0. Kung walang gumaganang IPv6 path papunta sa internet ang VPS, dumarating ang IPv6 packet sa tunnel at doon ito humihinto. Mag-test muna sa VPS bago mo ito pagkatiwalaan:

ip -6 addr show
curl -6 https://ifconfig.me

Ibig sabihin ng failed request ay walang IPv6 upstream ang VPS. Karaniwan pa ring naglo-load ang mga dual-stack website dahil sumusuko ang client sa IPv6 at muling sumusubok gamit ang IPv4. Gayunman, nagdudulot ang retry na ito ng delay sa unang connection sa bawat site. Mananatiling hindi maaabot ang mga IPv6-only na destination.

Ang kabilang bahagi ay ang forwarding. Kapag iniwan sa 0 ang net.ipv4.ip_forward = 1 at net.ipv6.conf.all.forwarding, magkakaroon ka ng gumaganang IPv4 path pero black hole para sa IPv6. Ang mararanasan ng reader ay “mabagal ang ilang site,” sa halip na error na madaling hanapan ng solusyon. Dapat nasa sysctl file ang parehong linya.

Dapat bang i-advertise din ng VPS ang mga subnet route?

Dala ng exit node ang lahat ng internet traffic. Ang subnet route ay isang private range na nasa likod ng machine na nag-a-advertise nito. Magkahiwalay ang mga feature na ito at magkahiwalay din ang approval, pero maaaring gawin ng iisang machine ang dalawa.

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

Mag-advertise ng subnet kapag may private network na kapareho ng network ng VPS, at may iba pang server dito na gusto mong maabot gamit ang kanilang private address. I-approve ito sa parehong Edit route settings panel, gamit ang sarili nitong toggle.

Maingat na piliin ang range. Mas specific ang advertised route kaysa sa default route ng laptop mo. Kaya kapag in-advertise ng VPS ang 192.168.1.0/24, makokontrol nito ang mga address ng home network na gumagamit ng kaparehong range, at mawawalan ng koneksyon ang mga device sa desk mo. Gumamit ng range na ikaw ang pumili, hindi ang range na awtomatikong pinili ng home router mo.

Gawing mabilis ang exit node gamit ang UDP GRO forwarding

Ang Tailscale 1.54 at mas bagong bersyon, kapag gumagamit ng Linux 6.2 o mas bagong kernel, ay maaaring gumamit ng receive offload para pataasin ang throughput ng forwarded traffic. Pinagsasama ng GRO (generic receive offload) ang mga papasok na packet bago isa-isang iproseso ng kernel. Noong August 2026, manual step pa rin ito sa exit node.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

Iniuulat ng ip -o route get 8.8.8.8 ang interface na aktuwal na kumokonekta sa internet, kaya hindi mo kailangang manghula sa pagitan ng eth0, ens3, at enp1s0. Kumpirmahin gamit ang ethtool -k $NETDEV | grep udp-gro-forwarding, na dapat ay on na ang nakalagay.

Nawawala ang setting pagkatapos ng reboot. Sa system na gumagamit ng networkd-dispatcher, gawin itong awtomatiko:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Suriin muna kung mayroon ang /etc/networkd-dispatcher/routable.d/. Kung wala ito, hindi gumagamit ang machine ng networkd-dispatcher. Sa halip, magpatakbo ng maliit na systemd unit ng linyang ethtool sa boot upang gawin ang parehong trabaho.

Ang ibig sabihin ng acceptable use policy ng iyong provider para sa exit traffic

Ang bawat packet na ipinapadala ng client sa pamamagitan ng exit node ay lumalabas gamit ang public IP address ng VPS, kaya iniuugnay ito sa iyong account. Sa iyong inbox darating ang mga abuse report, gaya ng copyright notice at reklamo tungkol sa port scan. Basahin ang AUP (acceptable use policy) ng iyong provider bago i-route ang traffic ng isang household o team sa iisang server. Huwag magbukas ng exit node para sa mga taong hindi mo kayang panagutan.

Dalawang beses binibilang ang bandwidth. Dumarating ang traffic sa VPS sa pamamagitan ng tunnel at umaalis itong muli patungo sa internet. Karaniwang parehong ibinabawas ang dalawang direksyon sa transfer allowance ng plan. Mas malaki sa inaasahan ng karamihan ang bandwidth na ginagamit ng video stream kapag pinapanood ito sa pamamagitan ng exit node.

May reputasyon din ang mga address range ng datacenter. Mas maraming CAPTCHA ang ipinapakita ng ilang site sa mga address na ito, at tahasang tinatanggihan ng ilang streaming service ang mga ito. Walang mababago rito ang configuration mo dahil katangian ito ng address block na pagmamay-ari ng iyong provider.

Bakit lumalabas pa rin ang traffic sa iyong local connection

Naka-advertise ang exit node pero hindi ito naaprubahan. Walang inilalabas na resulta ang tailscale exit-node list sa client, at walang machine na nagla-log ng error. Pumunta sa Machines page at i-enable ang Use as exit node.

Hindi ito pinili ng client. Ginagawang available ng approval ang node sa tailnet. Hiwalay na action ang pagpili nito sa bawat device. I-run muli ang sudo tailscale set --exit-node=<name>, pagkatapos ay suriin ulit ang curl -4 https://ifconfig.me.

Naka-off ang forwarding. Tiyak ang sintomas: nagtatagumpay ang tailscale ping <vps>, malinaw na gumagana ang tunnel, pero nagti-time out ang bawat external address. 0 ang inilalabas ng sysctl net.ipv4.ip_forward. Ayusin ang sysctl file, pagkatapos ay i-run ang sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

Hinaharang ng firewall ang mga forwarded packet. Gumagawa ang tailscaled ng sarili nitong ts-forward chain, at sapat na ito sa isang malinis na VPS. Sa isang machine na gumagamit na ng ufw o Docker, maaaring maging DROP ang FORWARD policy at maaaring mauna ang mga rule nito sa mga rule ng Tailscale. Huwag hulaan kung alin ang sanhi: i-run ang sudo iptables -L FORWARD -n -v habang sinusubukan ng client na mag-load ng page, at tingnan kung aling mga counter ang gumagalaw. Sa isang ufw machine, ang karaniwang fix ay DEFAULT_FORWARD_POLICY="ACCEPT" sa /etc/default/ufw, na sinusundan ng sudo ufw reload. Suriin din ang network firewall ng iyong provider sa control panel, dahil hiwalay itong control sa anumang tumatakbo sa server.

Gumagana ito pero mabagal. I-run ang tailscale netcheck sa parehong machine. Kung iniulat nitong blocked ang UDP, hindi makabuo ng direct path ang dalawang device at lilipat ang mga ito sa DERP relay, na nagdaragdag ng latency sa bawat connection. Karaniwang naibabalik ang direct path kapag pinayagan ang inbound UDP sa port 41641 papunta sa VPS sa network firewall ng provider.

Kailan dapat iwan ang coordination server ng Tailscale

Ang lahat ng nasa itaas ay nakadepende sa hosted coordination server ng Tailscale para sa key exchange at sa approval na iyong pinindot. Direktang dumadaloy ang traffic mo mula laptop papunta sa VPS, at hindi ito dumadaan sa coordination server. Gayunman, ito ang nagtatakda kung sino ang maaaring sumali sa tailnet at kung aling device ang maaaring maabot ng bawat isa. Kung ang dependency na ito ang gusto mong alisin, patakbuhin ang Headscale bilang sarili mong Tailscale control server at ituro rito ang parehong client. Pareho pa rin ang mga hakbang para sa exit node pagkatapos nito. Isasagawa lamang ang route approval sa pamamagitan ng command line ng Headscale sa halip na sa hosted console. Pinapalitan ng Headscale ang control plane, ngunit nananatili kang gumagamit ng Tailscale clients. Kung mas gusto mong ikaw mismo ang magpatakbo ng buong stack, may sarili itong coordination server at clients ang NetBird na maaari mong i-host sa isang VPS.

FAQ

Bakit gumagamit pa rin ng local connection ang traffic ko matapos kong piliin ang exit node?

May dalawang karaniwang sanhi. Na-advertise ang exit node pero hindi ito na-approve: buksan ang Machines page sa admin console, hanapin ang VPS, piliin ang Edit route settings, at i-on ang Use as exit node. Console toggle ang approval, at walang command sa server na gumagawa nito. Ang ikalawang sanhi ay iba ang sintomas: naka-off ang IP forwarding, kaya umaangat ang tunnel, gumagana ang tailscale ping papunta sa VPS, pero nagti-time out ang bawat external address. Suriin ito gamit ang sysctl net.ipv4.ip_forward, na dapat magbasa ng 1.

Kailangan ko bang manual na i-approve ang exit node sa bawat pagkakataon?

Isang beses lang kailangang gamitin ang toggle para sa bawat machine. Kung madalas mong nire-rebuild ang VPS, magdagdag ng autoApprovers block sa tailnet policy file na naglalaman ng "exitNode": ["tag:exit"], mag-define ng tag:exit sa ilalim ng tagOwners, at i-start ang node gamit ang --advertise-tags=tag:exit. Ang tagged device ay pagmamay-ari ng tailnet, hindi ng user account mo, kaya nagbabago rin ang mga access rule na nalalapat dito.

Aling DNS server ang ginagamit ng laptop ko kapag naka-enable ang exit node?

Ang exit node mismo. Ang device na gumagamit ng exit node ay nagpapadala roon ng lahat ng DNS query, at nao-override nito ang global at split DNS nameserver na itinakda para sa tailnet. Pinipigilan nitong makita ng local network ang mga pangalang tina-lookup mo. Para patuloy na malapat ang isang tailnet nameserver, i-enable ang Use with exit node para rito sa DNS page ng admin console. Nari-resolve pa rin ang mga MagicDNS name dahil lokal na sinasagot ng Tailscale client ang mga ito sa 100.100.100.100.

Maaari bang maging exit node at subnet router ang isang VPS nang sabay?

Oo. Magkahiwalay ang sudo tailscale set --advertise-exit-node at sudo tailscale set --advertise-routes=10.0.0.0/24, at bawat isa ay may sariling approval toggle sa ilalim ng Edit route settings. Kailangang naka-enable ang IP forwarding sa VPS para sa dalawang ito. Iwasang mag-advertise ng range na tumutugma sa home network ng laptop mo, dahil mas specific ang advertised route kaysa sa default route at magiging hindi reachable ang mga local device mo.

Itinatago ba ng exit node ang traffic ko sa VPS provider ko?

Hindi. Nagtatapos ang tunnel sa VPS, kaya lumalabas ang traffic sa server sa anyong inaasahan ng destination, at ipinapadala ito ng provider mo nang walang encryption saanman hindi encrypted ang mismong site. Inililipat ng exit node ang punto kung saan sumasali ang traffic mo sa internet—mula sa network na ginagamit mo papunta sa server na nirerentahan mo. Itinatago nito ang browsing mo mula sa café Wi-Fi at sa home ISP mo, pero ipinapakita nito ang parehong browsing sa VPS provider mo na kasama ang pangalan ng account mo.