WireGuard vs Tailscale vs Headscale: எது சிறந்தது?

WireGuard மற்றும் Tailscale: சுருக்கமான பதில்

WireGuard மற்றும் Tailscale ஆகியவற்றுக்கு இடையேயான தேர்வு என்பது இரண்டு வெவ்வேறு protocols-க்கு இடையேயான தேர்வு அல்ல, ஏனெனில் Tailscale என்பது அடிப்படையில் WireGuard-தான். Tailscale அதே encryption மற்றும் tunnel-ஐப் பயன்படுத்துகிறது, அதனுடன் ஒரு control plane-ஐச் சேர்க்கிறது: இது public keys-ஐப் பரிமாறிக்கொள்ளவும், IP addresses-ஐ வழங்கவும், NAT (network address translation) மூலம் துளைகளை உருவாக்கவும் (hole punching), மற்றும் access policy-ஐச் செயல்படுத்தவும் உதவும் ஒரு coordination server ஆகும். இந்த coordination-ஐ நீங்கள் எந்த அளவுக்கு நீங்களே நிர்வகிக்க விரும்புகிறீர்கள் என்பதையே நீங்கள் தேர்வு செய்கிறீர்கள்.

இதற்கு மூன்று தெளிவான பதில்கள் உள்ளன. உங்களிடம் ஒரு server மற்றும் அதைத் தொடர்புகொள்ளும் சில clients மட்டுமே இருந்தால், plain WireGuard-ஐப் பயன்படுத்தவும். எந்தவொரு config file-ஐயும் பராமரிக்காமல், ஒவ்வொரு machine-ம் மற்ற அனைத்து machine-களையும் அடைய வேண்டும் எனில், Tailscale-ஐப் பயன்படுத்தவும். உங்களுக்கு அத்தகைய mesh அமைப்பு தேவை, ஆனால் node list-ஐ மூன்றாம் தரப்பு நிறுவனம் வைத்திருக்கக்கூடாது எனில், Headscale-ஐப் பயன்படுத்தவும்.

கட்டுப்பாட்டு தளம் (control plane) உங்களுக்கு உண்மையில் என்ன வழங்குகிறது

சாதாரண WireGuard-ல் discovery வசதி கிடையாது. ஒவ்வொரு peer-ம் நீங்கள் கையால் எழுதும் ஒரு உரைத் தொகுப்பு: ஒரு public key, ஒரு AllowedIPs வரி, மற்றும் அந்த peer-ஐ அணுக முடிந்தால் ஒரு Endpoint. பத்து இயந்திரங்கள் கொண்ட ஒரு நெட்வொர்க்கில் ஒரு புதிய இயந்திரத்தைச் சேர்ப்பது என்பது பத்து config கோப்புகளைத் திருத்துவதாகும், ஏனெனில் ஒவ்வொரு பக்கமும் மற்றொன்றின் key-ஐக் கொண்டிருக்க வேண்டும். இதனால்தான் பெரும்பாலான self-hosted WireGuard அமைப்புகள் hub and spoke முறையில் உள்ளன: ஒரு public IP கொண்ட server, மற்றும் அதனுடன் மட்டுமே தொடர்பு கொள்ளும் clients.

ஒரு கட்டுப்பாட்டு தளம் இந்தத் திருத்தங்களை நீக்குகிறது. ஒவ்வொரு node-ம் ஒருமுறை பதிவு செய்து, 100.64.0.0/10 CGNAT (carrier grade NAT) வரம்பிலிருந்து ஒரு முகவரியைப் பெறுகிறது, மேலும் அது தொடர்பு கொள்ள அனுமதிக்கப்பட்ட node-களின் public key-கள் அதற்குத் தெரிவிக்கப்படுகின்றன. tunnel என்பது இன்னும் இரண்டு peer-களுக்கு இடையே நேரடி WireGuard இணைப்பாகவே இருக்கும், உங்கள் traffic ஒருபோதும் ஒருங்கிணைப்பு server வழியாகச் செல்லாது. server கையாள்வது metadata மட்டுமே: யார் இருக்கிறார்கள், யாருடைய key எது, யார் யாருடன் பேசலாம் என்பது மட்டுமே.

இதிலிருந்து மூன்று தெளிவான நன்மைகள் கிடைக்கின்றன.

NAT traversal. இரண்டு home router-களுக்குப் பின்னால் இருக்கும் இரண்டு மடிக்கணினிகளுக்கு இடையே public IP இருக்காது. Tailscale, STUN (session traversal utilities for NAT) பயன்படுத்தி ஒவ்வொரு பக்கத்தின் வெளி முகவரி மற்றும் port-ஐக் கண்டறிகிறது. பின்னர், இரண்டு பக்கங்களும் ஒரே நேரத்தில் பாக்கெட்டுகளை அனுப்புகின்றன, இதனால் ஒவ்வொரு router-ம் ஒரு outgoing flow-ஐ முதலில் பார்த்துவிட்டு பதிலை ஏற்றுக்கொள்கிறது. இது தோல்வியுற்றால், traffic ஒரு DERP relay-க்கு மாறுகிறது; இது Tailscale-ஆல் இயக்கப்படும் ஒரு encrypted relay ஆகும். relay-யிடம் key-கள் இல்லாததால், உங்கள் தரவு end-to-end encrypted முறையில் பாதுகாப்பாக இருக்கும். tailscale status-ஐ இயக்கினால், ஒவ்வொரு peer வரியும் direct அல்லது relay என்று காட்டும். எந்த relay அருகில் உள்ளது மற்றும் உங்கள் நெட்வொர்க் UDP-ஐ அனுமதிக்கிறதா என்பதைப் பார்க்க tailscale netcheck-ஐ இயக்கவும்.

காலாவதியாகும் key rotation. WireGuard key-கள் ஒருபோதும் காலாவதியாகாது. நீங்கள் மூன்று ஆண்டுகளுக்கு முன்பு வழங்கிய key, நீங்கள் கைமுறையாக peer block-ஐ நீக்கும் வரை எப்போதும் வேலை செய்யும். Tailscale அதற்குப் பதிலாக node key-களைக் காலாவதியாக்குகிறது. அக்டோபர் 2026 நிலவரப்படி, ஒரு புதிய tailnet-ல் இயல்புநிலை காலாவதி காலம் 180 நாட்கள் ஆகும். மீண்டும் அங்கீகரிக்கப்படாத (reauthenticated) ஒரு இயந்திரம் இணைப்பை நிறுத்திவிடும். server அல்லது subnet router போன்ற, யாரும் லாக்-இன் செய்ய முடியாத சாதனங்களுக்கு, நீங்கள் சாதன வாரியாக காலாவதி வசதியை (expiry) அணைக்கலாம்.

routing-க்கு பதிலாக கொள்கை (policy). சாதாரண WireGuard-ல், AllowedIPs என்பது ஒரே நேரத்தில் routing table மற்றும் access control list ஆகிய இரண்டாகவும் செயல்படுகிறது. எனவே, "alice database-ஐ அணுகலாம்" என்பதை ஒரு IP வரம்பாகவே குறிப்பிட வேண்டும். Tailscale ஒரு தனி policy கோப்பைப் பராமரிக்கிறது, அங்கு விதிகள் பயனர்கள், குழுக்கள் மற்றும் tags-களைப் பெயரிடுகின்றன. ஒரு விதி, tag:laptop ஆனது tag:db-ஐ 5432 port-ல் மட்டுமே அணுகலாம் என்றும், வேறு எதையும் அணுக முடியாது என்றும் கூறலாம். ஒரு இயந்திரம் புதிய முகவரியைப் பெற்றாலும் இந்த விதி மாறாமல் அப்படியே இருக்கும்.

Control plane-ஆல் ஏற்படும் செலவுகள்

Coordination server உங்கள் network-ஐப் பற்றி அறிந்திருக்கும். ஒவ்வொரு node-ன் public key, node-ன் பெயர், வழங்கப்பட்ட முகவரிகள் மற்றும் கொள்கை (policy) ஆகியவற்றை அது வைத்திருக்கும். Hosted Tailscale-ஐப் பயன்படுத்தும்போது, அது உங்கள் கட்டுப்பாட்டில் இல்லாத ஒரு நிறுவனமாகும். உங்கள் WireGuard private keys உங்கள் இயந்திரங்களிலேயே இருப்பதால், உங்கள் packets-களை அவர்களால் படிக்க முடியாது. ஆனால், உங்கள் network-ன் அமைப்பை அவர்களால் பார்க்க முடியும். மேலும், உங்கள் இணைப்பு என்பது அவர்களின் service இயங்குவதையும், உங்கள் கணக்கு நல்ல நிலையில் இருப்பதையும் பொறுத்தே அமையும். ஒரு coordination server சமரசம் செய்யப்பட்டாலோ அல்லது ஒரு identity கணக்கு திருடப்பட்டாலோ, அதில் உள்ள தகவல்களை வைத்து என்ன செய்ய முடியும் என்பதைப் பொறுத்தே இதற்கு எவ்வளவு முக்கியத்துவம் அளிக்க வேண்டும் என்பது தீர்மானிக்கப்படுகிறது. இது குறித்து Tailscale-ன் trust model-ஐ முழுமையாகப் படிப்பது பயனுள்ளது.

கவனிக்கத் தவறும் இரண்டாவது செலவு ஒன்றும் உள்ளது. Tailscale ஒவ்வொரு இயந்திரத்திலும் இயங்கும் ஒரு daemon ஆகும். எனவே, ஒவ்வொரு இயந்திரத்திலும் இதை நீங்கள் patch செய்து வைத்திருக்க வேண்டும். Ubuntu 24.04-ல் உள்ள சாதாரண WireGuard என்பது kernel module ஆகும்; இது distribution-உடன் சேர்ந்து வரும் மற்றும் kernel-உடன் சேர்ந்து update ஆகும்.

மூன்றாவது செலவு கட்டணம் தொடர்பானது. அக்டோபர் 2026 நிலவரப்படி, Personal திட்டம் 6 பயனர்கள் வரை வரம்பற்ற சாதனங்களுடன் இலவசமாகக் கிடைக்கிறது. Standard திட்டம் ஒரு பயனருக்கு மாதம் $8, Premium திட்டம் ஒரு பயனருக்கு மாதம் $18 ஆகும். ஒரு குடும்பத்திற்கு இது இலவசமாகவே இருக்கும், ஆனால் பத்து பேர் கொண்ட குழுவிற்கு இது பொருந்தாது. நீங்கள் இந்த வரம்பைத் தாண்டுவீர்களா என்பது சாதனங்களை விட பயனர்களின் எண்ணிக்கையைப் பொறுத்தது. இதற்கு ஒரு விதிவிலக்கு உண்டு: servers மற்றும் பிற tagged சாதனங்களுக்குத் தனி ஒதுக்கீடு உள்ளது. ஒவ்வொரு திட்டத்திலும் 50 tagged வளங்கள் அடங்கும். அக்டோபர் 2026 நிலவரப்படி, அதற்கு மேல் உள்ள ஒவ்வொன்றிற்கும் மாதம் $1 வீதம் கட்டணம் வசூலிக்கப்படும் என்று விலை நிர்ணயப் பக்கத்தில் குறிப்பிடப்பட்டுள்ளது. இலவசத் திட்டம் எவற்றை உள்ளடக்கியது என்பதை ஏழாவது பயனரை அழைப்பதற்கு முன்போ அல்லது ஐம்பத்தொன்றாவது server-ஐ tag செய்வதற்கு முன்போ படித்துப் பார்ப்பது நல்லது.

Plain WireGuard எப்போது சரியான தீர்வாகிறது

Topology என்பது hub and spoke முறையில் மட்டுமே இருக்கும்போது plain WireGuard-ஐத் தேர்ந்தெடுக்கவும். ஒரு public IP கொண்ட VPS, அதனுடன் இணையும் மூன்று அல்லது நான்கு சாதனங்கள், மற்றும் அந்தச் சாதனங்கள் ஒன்றுடன் ஒன்று இணைய வேண்டிய அவசியம் இல்லாத சூழல் இதற்குப் பொருந்தும். இதன் configuration ஒரு திரையிலேயே அடங்கிவிடும், புதுப்பிக்க வேண்டிய daemon கிடையாது, இழக்கக்கூடிய கணக்குகள் இல்லை, மேலும் உங்களுக்கும் உங்கள் server-க்கும் இடையில் எந்தவொரு வெளிப்புறச் சேவையும் இருக்காது.

மற்ற அனைத்து தொழில்நுட்பங்களும் எதன் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளன என்பதைப் புரிந்துகொள்ள விரும்பும்போதும் இதுவே சரியான தேர்வாகும். VPS-ல் WireGuard VPN-ஐ self-host செய்தல் என்ற கட்டுரை key generation, wg0.conf, IP forwarding, NAT மற்றும் handshake தோல்விகள் குறித்து விளக்குகிறது. ஒவ்வொரு tailnet-ன் அடியிலும் இந்த keys மற்றும் handshake-களே இயங்குகின்றன; ஒரு tailnet node, subnet router அல்லது exit node-ஆகச் செயல்படும்போது IP forwarding மீண்டும் அவசியமாகிறது. நீங்கள் இன்னும் பழைய விருப்பத்தைப் பரிசீலிக்கிறீர்கள் என்றால், WireGuard vs OpenVPN என்ற கட்டுரை OpenVPN இன்னும் சாதகமாக இருக்கும் நான்கு சூழல்களை விளக்குகிறது.

இதன் நிறுவல் மிகவும் எளிமையானது:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

ஒவ்வொரு சாதனமும் மற்ற அனைத்து சாதனங்களுடனும் இணைய வேண்டிய சூழல் வரும்போது plain WireGuard-ஐ நிர்வகிப்பது கடினமாகிறது. N எண்ணிக்கையிலான nodes கொண்ட full mesh அமைப்புக்கு, N பெருக்கல் (N-1) அளவிலான peer blocks தேவைப்படும். ஆறு சாதனங்கள் இருக்கும்போது, முப்பது blocks-ஐக் கைமுறையாகச் சீராக வைத்திருக்க வேண்டும். மேலும், நகல் எடுக்கப்பட்ட (duplicated) AllowedIPs entry இருந்தால், அது எந்தவித பிழைச் செய்தியும் காட்டாமல், முதலில் இருந்த peer-ன் traffic-ஐத் திருடிவிடும்.

Tailscale எப்போது சரியான தீர்வாக அமையும்

இயந்திரங்கள் ஓரிடத்தில் நிலையாக இல்லாமல் நகர்ந்து கொண்டிருக்கும்போது Tailscale-ஐத் தேர்ந்தெடுக்கவும். ஹோட்டல் நெட்வொர்க்குகளில் உள்ள மடிக்கணினிகள், மொபைல் டேட்டாவில் இயங்கும் தொலைபேசி, அல்லது நீங்கள் கட்டுப்படுத்தாத router-க்கு பின்னால் உள்ள home server போன்றவை இதற்குச் சிறந்த உதாரணங்கள். இத்தகைய சூழல்களில் சாதாரண WireGuard சரியாகச் செயல்படாது, ஏனெனில் இரு முனைகளிலும் Endpoint-ல் குறிப்பிடுவதற்கு நிலையான public endpoint இருக்காது.

அதிகாரப்பூர்வ installer மூலம் ஒரே கட்டளையில் client-ஐ நிறுவலாம்:

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

tailscale up ஒரு URL-ஐக் காட்டும். அதைத் திறந்து, login செய்தவுடன் அந்த இயந்திரம் நெட்வொர்க்கில் இணைந்துவிடும். இதில் key-களை நகலெடுக்க வேண்டிய அவசியமோ அல்லது inbound port-ஐத் திறக்க வேண்டிய தேவையோ இல்லை, ஏனெனில் daemon ஒரு outbound connection-ஐ coordination server-க்கு ஏற்படுத்தி அதைத் தொடர்ந்து திறந்தே வைத்திருக்கும். இதனால்தான், நீங்கள் எந்த firewall-ஐயும் கட்டுப்படுத்த முடியாத நெட்வொர்க்கிலும் ஒரு Tailscale node சிறப்பாகச் செயல்படுகிறது.

இதற்குப் பிறகு, இரண்டு அமைப்புகள் பெரும்பாலான பயனுள்ள வேலைகளைச் செய்கின்றன. ஒரு subnet router முழு LAN-ஐயும் நெட்வொர்க்கிற்குள் விளம்பரப்படுத்தும் (advertise), இதனால் ஒவ்வொரு சாதனத்திலும் client-ஐ நிறுவ வேண்டிய அவசியம் இருக்காது:

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
sudo tailscale set --advertise-routes=192.0.2.0/24

நீங்கள் admin console-ல் அனுமதிக்கும் வரை இந்த route செயலில் இருக்காது; இது வேண்டுமென்றே வடிவமைக்கப்பட்டது: ஒரு node தானாகவே உங்கள் நெட்வொர்க்கிற்குள் route-ஐச் செலுத்த முடியாது. Linux client-களுக்கு sudo tailscale set --accept-routes தேவைப்படுகிறது, ஏனெனில் Linux இயல்பாகவே விளம்பரப்படுத்தப்பட்ட route-களை ஏற்றுக்கொள்வதில்லை. எனவே, server பக்கத்தில் route அங்கீகரிக்கப்பட்டதாகத் தெரிந்தாலும், நீங்கள் அதைச் சரியாக அமைக்கும் வரை Linux மடிக்கணினியில் அது செயல்படாது. உங்களுக்கு இந்த அமைப்பு தேவைப்பட்டால், running a subnet router on a VPS என்ற வழிகாட்டி, route-ஐ அங்கீகரிக்கும் முறை மற்றும் forwarding அமைப்புகளைச் சரியாகச் செய்வதற்கான வழிமுறைகளை விளக்குகிறது.

ஒரு exit node, ஒரு client-ன் சாதாரண இணையப் போக்குவரத்தை (அதாவது, மற்றொரு tailnet சாதனத்திற்கோ அல்லது அங்கீகரிக்கப்பட்ட subnet route-க்கோ செல்லாத அனைத்துத் தரவுகளையும்) ஒரு குறிப்பிட்ட இயந்திரத்தின் வழியாக அனுப்புகிறது. இதுவே மக்கள் பொதுவாக "VPN" என்று குறிப்பிடும் முழுமையான tunnel செயல்பாடாகும். Linux-ல் இதை விளம்பரப்படுத்துவதற்கு முன்னால், மேலே காட்டப்பட்டுள்ள அதே IP forwarding அமைப்புகள் தேவைப்படும்:

sudo tailscale set --advertise-exit-node

அந்த flag-ஐ அமைப்பது எளிதான பகுதி. turning a VPS into an exit node என்ற வழிகாட்டி, அதற்குப் பிறகு செய்ய வேண்டியவற்றை விளக்குகிறது: admin console-ல் route-ஐ அங்கீகரிப்பது, மற்றும் போக்குவரத்து தவறான வழியில் செல்வதைத் தவிர்க்க DNS மற்றும் IPv6 அமைப்புகளைச் சரிசெய்வது போன்றவை இதில் அடங்கும். உங்களுக்கு ஒரு முழு நெட்வொர்க்கையும் அணுகுவதற்குப் பதிலாக ஒரு குறிப்பிட்ட web service-ஐ மட்டும் அணுக வேண்டும் என்றால், serve and funnel மூலம் ஒரு local port-க்கு முன்னால் HTTPS-ஐ அமைக்கலாம்; இது tailnet-க்கு மட்டும் அல்லது பொது இணையத்திற்குத் திறந்த நிலையில் இருக்கலாம்.

Headscale எப்போது சரியான தீர்வாக அமையும்

Headscale என்பது coordination server-ன் ஒரு open source செயலாக்கம் ஆகும். இது நீங்கள் சொந்தமாக வைத்திருக்கும் VPS-ல் இயங்குகிறது. அதிகாரப்பூர்வ Tailscale clients, அந்த hosted service-க்கு பதிலாக இதனுடன் இணைகின்றன:

sudo tailscale up --login-server https://headscale.example.com

Data path-ல் எந்த மாற்றமும் இல்லை. இது இப்போதும் WireGuard-தான், network அனுமதிக்கும் இடங்களில் peers-க்கு இடையே நேரடியாகவே செயல்படுகிறது. இதில் மாறுவது என்னவென்றால், node பட்டியல், keys மற்றும் policy ஆகியவை உங்கள் வசம் உள்ள வட்டில் (disk) ஒரு SQLite கோப்பில் சேமிக்கப்படுகின்றன. உங்கள் network-ன் அமைப்பை வெளியாட்கள் யாரும் பார்க்க முடியாது, உங்கள் கணக்கை முடக்க முடியாது, அல்லது பயனர்களுக்கு ஏற்ப கட்டணம் வசூலிக்க முடியாது.

இதற்கு நீங்கள் கூடுதல் உழைப்பைச் செலுத்த வேண்டியிருக்கும். நீங்கள் இப்போது ஒரு public HTTPS service-ஐ இயக்குகிறீர்கள்; இதற்கு ஒரு DNS பெயர், ஒரு certificate மற்றும் WebSocket upgrades-ஐச் சரியாகக் கையாளும் ஒரு reverse proxy தேவை. அதன் uptime-க்கு நீங்களே பொறுப்பு. coordination server இயங்கவில்லை என்றால், புதிய nodes-ஐப் பதிவு செய்ய முடியாது மற்றும் ஏற்கனவே உள்ள nodes-க்கு மாற்றங்கள் தெரியாது. Headscale இன்னும் 1.0 பதிப்பிற்கு கீழே இருப்பதால், அதன் minor releases-ல் சில மாற்றங்கள் (breaking changes) இருக்கலாம். எனவே, ஒவ்வொரு upgrade-க்கு முன்பும் changelog-ஐப் படிக்கவும். Headscale-ஐ உங்கள் சொந்த Tailscale control server-ஆக இயக்குதல் என்ற பகுதி, நிறுவல், config.yaml, preauth keys மற்றும் திறக்க வேண்டிய ports பற்றிய தகவல்களை வழங்குகிறது.

ஒரு முக்கியமான வரம்பை பலர் தாமதமாகவே கவனிக்கிறார்கள். Tailscale-ன் global relay network, Headscale உடன் சேர்ந்து வராது. இரண்டு peers நேரடியாக இணைக்க முடியாதபோது, உங்கள் சொந்த server-ல் embedded relay-ஐ இயக்க வேண்டும் அல்லது configuration-ஐ வேறு relay-ஐ நோக்கி அமைக்க வேண்டும். அந்த relay, உலகளாவிய fleet அல்ல; ஒரே region-ல் இருக்கும் ஒரே box மட்டுமே. உலகின் மறுபக்கத்தில் உள்ள peers இந்த வேறுபாட்டை network latency மூலம் தெளிவாக உணரும்.

இந்தப் பகுதியை நீங்களே அமைக்க விரும்பவில்லை என்றால், NetBird-ஐ self-hosting செய்தல் என்பது control plane-ஐ உங்கள் சொந்த infrastructure-க்குள் வைத்திருக்க மற்றொரு வழியாகும். இதன் quickstart, management, signal மற்றும் relay services-ஐ ஒரே VPS-ல் ஒன்றாகத் தொடங்குகிறது. ஆனால் Headscale போல NetBird ஒரு drop-in Tailscale server அல்ல. இது தனக்கென clients மற்றும் policy model-ஐ வழங்குகிறது. எனவே Headscale-க்குப் பதிலாக NetBird-ஐத் தேர்வு செய்வதற்கு முன், access rules மற்றும் relays தொடர்பாக NetBird மற்றும் Tailscale எவ்வாறு வேறுபடுகின்றன என்பதைப் படிக்கவும்.

ஒரே முயற்சியில் முடிவெடுப்பது எப்படி

ஒவ்வொரு machine-ம் மற்றொன்றை அணுக வேண்டிய அவசியம் எவ்வளவு என்பதை முதலில் கேட்கவும். அனைத்தும் server-உடன் மட்டுமே தொடர்பு கொள்ள வேண்டும் என்றால், plain WireGuard-ஐப் பயன்படுத்துவது சிறந்தது; இது குறைவான மென்பொருள் பயன்பாட்டில் அதே முடிவைத் தரும்.

அனைத்து machine-களும் நிலையான public address-ஐக் கொண்டுள்ளனவா என்று பார்க்கவும். பெரும்பாலானவை உங்கள் கட்டுப்பாட்டில் இல்லாத NAT-க்கு பின்னால் இருந்தால், உங்களுக்கு ஒரு control plane தேவைப்படும். ஏனெனில், hole punching என்பது கடினமான வேலை, அதை நீங்களே மீண்டும் உருவாக்குவதில் அர்த்தமில்லை.

உங்கள் network-ன் கட்டமைப்பு யாருக்குத் தெரியலாம் என்பதை முடிவு செய்யவும். வெளி நிறுவனங்கள் தெரியக்கூடாது என்றாலோ அல்லது பயனர்களின் எண்ணிக்கை அடிப்படையில் கட்டணம் வசூலிப்பது சிரமமாக இருந்தாலோ, Headscale-ஐப் பயன்படுத்தவும். ஆனால், control server-ஐ நீங்களே நிர்வகிக்க வேண்டும் என்பதை ஒப்புக்கொள்ள வேண்டும். கட்டண முறைதான் உங்களை மாற்றத்திற்குத் தூண்டுகிறது என்றால், முடிவெடுப்பதற்கு முன் கணக்கிட்டுப் பார்க்கவும். ஏனெனில் உங்கள் குழுவின் அளவிற்கேற்ப நீங்கள் உண்மையில் செலுத்தும் கட்டணம் என்பது நீங்கள் இயக்கும் machine-களின் எண்ணிக்கையை விட, எத்தனை பேர் கணக்குகளை வைத்துள்ளனர் என்பதைப் பொறுத்தே அமையும். உங்கள் tagged servers எண்ணிக்கை 50-ஐத் தாண்டும் வரை இது பொருந்தும்; இந்த இரண்டு எண்களும் பெரும்பாலும் ஒன்றாக இருப்பதில்லை.

நீங்கள் உங்கள் முடிவை எளிதாக மாற்றிக்கொள்ளலாம். மூன்றிலும் data plane ஒரே protocol-ஐப் பயன்படுத்துவதால், plain WireGuard-லிருந்து coordinated mesh-க்கு மாறுவது என்பது ஒரு client install மட்டுமே; இது முழு வடிவமைப்பையும் மாற்ற வேண்டிய அவசியமில்லை. Tailscale-லிருந்து Headscale-க்கு மாறுவது என்பது, ஒவ்வொரு node-ஐயும் வேறொரு login server-ல் மீண்டும் பதிவு செய்வது மட்டுமே.

இவை மூன்றிலும் கிடைக்காதவை

இவை எதுவும் firewall கிடையாது. ஒரு tunnel எந்த packets கடத்தப்பட வேண்டும் என்பதை மட்டுமே தீர்மானிக்கிறது, எந்த services listen செய்ய வேண்டும் என்பதை அல்ல. Tunnel வழியாக அணுகக்கூடிய ஒரு server, நீங்கள் திறந்து வைத்துள்ள எந்தவொரு port வழியாகவும் இணையத்திலிருந்து அணுகப்படலாம். எனவே, VPS-ல் உள்ள UFW firewall விதிகள் தொடர்ந்து அவற்றின் பணியைச் செய்வதை உறுதிப்படுத்தவும். Tailscale-ன் policy file மற்ற nodes எவற்றை அணுகலாம் என்பதை மட்டுமே கட்டுப்படுத்துகிறது; இது public interface-ல் எந்த மாற்றத்தையும் செய்வதில்லை.

இவை எதுவும் per-service authentication வசதியை வழங்கவில்லை, மேலும் ஒரு பயனர் இணைக்கப்பட்ட பிறகு அவர் என்ன செய்தார் என்பதற்கான audit trail-ஐயும் இவை தருவதில்லை. இவை மூன்றையும் transport layer-ஆக மட்டுமே கருதி, login சோதனைகளை application மட்டத்திலேயே அமைக்கவும்.

FAQ

Tailscale என்பது கூடுதல் படிகளைக் கொண்ட WireGuard மட்டும்தானா?

Tailscale தரவுப் பாதைக்கு (data path) WireGuard protocol-ஐப் பயன்படுத்துகிறது, எனவே encryption மற்றும் tunnel ஆகியவை ஒரே மாதிரியானவை. இது ஒருங்கிணைப்பை (coordination) சேர்க்கிறது: key exchange, முகவரி ஒதுக்கீடு, STUN மற்றும் DERP relays மூலம் NAT traversal, key expiry, மற்றும் IP வரம்புகளுக்குப் பதிலாக பயனர்களைக் குறிப்பிடும் policy file. இவை சாதாரண WireGuard-ல் நீங்களே கையாள வேண்டிய பகுதிகள், மேலும் இயந்திரங்கள் வெவ்வேறு network-களுக்கு இடையே நகரும்போது இவைதான் கடினமானவையாக மாறுகின்றன.

எனது traffic Tailscale-ன் servers வழியாகச் செல்கிறதா?

பொதுவாக இல்லை. ஒருங்கிணைப்பு server (coordination server) அறிமுகப்படுத்திய பிறகு, peers நேரடியாக ஒன்றோடொன்று இணைகின்றன, மேலும் அந்த peer வரிகளில் tailscale status என்பது direct என்று காட்டும். நேரடிப் பாதையை உருவாக்க முடியாதபோது, traffic ஒரு DERP relay-க்கு மாறுகிறது மற்றும் அந்த வரி relay என்று காட்டும். அப்படியிருந்தாலும், relay குறியாக்கம் செய்யப்பட்ட (encrypted) packets-களை மட்டுமே கொண்டு செல்கிறது, உங்கள் WireGuard private keys-களை அது கொண்டிருக்காது, எனவே உள்ளடக்கத்தை அதனால் படிக்க முடியாது. நேரடி இணைப்புகளுக்குத் தேவையான UDP-ஐ உங்கள் network தடுக்கிறதா என்று பார்க்க tailscale netcheck-ஐ இயக்கவும்.

அதிகாரப்பூர்வ Tailscale apps-உடன் Headscale-ஐப் பயன்படுத்த முடியுமா?

ஆம். Headscale அதே control protocol-ஐப் பயன்படுத்துகிறது, எனவே அதிகாரப்பூர்வ clients sudo tailscale up --login-server https://headscale.example.com மூலம் இணைகின்றன. Desktop மற்றும் mobile apps-களை ஒரு custom login server-க்கு மாற்ற முடியும், இருப்பினும் ஒவ்வொரு தளத்திலும் இந்த அமைப்பு வெவ்வேறு இடங்களில் இருக்கும், மேலும் mobile apps-களுக்கு ஒரு குறிப்பிட்ட version தேவைப்பட வாய்ப்புள்ளது. முழு network-ஐயும் மாற்றுவதற்கு முன் ஒரு phone-ல் சோதனை செய்யவும்.

Tailscale அல்லது Headscale-க்காக நான் இன்னும் ports-ஐத் திறக்க வேண்டுமா?

Tailscale client-க்கு எந்த inbound port-ம் தேவையில்லை, ஏனெனில் அது ஒருங்கிணைப்பு server-க்கு வெளியே அழைப்பை (dial out) மேற்கொண்டு அந்த இணைப்பைத் திறந்தே வைத்திருக்கும். ஒரு self-hosted Headscale server-க்கு inbound ports தேவை: control protocol-க்கு 443, நீங்கள் HTTP-01 certificate challenge பயன்படுத்தினால் 80, மற்றும் நீங்கள் embedded relay-ஐ இயக்கும்போது மட்டும் 3478/udp. சாதாரண WireGuard-க்கு அதன் UDP listen port, பொதுவாக 51820, server-லும் உங்கள் provider இயக்கும் ஏதேனும் தனி network firewall-லும் திறந்திருக்க வேண்டும்.

மூன்றில் எது வேகமானது?

மூன்றும் WireGuard மூலம் packets-களை நகர்த்துவதால், throughput ஒரே மாதிரியாகவே இருக்கும். இணைப்பு அமைப்பு (connection setup) மற்றும் பாதையின் தரம் ஆகியவற்றில் மட்டுமே வித்தியாசம் தெரியும். சரியான Endpoint கொண்ட சாதாரண WireGuard ஒவ்வொரு முறையும் நேரடியாக இணைகிறது. Tailscale மற்றும் Headscale பெரும்பாலான நேரங்களில் நேரடியாக இணைகின்றன, network hole punching-ஐத் தடுக்கும்போது மட்டும் relay-க்கு மாறுகின்றன, மேலும் relay செய்யப்பட்ட பாதை latency-ஐ அதிகரிக்கும். உங்கள் பாதையை tailscale ping <node> மூலம் அளவிடவும், இது பாதை நேரடியா அல்லது relay செய்யப்பட்டதா என்பதைத் தெரிவிக்கும், அல்லது tunnel வழியாக iperf3-ஐப் பயன்படுத்தவும். நேரடிப் பாதையில் அந்த எண் உங்கள் line rate-ஐ விட மிகக் குறைவாக இருந்தால், மூன்றில் எதைத் தேர்ந்தெடுப்பது என்பது உங்கள் சிக்கல் அல்ல, வழக்கமான காரணம் path MTU mismatch ஆகும், இது control plane இருந்தாலும் இல்லாவிட்டாலும் ஒரே மாதிரியாகவே செயல்படும்.