WireGuard, Tailscale की Headscale: VPS साठी काय निवडावे?

WireGuard विरुद्ध Tailscale: थोडक्यात उत्तर

WireGuard विरुद्ध Tailscale ही दोन प्रोटोकॉलमधील निवड नाही, कारण Tailscale हेच WireGuard आहे. Tailscale तेच encryption आणि तोच tunnel वापरते. त्यासोबत ते control plane जोडते: public keys ची देवाणघेवाण करणारा, addresses वितरित करणारा, NAT (network address translation) मधून मार्ग तयार करणारा आणि access policy लागू करणारा coordination server. या coordination पैकी किती भाग स्वतः चालवायचा, हीच तुमची निवड असते.

याची तीन स्पष्ट उत्तरे आहेत. तुमच्याकडे एक server आणि त्याच्याशी connection करणारे मोजके clients असतील, तर plain WireGuard चालवा. प्रत्येक machine ला configuration file न सांभाळता इतर प्रत्येक machine पर्यंत पोहोचवायचे असेल, तर Tailscale वापरा. तो mesh हवा असेल, पण node list एखाद्या third party कडे ठेवायची नसेल, तर Headscale वापरा.

कंट्रोल प्लेनमुळे प्रत्यक्षात काय मिळते

साध्या WireGuard मध्ये discovery सुविधा नसते. प्रत्येक peer म्हणजे तुम्ही हाताने लिहिलेला मजकुराचा एक block असतो: public key, एक AllowedIPs line आणि तो peer पोहोचण्यायोग्य असल्यास एक Endpoint. दहा मशीनच्या नेटवर्कमध्ये एक मशीन जोडण्यासाठी दहा configuration files संपादित कराव्या लागतात, कारण प्रत्येक बाजूला दुसऱ्या बाजूची key आवश्यक असते. म्हणूनच जवळजवळ प्रत्येक self-hosted WireGuard setup hub-and-spoke असतो: public IP असलेला एक server आणि त्याच्याशीच संवाद करणारे clients.

Control plane मुळे ही editing आवश्यकता दूर होते. प्रत्येक node एकदाच register होतो, 100.64.0.0/10 CGNAT (carrier grade NAT) range मधून एक address मिळवतो आणि ज्या nodes शी त्याला संवाद साधण्याची परवानगी आहे त्यांच्या public keys त्याला दिल्या जातात. Tunnel अजूनही दोन peers मधील थेट WireGuard connection असतो आणि तुमचा traffic coordination server मधून जात नाही. Server कडे metadata असतो: कोणते nodes अस्तित्वात आहेत, कोणती key कोणाची आहे आणि कोणाला कोणाशी संवाद साधण्याची परवानगी आहे.

यातून तीन ठोस गोष्टी मिळतात.

NAT traversal. दोन home routers च्या मागे असलेल्या दोन laptops मध्ये कोणताही public IP नसतो. Tailscale STUN (session traversal utilities for NAT) वापरून दोन्ही बाजूंचा बाहेरील address आणि port शोधते. त्यानंतर दोन्ही बाजू एकाच वेळी packets पाठवतात. त्यामुळे प्रत्येक router ला आधी outgoing flow दिसतो आणि तो reply स्वीकारतो. हे अयशस्वी झाल्यास traffic DERP relay कडे वळतो. हा Tailscale द्वारे चालवला जाणारा encrypted relay आहे. Relay कडे keys कधीही नसल्यामुळे relay मधून जातानाही तुमचा data end-to-end encrypted राहतो. tailscale status चालवा; प्रत्येक peer line मध्ये direct किंवा relay दिसेल. कोणता relay सर्वात जवळ आहे आणि तुमचे network UDP ला पूर्णपणे परवानगी देते का हे पाहण्यासाठी tailscale netcheck चालवा.

Expiry सह key rotation. WireGuard keys कधीही expire होत नाहीत. तीन वर्षांपूर्वी issue केलेली key तुम्ही peer block हाताने delete करेपर्यंत कायम कार्यरत राहते. याउलट, Tailscale node keys expire करते. July 2026 नुसार, नवीन tailnet साठी default expiry period 180 days आहे. Reauthenticate न केलेले machine connect होणे थांबवते. Server किंवा subnet router सारख्या device साठी expiry बंद करता येते, जिथे login करण्यासाठी कोणीही नियमितपणे उपलब्ध नसेल.

Routing ऐवजी policy. साध्या WireGuard मध्ये AllowedIPs हे एकाच वेळी routing table आणि access control list असते. त्यामुळे "alice may reach the database" हे IP range म्हणून व्यक्त करावे लागते. Tailscale स्वतंत्र policy file ठेवते. या file मधील rules मध्ये users, groups आणि tags ची नावे देता येतात. एखाद्या rule मध्ये tag:laptop ला port 5432 वरील tag:db पर्यंत आणि इतर कशापर्यंतही नाही, असा नियम करता येतो. Machine ला नवीन address मिळाल्यानंतरही हा rule लागू राहतो.

कंट्रोल प्लेनची किंमत

समन्वय सर्व्हरला तुमच्या नेटवर्कची माहिती असते. त्याच्याकडे प्रत्येक node ची public key, प्रत्येक node चे नाव, वितरित केलेले पत्ते आणि policy असते. Hosted Tailscale वापरल्यास हा सर्व्हर तुमच्या नियंत्रणाबाहेरील कंपनीकडे असतो. WireGuard private keys तुमच्या मशीनवरच राहतात, त्यामुळे तुमचे packets त्यांना वाचता येत नाहीत. मात्र तुमच्या नेटवर्कची रचना त्यांना दिसू शकते. तसेच connect होण्याची क्षमता त्यांच्या service सुरू असण्यावर आणि तुमचे account चांगल्या स्थितीत असण्यावर अवलंबून असते. त्यांच्या ताब्यातील माहिती वापरून compromised coordination server किंवा चोरीला गेलेल्या identity account कडून प्रत्यक्षात काय केले जाऊ शकते, यावर या जोखमीला किती महत्त्व द्यायचे हे ठरते. यासाठी Tailscale च्या trust model चे संपूर्ण स्पष्टीकरण वाचणे उपयुक्त आहे.

दुसरी एक किंमत सहज लक्षात येत नाही. Tailscale प्रत्येक मशीनवर daemon म्हणून चालते. त्यामुळे प्रत्येक मशीनवर ते software patched ठेवावे लागते. Ubuntu 24.04 मधील plain WireGuard हे distribution सोबत येणारे kernel module आहे आणि kernel सोबत update होते.

तिसरी किंमत billing ची आहे. July 2026 नुसार Personal plan 6 users पर्यंत unlimited devices सह विनामूल्य आहे. Standard ची किंमत प्रति user प्रति month $8 आहे आणि Premium ची किंमत प्रति user प्रति month $18 आहे. Household विनामूल्य राहते. दहा जणांची team विनामूल्य राहत नाही. ही मर्यादा devices पेक्षा seats वर अवलंबून आहे. सातव्या user ला invite करण्यापूर्वी free plan मध्ये प्रत्यक्षात काय समाविष्ट आहे हे वाचणे उपयुक्त आहे.

plain WireGuard योग्य पर्याय कधी आहे

नेटवर्कची रचना खरोखर hub-and-spoke असेल, तेव्हा plain WireGuard निवडा. सार्वजनिक IP असलेला एक VPS, त्याला जोडणारी तीन किंवा चार उपकरणे आणि त्या उपकरणांनी एकमेकांपर्यंत पोहोचण्याची आवश्यकता नसणे, अशी रचना यासाठी योग्य आहे. Configuration एका स्क्रीनवर मावते. अपडेट करावा लागणारा daemon नसतो. गमावण्यासारखे account नसते. तुमच्या आणि serverच्या मध्ये कोणतीही बाह्य सेवा नसते.

इतर सर्व रचना ज्या मूलभूत स्तरावर उभारल्या आहेत, तो स्तर समजून घ्यायचा असेल, तरीही हा योग्य पर्याय आहे. VPS वर WireGuard VPN स्वतः host करणे या मार्गदर्शकात key generation, wg0.conf, IP forwarding, NAT आणि handshake failures यांची माहिती दिली आहे. ही सर्व यंत्रणा tailnet च्या अंतर्गतही कार्यरत असते. तुम्ही अजूनही जुन्या पर्यायाचा विचार करत असाल, तर WireGuard विरुद्ध OpenVPN मध्ये OpenVPN अजूनही अधिक चांगला ठरणाऱ्या चार परिस्थिती स्पष्ट केल्या आहेत.

Installation लहान आहे:

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

प्रत्येक उपकरणाने इतर प्रत्येक उपकरणापर्यंत पोहोचणे आवश्यक झाल्यावर plain WireGuard व्यवस्थापित करणे अवघड होते. N nodes असलेल्या full mesh साठी N times N minus one peer blocks आवश्यक असतात. सहा उपकरणे असताना अशा तीस blocks चे synchronization manually करावे लागते. तसेच duplicate AllowedIPs entry मुळे आधीपासून ती entry असलेल्या peer कडून network traffic शांतपणे वळवला जातो; कुठेही error दाखवला जात नाही.

Tailscale योग्य पर्याय कधी आहे

मशिन्सची ठिकाणे बदलत असतील, तेव्हा Tailscale निवडा. हॉटेलच्या नेटवर्कवर असलेले लॅपटॉप, mobile data वापरणारा फोन किंवा तुमचे नियंत्रण नसलेल्या router च्या मागे असलेला home server यासाठी हे योग्य आहे. या परिस्थिती plain WireGuard साठी कठीण असतात, कारण Endpoint मध्ये नोंदवता येईल असा स्थिर public endpoint कोणत्याही बाजूला नसतो.

अधिकृत installer वापरून client install करण्यासाठी एक command चालवा:

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

tailscale up एक URL दाखवते. तो उघडा, log in करा आणि मशीन network मध्ये जोडले जाईल. कॉपी करण्यासाठी कोणतीही key नसते आणि inbound port उघडण्याची गरज नसते, कारण daemon coordination server कडे outbound connection तयार करून तो खुला ठेवतो. त्यामुळे कोणत्याही firewall वर तुमचे नियंत्रण नसलेल्या network वरही Tailscale node कार्य करते.

त्यानंतर उपयुक्त कामासाठी दोन settings महत्त्वाच्या असतात. Subnet router संपूर्ण LAN ची जाहिरात network मध्ये करतो. त्यामुळे प्रत्येक device वर client install करण्याची गरज राहत नाही:

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 approve करेपर्यंत तो inactive राहतो. हे जाणीवपूर्वक केलेले आहे: node स्वतःहून तुमच्या network मध्ये route inject करू शकत नाही. Linux clients साठी sudo tailscale set --accept-routes देखील आवश्यक आहे, कारण Linux advertised routes default ने स्वीकारत नाही. त्यामुळे server side वर approved दिसणारा route, Linux laptop वर ही setting केल्याशिवाय कार्य करत नाही. हीच रचना हवी असल्यास, VPS वर subnet router चालवणे approval step आणि forwarding settings योग्य क्रमाने समजावते. त्यामुळे route अर्धवट कार्यरत राहण्याची समस्या टाळता येते.

Exit node client चा सर्व traffic एका मशीनमधून पाठवतो. लोक "VPN" म्हणतात ते पूर्ण tunnel behaviour साधारणपणे हेच असते:

sudo tailscale set --advertise-exit-node

हा flag वापरणे सोपे आहे. त्यानंतरची प्रक्रिया VPS ला exit node मध्ये रूपांतरित करणे येथे दिली आहे: प्रथम admin console मध्ये route approve करा. त्यानंतर DNS आणि IPv6 behaviour दुरुस्त करा; अन्यथा traffic चुकीच्या मार्गाने बाहेर जाऊ शकतो. संपूर्ण network ऐवजी एखादी एक web service उपलब्ध करून द्यायची असल्यास, serve आणि funnel वापरा. यात एका local port समोर HTTPS ठेवता येते, आणि सेवा फक्त tailnet साठी किंवा public internet साठी खुली ठेवता येते.

Headscale योग्य पर्याय कधी ठरतो

Headscale हे coordination server चे open source implementation आहे. ते तुमच्या मालकीच्या VPS वर चालते. अधिकृत Tailscale clients hosted service ऐवजी त्याकडे निर्देश करतात:

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

Data path मधील सर्व काही तसेच राहते. हे अजूनही WireGuard असते आणि network परवानगी देत असल्यास peers दरम्यान थेट कनेक्शन होते. बदल एवढाच असतो की node list, keys आणि policy तुमच्या मालकीच्या disk वरील SQLite file मध्ये राहतात. बाहेरील कोणालाही तुमच्या network ची रचना पाहता येत नाही, तुमचे account disable करता येत नाही किंवा प्रत्येक user साठी शुल्क आकारता येत नाही.

यासाठी प्रत्यक्ष व्यवस्थापनाचे काम करावे लागते. आता तुम्ही सार्वजनिक HTTPS service चालवत असता. त्यामुळे DNS name, certificate आणि WebSocket upgrades योग्यरीत्या forward करणारा reverse proxy आवश्यक असतो. त्याची uptime राखण्याची जबाबदारी तुमची असते. Coordination server बंद असल्यास नवीन nodes register होऊ शकत नाहीत आणि विद्यमान nodes ना बदलांची माहिती मिळत नाही. Headscale अजून version 1.0 पेक्षा कमी आहे. त्याच्या minor releases मध्ये breaking changes झाले आहेत. त्यामुळे प्रत्येक upgrade पूर्वी changelog वाचा. Headscale स्वतःचा Tailscale control server म्हणून चालवणे यामध्ये install, config.yaml, preauth keys आणि उघडायचे ports यांची माहिती आहे.

एक महत्त्वाची मर्यादा उशिरा लक्षात येते. Headscale सोबत Tailscale चे जागतिक relay network येत नाही. दोन peers थेट connect होऊ शकत नसतील, तर तुम्हाला तुमच्या स्वतःच्या server वर embedded relay enable करावे लागते किंवा config दुसऱ्या relay कडे निर्देशित करावी लागते. हा relay जगभरातील fleet ऐवजी एका region मधील एका box वर चालतो. पृथ्वीच्या विरुद्ध बाजूला असलेल्या peers ना हा फरक जाणवतो. हा भाग स्वतः तयार करायचा नसेल, तर NetBird स्वतःच्या infrastructure वर चालवणे हा control plane in-house ठेवण्याचा दुसरा मार्ग आहे. त्याच्या quickstart मुळे management, signal आणि relay services एकाच VPS वर एकत्र सुरू होतात.

एका फेरीत निर्णय कसा घ्यावा

एकमेकांपर्यंत पोहोचणे आवश्यक असलेल्या मशीनची संख्या विचारात घ्या. त्या सर्व मशीन फक्त सर्व्हरशीच संवाद साधत असतील, तर त्याच परिणामासाठी plain WireGuard मध्ये कमी सॉफ्टवेअर लागते.

मशिनींना स्थिर public addresses आहेत का ते तपासा. त्यांपैकी बहुतेक तुमच्या नियंत्रणाबाहेरील NAT च्या मागे असतील, तर तुम्हाला control plane आवश्यक आहे. कारण hole punching हा कठीण भाग आहे आणि तो पुन्हा तयार करणे योग्य ठरणार नाही.

तुमच्या नेटवर्कची रचना कोणाला माहीत असण्याची परवानगी आहे ते ठरवा. बाहेरील कंपन्यांना ही माहिती देणे मान्य नसेल किंवा user count मुळे per seat billing महाग पडत असेल, तर Headscale चालवा आणि control server आता तुम्हालाच operate करावा लागेल हे स्वीकारा. Billing मुळे migration करण्याचा निर्णय घेत असाल, तर commit करण्यापूर्वी गणित करा. कारण तुमच्या आकाराच्या टीमला प्रत्यक्षात किती खर्च येतो हे तुम्ही चालवत असलेल्या मशीनच्या संख्येवर नव्हे, तर account असलेल्या लोकांच्या संख्येवर ठरते; आणि या दोन संख्या क्वचितच समान असतात.

तुम्ही कमी खर्चात निर्णय बदलू शकता. तिन्ही पर्यायांमध्ये data plane साठी समान protocol वापरला जात असल्याने, plain WireGuard वरून coordinated mesh कडे जाण्यासाठी redesign करण्याऐवजी client install करणे पुरेसे असते. Tailscale वरून Headscale कडे जाताना प्रत्येक node ची वेगळ्या login server विरुद्ध re-registration करावी लागते.

तीनही पर्यायांमधून काय मिळत नाही

यापैकी एकही firewall नाही. Tunnel कोणते packets वाहून नेले जातील हे ठरवतो; कोणत्या services listen करतील हे नाही. Tunnel द्वारे उपलब्ध असलेला server तुम्ही खुले ठेवलेल्या कोणत्याही port वरून internet वरून तरीही उपलब्ध असतो. त्यामुळे VPS वरील UFW firewall नियम त्यांचे काम करत आहेत याची खात्री करा. Tailscale ची policy file इतर nodes कोणत्या सेवांपर्यंत पोहोचू शकतात याची मर्यादा घालते. तिचा public interface वर कोणताही परिणाम होत नाही.

यापैकी एकही पर्याय per-service authentication देत नाही. तसेच connect झाल्यानंतर user ने काय केले याचा audit trail यापैकी कोणताही तयार करत नाही. तिन्ही पर्यायांना transport म्हणून वापरा आणि login checks application मध्ये ठेवा.

FAQ

Tailscale म्हणजे अतिरिक्त टप्प्यांसह WireGuardच आहे का?

Tailscale डेटा पाथसाठी WireGuard प्रोटोकॉल वापरते, त्यामुळे एन्क्रिप्शन आणि टनेल समान असतात. Tailscale यात coordination जोडते: key exchange, address assignment, STUN आणि DERP relay वापरून NAT traversal, key expiry आणि IP range ऐवजी users नमूद करणारी policy file. Plain WireGuard मध्ये ही कामे तुम्हालाच करावी लागतात. मशीन वेगवेगळ्या नेटवर्कमध्ये हलू लागल्यावर हीच कामे अवघड होतात.

माझा traffic Tailscale च्या सर्व्हरमधून जातो का?

सामान्यतः नाही. Coordination server ने peers ची ओळख करून दिल्यानंतर ते एकमेकांशी थेट connect होतात आणि tailscale status त्या peer lines वर direct दाखवते. Direct path तयार करता आला नाही, तर traffic DERP relay कडे वळतो आणि त्या line वर relay दिसते. तरीही relay encrypted packets वाहून नेतो आणि तुमच्या WireGuard private keys त्याच्याकडे नसतात. त्यामुळे तो contents वाचू शकत नाही. तुमचे network direct connections साठी आवश्यक UDP block करत आहे का हे पाहण्यासाठी tailscale netcheck चालवा.

मी official Tailscale apps सोबत Headscale वापरू शकतो का?

होय. Headscale तोच control protocol वापरते. त्यामुळे official clients sudo tailscale up --login-server https://headscale.example.com सह join होतात. Desktop आणि mobile apps custom login server कडे निर्देशित करता येतात. मात्र प्रत्येक platform वर ही setting वेगळ्या ठिकाणी असते. विशिष्ट version ची गरज भासण्याची शक्यता mobile apps मध्ये अधिक असते. संपूर्ण network migrate करण्यापूर्वी एका phone वर चाचणी करा.

Tailscale किंवा Headscale साठी मला ports उघडण्याची अजूनही गरज आहे का?

Tailscale client ला inbound port ची गरज नसते. तो coordination server शी outbound connection करतो आणि ती connection उघडी ठेवतो. Self-hosted Headscale server साठी inbound ports आवश्यक असतात: control protocol साठी 443, HTTP-01 certificate challenge वापरत असल्यास 80 आणि embedded relay enable केल्यावरच 3478/udp. Plain WireGuard साठी त्याचा UDP listen port, सामान्यतः 51820, server वर आणि provider चालवत असलेल्या स्वतंत्र network firewall वर उघडा असणे आवश्यक आहे.

या तिन्हीपैकी कोणते सर्वात वेगवान आहे?

Throughput समान असतो, कारण तिन्ही WireGuard वापरून packets पाठवतात. फरक connection setup आणि path quality मध्ये दिसतो. योग्य Endpoint असलेले Plain WireGuard प्रत्येक वेळी direct connect होते. Tailscale आणि Headscale बहुतेक वेळा direct connect होतात आणि network hole punching block करत असल्यास relay कडे वळतात. Relayed path मुळे latency वाढते. तुमचा path tailscale ping <node> वापरून मोजा. हे route direct आहे की relayed ते दाखवते. तुम्ही tunnel वर iperf3 वापरूनही मोजू शकता. Direct path वर हा आकडा तुमच्या line rate पेक्षा खूपच कमी असल्यास, या तिन्हीपैकी निवड ही समस्या निर्माण करणारी बाब नाही. अशा वेळी सामान्य कारण म्हणजे path MTU mismatch असते. Control plane असो वा नसो, ते त्याच प्रकारे परिणाम करते.