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 मध्ये डिस्कव्हरी नसते. प्रत्येक पीअर (peer) म्हणजे तुम्ही हाताने लिहिलेला मजकूर असतो: एक पब्लिक की, एक AllowedIPs ओळ, आणि जर तो पीअर पोहोचण्यायोग्य असेल तर एक Endpoint. दहा मशीनच्या नेटवर्कमध्ये एक नवीन मशीन जोडणे म्हणजे दहा कॉन्फिगरेशन फाइल्स एडिट करणे, कारण प्रत्येक बाजूला दुसऱ्याची की आवश्यक असते. म्हणूनच जवळजवळ सर्व self-hosted WireGuard सेटअप हे हब आणि स्पोक (hub and spoke) स्वरूपाचे असतात: एक पब्लिक IP असलेला सर्व्हर आणि फक्त त्याच्याशीच संवाद साधणारे क्लायंट्स.

कंट्रोल प्लेनमुळे ही एडिटिंगची गरज संपते. प्रत्येक नोड एकदा रजिस्टर होतो, त्याला 100.64.0.0/10 CGNAT (carrier grade NAT) रेंजमधून एक ॲड्रेस मिळतो, आणि त्याला कोणत्या नोड्सपर्यंत पोहोचण्याची परवानगी आहे त्यांच्या पब्लिक कीज दिल्या जातात. टनेल अजूनही दोन पीअर्समधील थेट WireGuard कनेक्शनच असते आणि तुमचा ट्रॅफिक कधीही कोऑर्डिनेशन सर्व्हरवरून जात नाही. सर्व्हर फक्त मेटाडेटा हाताळतो: कोण अस्तित्वात आहे, त्यांची की कोणती आहे आणि कोणाला कोणाशी बोलण्याची परवानगी आहे.

याचे तीन ठोस फायदे आहेत.

NAT ट्रॅव्हर्सल. दोन होम राउटरच्या मागे असलेल्या दोन लॅपटॉप्सकडे स्वतःचा पब्लिक IP नसतो. Tailscale प्रत्येक बाजूचा बाहेरील ॲड्रेस आणि पोर्ट शोधण्यासाठी STUN (session traversal utilities for NAT) वापरते. त्यानंतर दोन्ही बाजू एकाच वेळी पॅकेट्स पाठवतात, जेणेकरून प्रत्येक राउटरला आधी आउटगोइंग फ्लो दिसतो आणि तो रिप्लाय स्वीकारतो. जेव्हा हे अपयशी ठरते, तेव्हा ट्रॅफिक DERP रिलेवर शिफ्ट होतो, जो Tailscale द्वारे चालवला जाणारा एक एनक्रिप्टेड रिले आहे. तुमचा डेटा रिलेद्वारे एंड-टू-एंड एनक्रिप्टेड राहतो, कारण रिलेकडे कधीही कीज नसतात. tailscale status रन करा, प्रत्येक पीअर ओळीवर direct किंवा relay दिसेल. कोणता रिले सर्वात जवळ आहे आणि तुमचे नेटवर्क UDP ला परवानगी देते का हे पाहण्यासाठी tailscale netcheck रन करा.

एक्सपायरीसह की रोटेशन. WireGuard कीज कधीही एक्सपायर होत नाहीत. तुम्ही तीन वर्षांपूर्वी दिलेली की जोपर्यंत तुम्ही पीअर ब्लॉक हाताने डिलीट करत नाही, तोपर्यंत काम करत राहते. Tailscale त्याऐवजी नोड कीज एक्सपायर करते आणि ऑक्टोबर 2026 पासून नवीन tailnet वर डीफॉल्ट एक्सपायरी कालावधी 180 दिवस आहे. ज्या मशीनने पुन्हा ऑथेंटिकेट केलेले नाही, ते कनेक्ट होणे थांबवते. सर्व्हर किंवा सबनेट राउटरसाठी, जिथे लॉग इन करण्यासाठी कोणीही उपलब्ध नसेल, तुम्ही प्रति डिव्हाइस एक्सपायरी बंद करू शकता.

राउटिंगऐवजी पॉलिसी. साध्या WireGuard मध्ये, AllowedIPs हे राउटिंग टेबल आणि ॲक्सेस कंट्रोल लिस्ट दोन्ही असते, त्यामुळे "alice डेटाबेसपर्यंत पोहोचू शकते" हे IP रेंजच्या स्वरूपात सांगावे लागते. Tailscale एक स्वतंत्र पॉलिसी फाइल ठेवते जिथे नियम वापरकर्ते, गट आणि टॅग्सच्या नावाने असतात. एक नियम सांगू शकतो की tag:laptop ला tag:db वर पोर्ट 5432 वर पोहोचण्याची परवानगी आहे आणि त्याशिवाय काहीही नाही. मशीनला नवीन ॲड्रेस मिळाला तरी हा नियम कायम राहतो.

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

कोऑर्डिनेशन सर्व्हरला तुमच्या नेटवर्कची माहिती असते. यामध्ये प्रत्येक नोडची पब्लिक की, नोडचे नाव, दिलेले पत्ते आणि धोरणे (policy) साठवलेली असतात. जर तुम्ही Tailscale ची होस्टेड सेवा वापरत असाल, तर ही माहिती तुमच्या नियंत्रणाबाहेरील एका कंपनीकडे असते. तुमचे पॅकेट्स ते वाचू शकत नाहीत, कारण WireGuard च्या प्रायव्हेट की तुमच्या मशीनवरच राहतात. मात्र, तुमच्या नेटवर्कची रचना त्यांना दिसते आणि तुम्ही एकमेकांशी कनेक्ट होऊ शकणार की नाही, हे त्यांच्या सेवेच्या उपलब्धतेवर आणि तुमच्या खात्याच्या स्थितीवर अवलंबून असते. या गोष्टीला किती महत्त्व द्यावे, हे यावर अवलंबून आहे की एखादा कॉम्प्रमाइज झालेला कोऑर्डिनेशन सर्व्हर किंवा चोरीला गेलेले खाते काय करू शकते. याबद्दल अधिक माहितीसाठी Tailscale चा ट्रस्ट मॉडेल पूर्णपणे वाचणे फायदेशीर ठरेल.

दुसरी एक किंमत आहे जी सहसा दुर्लक्षित केली जाते. Tailscale हे प्रत्येक मशीनवर चालणारे एक daemon आहे, त्यामुळे तुम्हाला प्रत्येक मशीनवर हे सॉफ्टवेअर अपडेट ठेवावे लागते. Ubuntu 24.04 वरील साधे WireGuard हे एक कर्नल मॉड्यूल आहे, जे डिस्ट्रिब्युशनसोबतच येते आणि कर्नल अपडेट्ससोबत आपोआप अपडेट होते.

तिसरी किंमत म्हणजे बिलिंग. ऑक्टोबर 2026 पर्यंत, Personal प्लॅन 6 वापरकर्त्यांपर्यंत अमर्यादित उपकरणांसाठी मोफत आहे. Standard प्लॅनची किंमत प्रति वापरकर्ता दरमहा $8 आहे आणि Premium प्लॅनची किंमत प्रति वापरकर्ता दरमहा $18 आहे. घरगुती वापरासाठी हे मोफत राहते, पण दहा लोकांच्या टीमसाठी तसे नाही. तुम्ही या मर्यादेच्या पलीकडे जाता का, हे प्रामुख्याने वापरकर्त्यांच्या संख्येवर अवलंबून असते, उपकरणांच्या संख्येवर नाही. मात्र, यात एक अपवाद आहे: सर्व्हर्स आणि इतर टॅग केलेली उपकरणे यांची स्वतःची वेगळी मर्यादा असते. प्रत्येक प्लॅनमध्ये 50 टॅग केलेली संसाधने समाविष्ट आहेत आणि ऑक्टोबर 2026 च्या माहितीनुसार, त्यापुढील प्रत्येक संसाधनासाठी दरमहा $1 शुल्क आकारले जाते. सातवा वापरकर्ता जोडण्यापूर्वी किंवा एकावन्नवा सर्व्हर टॅग करण्यापूर्वी मोफत प्लॅनमध्ये नक्की काय समाविष्ट आहे हे वाचणे महत्त्वाचे आहे.

जेव्हा साधे WireGuard हा योग्य पर्याय असतो

जेव्हा टोपोलॉजी खरोखरच 'हब आणि स्पोक' (hub and spoke) स्वरूपाची असते, तेव्हा साधे WireGuard निवडा. एक VPS ज्याला सार्वजनिक IP आहे, त्याला जोडलेली तीन किंवा चार उपकरणे आणि त्या उपकरणांना एकमेकांशी जोडण्याची कोणतीही गरज नाही, अशी स्थिती असल्यास हे योग्य ठरते. याचे कॉन्फिगरेशन एका स्क्रीनवर मावते, अपडेट करण्यासाठी कोणताही डॅमन (daemon) नसतो, गमावण्यासाठी कोणतेही खाते नसते आणि तुमच्या व तुमच्या सर्व्हरच्या मध्ये कोणतीही बाह्य सेवा नसते.

ज्या पायावर इतर सर्व गोष्टी उभ्या आहेत, तो समजून घ्यायचा असेल तेव्हाही हाच योग्य पर्याय असतो. Self-hosting a WireGuard VPN on a VPS मध्ये की जनरेशन (key generation), wg0.conf, IP फॉरवर्डिंग, NAT आणि हँडशेकमधील त्रुटींची सविस्तर माहिती दिली आहे. प्रत्येक tailnet च्या मागे अजूनही कीज आणि हँडशेक कार्यरत असतात आणि जेव्हा एखादा tailnet नोड सबनेट राउटर किंवा एक्झिट नोड म्हणून काम करतो, तेव्हा IP फॉरवर्डिंगची गरज पुन्हा भासते. जर तुम्ही अजूनही जुन्या पर्यायाचा विचार करत असाल, तर WireGuard vs OpenVPN मध्ये अशा चार परिस्थिती दिल्या आहेत जिथे OpenVPN चा फायदा होतो.

याची स्थापना (install) थोडक्यात आहे:

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

जेव्हा प्रत्येक उपकरणाला इतर प्रत्येक उपकरणापर्यंत पोहोचणे आवश्यक असते, तेव्हा साधे WireGuard वापरणे त्रासदायक ठरू शकते. N नोड्सच्या पूर्ण मेश (full mesh) साठी N गुणिले (N वजा एक) पीअर ब्लॉक्सची गरज असते. सहा उपकरणांच्या बाबतीत, हे तीस ब्लॉक्स हाताने सिंक (sync) करावे लागतात आणि एखादी डुप्लिकेट AllowedIPs एन्ट्री नकळतपणे आधीच्या पीअरकडून ट्रॅफिक चोरते, ज्याची कोणतीही त्रुटी (error) कुठेही दिसत नाही.

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

जेव्हा तुमची उपकरणे सतत फिरती असतात, तेव्हा Tailscale निवडा. हॉटेलमधील लॅपटॉप, मोबाईल डेटावर असलेला फोन किंवा तुमच्या नियंत्रणाबाहेर असलेल्या राउटरमागील होम सर्व्हर अशा परिस्थितींत साधे WireGuard नीट काम करत नाही, कारण दोन्ही बाजूंना Endpoint मध्ये टाकण्यासाठी कोणताही स्थिर सार्वजनिक एंडपॉईंट नसतो.

अधिकृत इंस्टॉलरवरून एक कमांड वापरून तुम्ही क्लायंट इंस्टॉल करू शकता:

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

tailscale up एक URL दाखवेल. ती उघडा, लॉग इन करा आणि तुमचे उपकरण नेटवर्कमध्ये सामील होईल. यामध्ये कोणतीही की कॉपी करण्याची किंवा इनबाउंड पोर्ट उघडण्याची गरज नसते, कारण डेमन (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

जोपर्यंत तुम्ही ॲडमिन कन्सोलमध्ये याला मंजुरी देत नाही, तोपर्यंत हा मार्ग (route) निष्क्रिय राहतो. हे मुद्दाम ठेवलेले आहे, कारण कोणताही नोड स्वतःहून तुमच्या नेटवर्कमध्ये मार्ग इंजेक्ट करू शकत नाही. Linux क्लायंटसाठी sudo tailscale set --accept-routes ची देखील आवश्यकता असते, कारण Linux डीफॉल्टनुसार ॲडव्हर्टाइज केलेले मार्ग स्वीकारत नाही. त्यामुळे सर्व्हरच्या बाजूने मार्ग मंजूर दिसत असला तरी, जोपर्यंत तुम्ही ही सेटिंग करत नाही, तोपर्यंत Linux लॅपटॉपवर तो कार्यरत होत नाही. जर तुम्हाला हीच रचना हवी असेल, तर VPS वर सबनेट राउटर चालवणे या मार्गदर्शिकेत मंजुरीची प्रक्रिया आणि फॉरवर्डिंग सेटिंग्ज अशा क्रमाने दिल्या आहेत, ज्यामुळे मार्ग अर्धवट कार्यरत राहण्याची समस्या उद्भवत नाही.

एक्झिट नोड क्लायंटचा सामान्य इंटरनेट ट्रॅफिक एका विशिष्ट मशीनद्वारे पाठवतो. याचा अर्थ असा की, जे ट्रॅफिक आधीच दुसऱ्या tailnet उपकरणाकडे किंवा मंजूर सबनेट मार्गाकडे जात नाही, ते सर्व या मशीनद्वारे जाते. यालाच लोक सामान्यतः "VPN" म्हणतात. Linux वर, हे ॲडव्हर्टाइज करण्यापूर्वी वर दर्शविल्याप्रमाणे IP फॉरवर्डिंग सेटिंग्जची आवश्यकता असते:

sudo tailscale set --advertise-exit-node

हा फ्लॅग (flag) सोपा भाग आहे आणि VPS ला एक्झिट नोडमध्ये रूपांतरित करणे या लेखात त्यानंतरच्या पायऱ्या दिल्या आहेत: ॲडमिन कन्सोलमध्ये मार्गाला मंजुरी देणे, आणि त्यानंतर DNS व IPv6 चे वर्तन सुधारणे, जेणेकरून ट्रॅफिक चुकीच्या मार्गाने जाणार नाही. जर तुम्हाला संपूर्ण नेटवर्कऐवजी फक्त एक वेब सर्व्हिस वापरायची असेल, तर serve आणि funnel वापरून तुम्ही एका स्थानिक पोर्टसमोर HTTPS लावू शकता, जे फक्त tailnet साठी किंवा सार्वजनिक इंटरनेटसाठी खुले ठेवता येते.

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 थेट कनेक्ट होऊ शकत नसतील, तर तुम्हाला तुमच्या स्वतःच्या server वर embedded relay enable करावा लागतो किंवा config दुसऱ्या relay कडे निर्देशित करावी लागते. हा relay जगभर पसरलेल्या fleet ऐवजी एका region मधील एकाच box वर चालतो. पृथ्वीच्या दुसऱ्या बाजूला असलेल्या peers ना हा फरक जाणवतो. हा भाग स्वतः तयार करायचा नसेल, तर NetBird self-host करणे हा control plane in house ठेवण्याचा दुसरा पर्याय आहे. त्याच्या quickstart मुळे management, signal आणि relay services एकाच VPS वर एकत्र सुरू होतात. मात्र NetBird हा Headscale प्रमाणे drop-in Tailscale server नाही. त्याचे स्वतःचे clients आणि स्वतःचे policy model आहेत. त्यामुळे Headscale ऐवजी NetBird निवडण्यापूर्वी access rules आणि relays बाबत NetBird आणि Tailscale मधील फरक वाचा.

एका प्रयत्नात निर्णय कसा घ्यावा

किती मशीन्सना एकमेकांशी संपर्क साधण्याची गरज आहे, हे विचारा. जर उत्तर असे असेल की त्या सर्वांना फक्त सर्व्हरशीच बोलायचे आहे, तर साधे WireGuard वापरणे अधिक सोपे आहे, कारण त्यात कमी सॉफ्टवेअर लागते आणि निकाल तोच मिळतो.

मशीन्सना स्थिर सार्वजनिक (public) पत्ते आहेत का, हे तपासा. जर त्यापैकी बहुतेक मशीन्स तुमच्या नियंत्रणाबाहेरील NAT च्या मागे असतील, तर तुम्हाला एका कंट्रोल प्लेनची गरज आहे. कारण 'होल पंचिंग' (hole punching) ही कठीण प्रक्रिया आहे आणि ती पुन्हा तयार करण्यात वेळ घालवणे फायदेशीर नाही.

तुमच्या नेटवर्कची रचना कोणाला माहित असावी, हे ठरवा. जर तुम्हाला बाहेरील कंपन्यांना यापासून दूर ठेवायचे असेल, किंवा वापरकर्त्यांच्या संख्येमुळे प्रति-सीट (per seat) बिलिंग महाग पडत असेल, तर Headscale वापरा आणि आता तुम्ही स्वतः कंट्रोल सर्व्हर चालवत आहात हे स्वीकारा. जर बिलिंगमुळे तुम्ही हा निर्णय घेत असाल, तर स्थलांतर (migration) करण्यापूर्वी गणित करून पहा. कारण तुमच्या आकाराच्या टीमला प्रत्यक्ष किती खर्च येतो हे तुम्ही किती मशीन्स चालवता यापेक्षा किती लोकांकडे अकाउंट्स आहेत, यावर अवलंबून असते. जोपर्यंत तुमचे टॅग केलेले सर्व्हर्स प्रत्येक प्लॅनमध्ये समाविष्ट असलेल्या 50 च्या मर्यादेपेक्षा जास्त होत नाहीत, तोपर्यंत हे दोन आकडे सहसा जवळ नसतात.

तुम्ही तुमचा निर्णय कमी खर्चात बदलू शकता. तिन्ही पर्यायांमध्ये डेटा प्लेनसाठी समान प्रोटोकॉल वापरला जात असल्याने, साध्या WireGuard कडून कोऑर्डिनेटेड मेशकडे जाणे म्हणजे केवळ क्लायंट इन्स्टॉल करणे आहे, पूर्ण रचना बदलणे नाही. तसेच, Tailscale कडून Headscale कडे जाणे म्हणजे प्रत्येक नोडची वेगळ्या लॉगिन सर्व्हरवर पुन्हा नोंदणी करणे इतकेच सोपे आहे.

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

यापैकी एकही 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 असो वा नसो, ते त्याच प्रकारे परिणाम करते.