WireGuard, Tailscale और Headscale में क्या अंतर है?

WireGuard बनाम Tailscale: संक्षिप्त उत्तर

WireGuard और Tailscale के बीच चुनाव दो अलग-अलग प्रोटोकॉल के बीच का चुनाव नहीं है, क्योंकि Tailscale स्वयं WireGuard ही है। Tailscale वही एन्क्रिप्शन और वही टनल इस्तेमाल करता है, लेकिन साथ में एक कंट्रोल प्लेन जोड़ देता है: एक कोऑर्डिनेशन सर्वर जो पब्लिक कीज़ (public keys) का आदान-प्रदान करता है, IP एड्रेस आवंटित करता है, NAT (नेटवर्क एड्रेस ट्रांसलेशन) के माध्यम से होल पंचिंग करता है और एक्सेस पॉलिसी लागू करता है। आप यह चुन रहे हैं कि आप इस कोऑर्डिनेशन का कितना हिस्सा स्वयं मैनेज करना चाहते हैं।

इसके तीन स्पष्ट उत्तर हैं। जब आपके पास एक सर्वर और कुछ क्लाइंट्स हों जो सभी उसी से कनेक्ट होते हैं, तो साधारण WireGuard का उपयोग करें। जब आप चाहते हैं कि हर मशीन बिना किसी कॉन्फ़िगरेशन फ़ाइल को मेंटेन किए दूसरी हर मशीन से जुड़ सके, तो Tailscale का उपयोग करें। जब आप वह मेश नेटवर्क तो चाहते हैं, लेकिन यह नहीं चाहते कि कोई थर्ड पार्टी आपके नोड की सूची रखे, तो Headscale का उपयोग करें।

कंट्रोल प्लेन वास्तव में आपको क्या प्रदान करता है

साधारण WireGuard में कोई डिस्कवरी नहीं होती है। प्रत्येक पीयर टेक्स्ट का एक ब्लॉक होता है जिसे आप हाथ से लिखते हैं: एक पब्लिक की, एक AllowedIPs लाइन, और यदि वह पीयर पहुँच योग्य है तो एक Endpoint। दस मशीनों के नेटवर्क में एक मशीन जोड़ने का मतलब है दस कॉन्फ़िगरेशन फ़ाइलों को संपादित करना, क्योंकि प्रत्येक पक्ष को दूसरे की की (key) की आवश्यकता होती है। यही कारण है कि लगभग सभी सेल्फ-होस्टेड WireGuard सेटअप हब और स्पोक मॉडल पर आधारित होते हैं: एक सर्वर जिसमें पब्लिक IP होता है, और क्लाइंट जो केवल उसी से बात करते हैं।

एक कंट्रोल प्लेन संपादन की आवश्यकता को समाप्त कर देता है। प्रत्येक नोड एक बार रजिस्टर होता है, 100.64.0.0/10 CGNAT (कैरियर ग्रेड NAT) रेंज से एक एड्रेस प्राप्त करता है, और उसे उन नोड्स की पब्लिक कीज़ के बारे में बताया जाता है जिनसे उसे जुड़ने की अनुमति है। टनल अभी भी दो पीयर्स के बीच सीधा WireGuard कनेक्शन ही रहती है, और आपका ट्रैफ़िक कभी भी कोऑर्डिनेशन सर्वर से होकर नहीं गुजरता है। सर्वर केवल मेटाडेटा को संभालता है: कौन मौजूद है, उनकी की क्या है, और कौन किससे बात कर सकता है।

इससे तीन ठोस लाभ मिलते हैं।

NAT ट्रैवर्सल। दो होम राउटर के पीछे मौजूद दो लैपटॉप के बीच कोई पब्लिक IP नहीं होता है। Tailscale प्रत्येक पक्ष के बाहरी एड्रेस और पोर्ट को खोजने के लिए STUN (सेशन ट्रैवर्सल यूटिलिटीज फॉर NAT) का उपयोग करता है, फिर दोनों पक्ष एक ही समय पर पैकेट भेजते हैं ताकि प्रत्येक राउटर पहले आउटगोइंग फ़्लो को देखे और रिप्लाई को स्वीकार कर ले। जब यह विफल हो जाता है, तो ट्रैफ़िक DERP रिले पर वापस चला जाता है, जो Tailscale द्वारा संचालित एक एन्क्रिप्टेड रिले है। आपका डेटा रिले के माध्यम से एंड-टू-एंड एन्क्रिप्टेड रहता है, क्योंकि रिले के पास कभी भी कीज़ नहीं होती हैं। tailscale status चलाएं और प्रत्येक पीयर लाइन direct या relay दिखाएगी। यह देखने के लिए कि कौन सा रिले सबसे निकट है और क्या आपका नेटवर्क UDP की अनुमति देता है, tailscale netcheck चलाएं।

समाप्ति तिथि (expiry) के साथ की रोटेशन। WireGuard कीज़ कभी समाप्त नहीं होती हैं। तीन साल पहले जारी की गई की हमेशा काम करती है जब तक कि आप पीयर ब्लॉक को हाथ से डिलीट न कर दें। इसके विपरीत Tailscale नोड कीज़ को समाप्त कर देता है, और जुलाई 2026 तक एक नए tailnet पर डिफ़ॉल्ट समाप्ति अवधि 180 दिन है। जो मशीन फिर से ऑथेंटिकेट नहीं हुई है, वह कनेक्ट होना बंद कर देती है। आप किसी सर्वर या सबनेट राउटर के लिए प्रति डिवाइस समाप्ति को बंद कर सकते हैं, जहाँ लॉगिन करने के लिए कोई मौजूद नहीं होगा।

राउटिंग के बजाय पॉलिसी। साधारण WireGuard में, AllowedIPs एक ही समय में राउटिंग टेबल और एक्सेस कंट्रोल लिस्ट दोनों होता है, इसलिए "alice डेटाबेस तक पहुँच सकती है" को IP रेंज के रूप में व्यक्त करना पड़ता है। Tailscale एक अलग पॉलिसी फ़ाइल रखता है जहाँ नियम उपयोगकर्ताओं, समूहों और टैग्स के नाम का उपयोग करते हैं। एक नियम यह कह सकता है कि tag:laptop को पोर्ट 5432 पर tag:db तक पहुँचने की अनुमति है और इसके अलावा कुछ भी नहीं, और यह नियम मशीन को नया एड्रेस मिलने पर भी प्रभावी रहता है।

कंट्रोल प्लेन की लागत

कोऑर्डिनेशन सर्वर आपके नेटवर्क को जानता है। इसमें प्रत्येक नोड की पब्लिक की, नोड का नाम, आवंटित पते और पॉलिसी की जानकारी होती है। होस्टेड Tailscale के मामले में, यह एक ऐसी कंपनी है जो आपके नियंत्रण से बाहर है। आपके पैकेट उन्हें नहीं दिख सकते, क्योंकि WireGuard की प्राइवेट की आपकी मशीनों पर ही रहती हैं, लेकिन आपके नेटवर्क की संरचना उन्हें दिखाई देती है, और आपकी कनेक्टिविटी उनकी सर्विस के चालू रहने और आपके अकाउंट की स्थिति पर निर्भर करती है। इसका कितना महत्व है, यह इस बात पर निर्भर करता है कि एक समझौता किए गए (compromised) कोऑर्डिनेशन सर्वर या चोरी किए गए अकाउंट के साथ क्या किया जा सकता है, जो कि Tailscale के ट्रस्ट मॉडल को पूरा पढ़ने योग्य बनाता है।

एक दूसरी लागत भी है जिसे नजरअंदाज करना आसान है। Tailscale हर मशीन पर चलने वाला एक डेमन (daemon) है, इसलिए यह वह सॉफ्टवेयर है जिसे अब आपको हर मशीन पर पैच करना होगा। Ubuntu 24.04 पर साधारण WireGuard एक कर्नल मॉड्यूल है जो डिस्ट्रीब्यूशन के साथ आता है और कर्नल के साथ अपडेट होता रहता है।

तीसरी लागत बिलिंग की है। जुलाई 2026 तक, पर्सनल प्लान 6 उपयोगकर्ताओं तक के लिए असीमित डिवाइस के साथ मुफ्त है, स्टैंडर्ड प्लान $8 प्रति उपयोगकर्ता प्रति माह है, और प्रीमियम प्लान $18 प्रति उपयोगकर्ता प्रति माह है। एक घर के लिए यह मुफ्त रहता है। दस लोगों की टीम के लिए ऐसा नहीं है। आप उस सीमा को पार करते हैं या नहीं, यह डिवाइस की संख्या के बजाय सीटों (seats) का सवाल है, और फ्री प्लान वास्तव में क्या कवर करता है इसे सातवें उपयोगकर्ता को आमंत्रित करने से पहले पढ़ लेना चाहिए।

जब plain WireGuard सही विकल्प हो

जब topology वास्तव में hub and spoke हो, तब plain WireGuard चुनें। एक public IP वाला VPS, उससे जुड़ने वाले तीन या चार उपकरण, और उन उपकरणों के आपस में जुड़ने की कोई आवश्यकता न हो। इसका config एक स्क्रीन पर आ जाता है, इसमें update करने के लिए कोई daemon नहीं होता, खोने के लिए कोई account नहीं होता, और आपके तथा आपके सर्वर के बीच कोई बाहरी सेवा नहीं होती।

यह तब भी सही विकल्प है जब आप उस layer को समझना चाहते हैं जिस पर बाकी सब कुछ बना है। VPS पर WireGuard VPN को self-host करना key generation, wg0.conf, IP forwarding, NAT और handshake failures के बारे में विस्तार से बताता है, और इनमें से हर एक mechanism tailnet के नीचे भी काम कर रहा होता है। यदि आप अभी भी पुराने विकल्प पर विचार कर रहे हैं, तो WireGuard बनाम OpenVPN उन चार स्थितियों को कवर करता है जहाँ OpenVPN का लाभ बना रहता है।

इसका install छोटा है:

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

plain WireGuard तब असुविधाजनक हो जाता है जब हर उपकरण को हर दूसरे उपकरण तक पहुँचना हो। N nodes के full mesh के लिए N गुना N minus एक peer blocks की आवश्यकता होती है। छह उपकरणों पर यह तीस blocks होते हैं जिन्हें हाथ से sync रखना पड़ता है, और एक duplicate AllowedIPs entry चुपचाप उस peer से traffic चुरा लेती है जिसके पास वह पहले थी, और कहीं भी कोई error print नहीं होता।

जब Tailscale सही विकल्प हो

Tailscale का चुनाव तब करें जब मशीनें एक स्थान से दूसरे स्थान पर जाती रहती हैं। होटल नेटवर्क पर लैपटॉप, मोबाइल डेटा पर फोन, या ऐसे राउटर के पीछे स्थित होम सर्वर जिसे आप नियंत्रित नहीं करते हैं। ये बिल्कुल वही स्थितियां हैं जिन्हें सामान्य WireGuard ठीक से नहीं संभाल पाता, क्योंकि किसी भी तरफ कोई स्थिर पब्लिक एंडपॉइंट नहीं होता जिसे Endpoint में डाला जा सके।

क्लाइंट को इंस्टॉल करना आधिकारिक इंस्टॉलर से केवल एक कमांड का काम है:

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

tailscale up एक URL प्रिंट करता है। उसे खोलें, लॉग इन करें, और मशीन नेटवर्क से जुड़ जाएगी। इसमें कॉपी करने के लिए कोई की (key) नहीं है और न ही कोई इनबाउंड पोर्ट खोलने की आवश्यकता है, क्योंकि डेमन (daemon) कोऑर्डिनेशन सर्वर से एक आउटबाउंड कनेक्शन बनाता है और उसे खुला रखता है। यही कारण है कि Tailscale नोड ऐसे नेटवर्क पर भी काम करता है जहाँ आपका किसी भी फायरवॉल पर कोई नियंत्रण नहीं है।

उसके बाद दो सेटिंग्स अधिकांश उपयोगी काम करती हैं। एक सबनेट राउटर पूरे LAN को नेटवर्क में एडवर्टाइज करता है ताकि आपको हर डिवाइस पर क्लाइंट इंस्टॉल न करना पड़े:

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

यह रूट तब तक निष्क्रिय रहता है जब तक आप इसे एडमिन कंसोल में अप्रूव नहीं करते, जो कि जानबूझकर किया गया है: कोई नोड अपने आप आपके नेटवर्क में रूट इंजेक्ट नहीं कर सकता। Linux क्लाइंट्स को sudo tailscale set --accept-routes की भी आवश्यकता होती है, क्योंकि Linux डिफ़ॉल्ट रूप से एडवर्टाइज किए गए रूट को स्वीकार नहीं करता है। इसलिए, सर्वर साइड पर अप्रूव्ड दिखने वाला रूट भी Linux लैपटॉप पर तब तक काम नहीं करता जब तक आप उसे सेट न कर लें। यदि आप यही सेटअप चाहते हैं, तो running a subnet router on a VPS अप्रूवल स्टेप और फॉरवर्डिंग सेटिंग्स को उस क्रम में बताता है जिससे आधा-अधूरा काम करने वाला रूट न बने।

एक एग्जिट नोड क्लाइंट के सभी ट्रैफिक को एक मशीन के माध्यम से भेजता है, जो कि पूर्ण टनल व्यवहार है जिसे लोग आमतौर पर "VPN" कहते हैं:

sudo tailscale set --advertise-exit-node

वह फ्लैग आसान हिस्सा है, और turning a VPS into an exit node उसके बाद की प्रक्रिया को कवर करता है: एडमिन कंसोल में रूट को अप्रूव करना, फिर DNS और IPv6 व्यवहार को ठीक करना जो अन्यथा ट्रैफिक को गलत रास्ते से बाहर जाने देता है। यदि आप पूरे नेटवर्क के बजाय केवल एक वेब सर्विस तक पहुँचना चाहते हैं, तो serve and funnel एक सिंगल लोकल पोर्ट के सामने HTTPS लगा देते हैं, जो या तो केवल tailnet के लिए होता है या पब्लिक इंटरनेट के लिए खुला होता है।

Headscale कब सही विकल्प है

Headscale, coordination server का एक open source implementation है, जो आपके अपने VPS पर चलता है। आधिकारिक Tailscale clients, hosted service के बजाय इसकी ओर point करते हैं:

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

Data path के बारे में सब कुछ अपरिवर्तित रहता है। यह अभी भी WireGuard है, और जहाँ network अनुमति देता है, वहाँ peers के बीच सीधा connection बना रहता है। जो बदलता है वह यह है कि node list, keys और policy आपकी अपनी disk पर मौजूद एक SQLite file में रहती हैं। आपके network के स्वरूप को बाहर का कोई व्यक्ति नहीं देख सकता, आपके account को disable नहीं कर सकता, और न ही आपसे प्रति user शुल्क ले सकता है।

इसका trade-off यह है कि इसमें वास्तविक मेहनत लगती है। अब आप एक public HTTPS service चला रहे हैं, जिसका अर्थ है कि आपको एक DNS name, एक certificate और एक ऐसे reverse proxy की आवश्यकता है जो WebSocket upgrades को सही ढंग से pass करे। इसके uptime की जिम्मेदारी आपकी है, और यदि coordination server down है, तो नए nodes register नहीं हो सकते और मौजूदा nodes को बदलावों की जानकारी नहीं मिल सकती। Headscale अभी version 1.0 से नीचे है और इसके minor releases में breaking changes आते रहे हैं, इसलिए हर upgrade से पहले changelog जरूर पढ़ें। Headscale को अपने Tailscale control server के रूप में चलाना में install, config.yaml, preauth keys और open किए जाने वाले ports की जानकारी दी गई है।

एक चेतावनी जो लोगों को बाद में समझ आती है: Headscale, Tailscale के global relay network के साथ नहीं आता है। जहाँ दो peers सीधे connect नहीं हो पाते, वहाँ आपको या तो अपने server पर embedded relay enable करना होगा या config को किसी अन्य server की ओर point करना होगा, और वह relay दुनिया भर के fleet के बजाय एक ही region में स्थित एक single box होता है। पृथ्वी के दूसरी ओर स्थित peers को यह अंतर महसूस होता है। यदि आप उस हिस्से को खुद assemble नहीं करना चाहते हैं, तो NetBird को self-host करना control plane को अपने पास रखने का दूसरा तरीका है, क्योंकि इसका quickstart management, signal और relay services को एक ही VPS पर एक साथ खड़ा कर देता है।

एक बार में निर्णय कैसे लें

यह पूछें कि कितनी मशीनों को एक-दूसरे से संपर्क करने की आवश्यकता है। यदि उत्तर यह है कि वे सभी केवल सर्वर से बात करती हैं, तो plain WireGuard समान परिणाम के लिए कम सॉफ्टवेयर का उपयोग करता है।

यह पूछें कि क्या मशीनों के पास स्थिर public addresses हैं। यदि उनमें से अधिकांश ऐसे NAT के पीछे हैं जिसे आप नियंत्रित नहीं करते हैं, तो आपको एक control plane की आवश्यकता होगी, क्योंकि hole punching एक कठिन कार्य है और इसे दोबारा बनाना सार्थक नहीं है।

यह पूछें कि आपके नेटवर्क की संरचना जानने की अनुमति किसे है। यदि उत्तर में बाहरी कंपनियों को शामिल नहीं किया गया है, या आपके उपयोगकर्ताओं की संख्या के कारण per-seat billing महंगी पड़ती है, तो Headscale चलाएं और यह स्वीकार करें कि अब आप control server का संचालन करते हैं। यदि billing ही मुख्य कारण है, तो migration के लिए प्रतिबद्ध होने से पहले गणना कर लें, क्योंकि आपके आकार की टीम वास्तव में कितना भुगतान करती है यह इस पर निर्भर करता है कि कितने लोगों के पास accounts हैं, न कि इस पर कि आप कितनी मशीनें चलाते हैं, और ये दोनों संख्याएं शायद ही कभी समान होती हैं।

आप अपना निर्णय कम लागत पर बदल सकते हैं। चूंकि data plane तीनों में एक ही protocol का उपयोग करता है, इसलिए plain WireGuard से coordinated mesh पर जाना केवल एक client install है, न कि redesign। और Tailscale से Headscale पर जाना प्रत्येक node को एक अलग login server के साथ फिर से register करना मात्र है।

ये तीनों आपको क्या नहीं देते हैं

इनमें से कोई भी firewall नहीं है। एक tunnel यह तय करती है कि कौन से packets ले जाए जाएंगे, न कि यह कि कौन सी services listen करेंगी। tunnel के माध्यम से पहुँच योग्य सर्वर अभी भी internet से उन सभी ports पर पहुँच योग्य रहता है जिन्हें आपने खुला छोड़ा है, इसलिए VPS पर UFW firewall rules को अपना काम करने दें। Tailscale की policy file यह सीमित करती है कि अन्य nodes क्या पहुँच सकते हैं, और यह public interface के बारे में कुछ नहीं करती है।

इनमें से कोई भी per-service authentication नहीं है, और इनमें से कोई भी इस बात का audit trail नहीं है कि एक बार connect होने के बाद user ने क्या किया। इन तीनों को transport के रूप में मानें, और login checks को application में ही रखें।

FAQ

क्या Tailscale केवल अतिरिक्त चरणों वाला WireGuard है?

Tailscale डेटा पाथ के लिए WireGuard प्रोटोकॉल का उपयोग करता है, इसलिए एन्क्रिप्शन और टनल समान हैं। यह समन्वय (coordination) जोड़ता है: की-एक्सचेंज, एड्रेस असाइनमेंट, STUN और DERP रिले के साथ NAT ट्रैवर्सल, की-एक्सपायरी, और एक पॉलिसी फाइल जो IP रेंज के बजाय उपयोगकर्ताओं के नाम का उपयोग करती है। ये वे हिस्से हैं जिन्हें साधारण WireGuard आप पर छोड़ देता है, और जब मशीनें नेटवर्क के बीच मूव करती हैं तो ये हिस्से कठिन हो जाते हैं।

क्या मेरा ट्रैफ़िक Tailscale के सर्वर से होकर जाता है?

आमतौर पर नहीं। एक बार जब कोऑर्डिनेशन सर्वर पीयर्स (peers) का परिचय करा देता है, तो वे सीधे एक-दूसरे से जुड़ जाते हैं, और tailscale status उन पीयर लाइनों पर direct दिखाता है। जब सीधा रास्ता (direct path) स्थापित नहीं हो पाता, तो ट्रैफ़िक DERP रिले पर वापस चला जाता है और लाइन relay पढ़ती है। तब भी रिले एन्क्रिप्टेड पैकेट ले जाता है और आपकी WireGuard प्राइवेट कीज़ को नहीं रखता है, इसलिए यह सामग्री को पढ़ नहीं सकता। यह देखने के लिए कि क्या आपका नेटवर्क उस UDP को ब्लॉक कर रहा है जिसकी सीधे कनेक्शन के लिए आवश्यकता है, tailscale netcheck चलाएँ।

क्या मैं आधिकारिक Tailscale ऐप्स के साथ Headscale का उपयोग कर सकता हूँ?

हाँ। Headscale उसी कंट्रोल प्रोटोकॉल का उपयोग करता है, इसलिए आधिकारिक क्लाइंट sudo tailscale up --login-server https://headscale.example.com के साथ जुड़ जाते हैं। डेस्कटॉप और मोबाइल ऐप्स को भी एक कस्टम लॉगिन सर्वर पर पॉइंट किया जा सकता है, हालाँकि यह सेटिंग हर प्लेटफ़ॉर्म पर अलग जगह होती है, और मोबाइल ऐप्स में किसी विशिष्ट वर्ज़न की आवश्यकता होने की संभावना सबसे अधिक होती है। पूरे नेटवर्क को माइग्रेट करने से पहले एक फ़ोन पर परीक्षण करें।

क्या मुझे अभी भी Tailscale या Headscale के लिए पोर्ट खोलने की आवश्यकता है?

Tailscale क्लाइंट को किसी इनबाउंड पोर्ट की आवश्यकता नहीं होती है, क्योंकि यह कोऑर्डिनेशन सर्वर से बाहर की ओर डायल करता है और उस कनेक्शन को खुला रखता है। एक सेल्फ-होस्टेड Headscale सर्वर को इनबाउंड पोर्ट की आवश्यकता होती है: कंट्रोल प्रोटोकॉल के लिए 443, यदि आप HTTP-01 सर्टिफिकेट चैलेंज का उपयोग करते हैं तो 80, और केवल तभी जब आप एम्बेडेड रिले को सक्षम करते हैं तो 3478/udp। साधारण WireGuard को अपने UDP लिसन पोर्ट, आमतौर पर 51820, को सर्वर पर और आपके प्रदाता द्वारा चलाए जाने वाले किसी भी अलग नेटवर्क फ़ायरवॉल पर खोलने की आवश्यकता होती है।

तीनों में से सबसे तेज़ कौन सा है?

थ्रूपुट समान है, क्योंकि तीनों WireGuard के साथ पैकेट मूव करते हैं। अंतर कनेक्शन सेटअप और पाथ क्वालिटी में दिखाई देता है। सही Endpoint के साथ साधारण WireGuard हर बार सीधे जुड़ता है। Tailscale और Headscale अधिकांश समय सीधे जुड़ते हैं और जब नेटवर्क होल पंचिंग को ब्लॉक करता है तो रिले पर वापस चले जाते हैं, और रिलेड पाथ लेटेंसी बढ़ाता है। tailscale ping <node> के साथ अपने स्वयं के पाथ को मापें, जो रिपोर्ट करता है कि रूट सीधा है या रिलेड, या टनल के पार iperf3 के साथ। यदि वह संख्या सीधे पाथ पर आपकी लाइन रेट से काफी नीचे आती है, तो तीनों के बीच का चुनाव वह नहीं है जो आपको नुकसान पहुँचा रहा है, और इसका सामान्य कारण पाथ MTU मिसमैच है जो कंट्रोल प्लेन के साथ या उसके बिना समान रूप से व्यवहार करता है।