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. பத்து இயந்திரங்கள் கொண்ட ஒரு நெட்வொர்க்கில் ஒரு புதிய இயந்திரத்தைச் சேர்ப்பது என்பது பத்து configuration கோப்புகளைத் திருத்துவதாகும், ஏனெனில் ஒவ்வொரு பக்கமும் மற்றொன்றின் key-ஐக் கொண்டிருக்க வேண்டும். இதனால்தான் பெரும்பாலான self-hosted WireGuard அமைப்புகள் hub and spoke முறையில் உள்ளன: public IP கொண்ட ஒரு server, மற்றும் அதனுடன் மட்டுமே பேசும் clients.

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

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

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

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

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

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

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

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

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

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

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

மற்ற தொழில்நுட்பங்கள் எதன் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளன என்பதைப் புரிந்துகொள்ள விரும்பும்போதும் இதுவே சரியான தேர்வாகும். VPS-ல் WireGuard VPN-ஐ self-host செய்தல் என்ற கட்டுரை key generation, wg0.conf, IP forwarding, NAT மற்றும் handshake தோல்விகள் குறித்து விளக்குகிறது. இவை அனைத்தும் ஒரு tailnet-ன் பின்னணியிலும் இயங்கிக்கொண்டிருக்கின்றன. நீங்கள் இன்னும் பழைய விருப்பத்தைப் பரிசீலிக்கிறீர்கள் என்றால், 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-ஐ நீங்களே கைகளால் ஒத்திசைக்க (sync) வேண்டியிருக்கும். மேலும், நகல் எடுக்கப்பட்ட (duplicated) AllowedIPs entry ஏதேனும் இருந்தால், அது முதலில் இருந்த peer-ன் traffic-ஐ எந்தவித எச்சரிக்கையும் இன்றித் திருடிவிடும்.

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

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

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

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

tailscale up ஒரு URL-ஐக் காண்பிக்கும். அதைத் திறந்து, லாக்-இன் செய்தவுடன் அந்த இயந்திரம் நெட்வொர்க்கில் இணைந்துவிடும். இதில் கீ-களை (keys) நகலெடுக்க வேண்டிய அவசியமோ அல்லது inbound port-களைத் திறக்க வேண்டிய தேவையோ இல்லை. ஏனெனில், daemon ஒரு outbound இணைப்பை 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-களை ஏற்றுக்கொள்வதில்லை. எனவே, சர்வர் பக்கத்தில் route அங்கீகரிக்கப்பட்டதாகத் தெரிந்தாலும், நீங்கள் அதைச் சரியாக அமைக்கும் வரை Linux மடிக்கணினியில் அது செயல்படாது. உங்களுக்கு இந்த அமைப்பு தேவைப்பட்டால், VPS-ல் subnet router-ஐ இயக்குவது குறித்த வழிகாட்டி, அங்கீகாரப் படிநிலை மற்றும் forwarding அமைப்புகளைச் சரியாகச் செய்வதற்கான வழிமுறைகளை விளக்குகிறது.

ஒரு exit node, client-ன் அனைத்து டிராஃபிக்கையும் ஒரே இயந்திரத்தின் வழியாக அனுப்பும். இதுவே மக்கள் பொதுவாக "VPN" என்று குறிப்பிடும் முழுமையான டன்னல் (full tunnel) செயல்பாடாகும்:

sudo tailscale set --advertise-exit-node

அந்த flag-ஐ அமைப்பது எளிதான பகுதி. VPS-ஐ exit node-ஆக மாற்றுவது குறித்த பகுதி, அதற்குப் பிறகு செய்ய வேண்டியவற்றை விளக்குகிறது: நிர்வாக கன்சோலில் route-ஐ அங்கீகரிப்பது, மற்றும் டிராஃபிக் தவறான வழியில் செல்வதைத் தவிர்க்க DNS மற்றும் IPv6 செயல்பாடுகளைச் சரிசெய்வது போன்றவை இதில் அடங்கும். உங்களுக்கு ஒரு முழு நெட்வொர்க்கிற்குப் பதிலாக ஒரு குறிப்பிட்ட இணைய சேவை (web service) மட்டுமே தேவைப்பட்டால், serve மற்றும் 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 பற்றிய தகவல்களை வழங்குகிறது.

ஒரு முக்கியமான எச்சரிக்கை: Headscale-உடன் Tailscale-ன் global relay network வராது. இரண்டு peers நேரடியாக இணைய முடியாத சூழலில், நீங்கள் உங்கள் server-லேயே உள்ள embedded relay-ஐ இயக்க வேண்டும் அல்லது வேறொரு config-ஐக் குறிப்பிட வேண்டும். அந்த relay, உலகம் முழுவதும் பரவியிருக்கும் fleet-க்கு பதிலாக, ஒரு குறிப்பிட்ட பகுதியில் உள்ள ஒரு தனி server மட்டுமே. உலகின் மறுமுனையில் இருக்கும் peers இந்த வித்தியாசத்தை உணர முடியும். நீங்களாகவே அந்தப் பகுதியை உருவாக்க விரும்பவில்லை என்றால், NetBird-ஐ self-host செய்தல் என்பது control plane-ஐ உங்கள் கட்டுப்பாட்டில் வைத்திருக்க மற்றொரு வழியாகும். ஏனெனில் அதன் quickstart முறை, management, signal மற்றும் relay services ஆகியவற்றை ஒரே VPS-ல் ஒன்றாக நிறுவுகிறது.

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

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

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

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

நீங்கள் உங்கள் முடிவை எளிதாக மாற்றிக்கொள்ளலாம். மூன்றிலும் data plane ஒரே protocol-ஐப் பயன்படுத்துவதால், plain WireGuard-லிருந்து coordinated mesh-க்கு மாறுவது என்பது ஒரு redesign அல்ல, அது ஒரு 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-ல் நீங்கள் கையாள வேண்டியவை, மேலும் இயந்திரங்கள் நெட்வொர்க்குகளுக்கு இடையே மாறும்போது இவைதான் கடினமான பகுதிகளாகின்றன.

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

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

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

Tailscale client-க்கு inbound port தேவையில்லை, ஏனெனில் அது ஒருங்கிணைப்பு server-க்கு வெளியே டயல் செய்து அந்த இணைப்பைத் திறந்தே வைத்திருக்கும். ஒரு 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 இயக்கும் ஏதேனும் தனி நெட்வொர்க் firewall-லும் திறந்திருக்க வேண்டும்.

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

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