SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-11-01

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

WireGuard, Tailscale और Headscale के बीच का मुख्य अंतर समझें। जानें कि कब साधारण WireGuard का उपयोग करें, कब Tailscale का कंट्रोल प्लेन चुनें और कब Headscale का उपयोग करना सही है।

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

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

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

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

साधारण WireGuard में कोई discovery नहीं होती है। प्रत्येक peer टेक्स्ट का एक ब्लॉक होता है जिसे आप हाथ से लिखते हैं: एक public key, एक AllowedIPs लाइन, और यदि वह peer reachable है तो एक Endpoint। दस मशीनों के नेटवर्क में एक मशीन जोड़ने का मतलब है दस कॉन्फ़िगरेशन फ़ाइलों को एडिट करना, क्योंकि प्रत्येक साइड को दूसरी साइड की key की आवश्यकता होती है। यही कारण है कि लगभग हर self-hosted WireGuard सेटअप hub and spoke मॉडल पर आधारित होता है: एक public IP वाला सर्वर, और ऐसे क्लाइंट जो केवल उसी से बात करते हैं।

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

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

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

एक्सपायरी के साथ key रोटेशन। WireGuard keys कभी एक्सपायर नहीं होती हैं। तीन साल पहले जारी की गई key हमेशा काम करती है जब तक कि आप peer ब्लॉक को मैन्युअल रूप से डिलीट न कर दें। इसके विपरीत, Tailscale नोड keys को एक्सपायर करता है, और अक्टूबर 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) का सवाल है, न कि डिवाइस का, सिवाय एक अपवाद के: सर्वर और अन्य टैग किए गए डिवाइस की अपनी अलग सीमा होती है। प्रत्येक प्लान में 50 टैग किए गए संसाधन शामिल हैं, और अक्टूबर 2026 तक, प्राइसिंग पेज पर उससे अधिक प्रत्येक संसाधन के लिए $1 प्रति माह का शुल्क सूचीबद्ध है। फ्री प्लान वास्तव में क्या कवर करता है इसे सातवें उपयोगकर्ता को आमंत्रित करने या इक्यावनवें सर्वर को टैग करने से पहले पढ़ना उचित है।

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

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

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

install करना संक्षिप्त है:

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

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

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 लैपटॉप पर तब तक काम नहीं करता जब तक आप उसे सेट न कर दें। यदि आप यही सेटअप चाहते हैं, तो VPS पर सबनेट राउटर चलाना अप्रूवल स्टेप और फॉरवर्डिंग सेटिंग्स को उस क्रम में बताता है जिससे अधूरा काम करने वाला रूट न बने।

एक एग्जिट नोड क्लाइंट के सामान्य इंटरनेट ट्रैफिक को—यानी वह सब कुछ जो पहले से किसी अन्य tailnet डिवाइस या अप्रूव्ड सबनेट रूट की ओर नहीं जा रहा है—एक मशीन के माध्यम से भेजता है। यह वही पूर्ण टनल व्यवहार है जिसे लोग आमतौर पर "VPN" कहते हैं। Linux पर इसे एडवर्टाइज करने से पहले ऊपर दिखाई गई IP फॉरवर्डिंग सेटिंग्स की आवश्यकता होती है:

sudo tailscale set --advertise-exit-node

वह फ्लैग आसान हिस्सा है, और VPS को एग्जिट नोड में बदलना उसके बाद की प्रक्रिया को कवर करता है: एडमिन कंसोल में रूट को अप्रूव करना, फिर DNS और IPv6 व्यवहार को ठीक करना जो अन्यथा ट्रैफिक को गलत दिशा में भेज देता है। यदि आप पूरे नेटवर्क के बजाय केवल एक वेब सर्विस तक पहुँचना चाहते हैं, तो serve और 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 करना होगा या configuration को किसी अन्य relay की ओर point करना होगा। वह relay worldwide fleet के बजाय एक ही region में मौजूद एक single box होता है। ग्रह के दूसरे छोर पर मौजूद peers को इस अंतर का प्रभाव स्पष्ट रूप से महसूस होता है। यदि आप यह हिस्सा स्वयं assemble नहीं करना चाहते, तो NetBird को self-host करना control plane को अपने infrastructure में रखने का दूसरा तरीका है, क्योंकि इसका quickstart management, signal और relay services को एक ही VPS पर साथ में शुरू करता है। हालांकि NetBird, Headscale की तरह Tailscale server का drop-in विकल्प नहीं है। यह अपने clients और अपना policy model देता है। इसलिए Headscale के बजाय इसे चुनने से पहले access rules और relays के मामले में NetBird और Tailscale कैसे अलग हैं पढ़ें।

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

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

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

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

आप अपना निर्णय कम लागत पर बदल सकते हैं। चूंकि 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 मिसमैच है जो कंट्रोल प्लेन के साथ या उसके बिना समान रूप से व्यवहार करता है।

क्या यह लेख उपयोगी था?