अलग साइटों को जोड़ना: VPN, Tailscale, NetBird या Cloudflare Mesh?

मैं कंपनियों के नेटवर्क जोड़ने का काम काफी करता हूँ। अक्सर वही प्रश्न आते हैं: हमारी साइटों को जोड़ने का सबसे अच्छा तरीका क्या है? क्या सार्वजनिक IP पते चाहिए? यह कितना सुरक्षित है? नई शाखा जुड़ने, इंटरनेट कनेक्शन बदलने या कर्मचारियों की संख्या बढ़ने पर भी क्या यह समाधान उपयुक्त रहेगा?

मेरा उत्तर कंपनी की वास्तविक जरूरतों पर निर्भर करता है। पहले से फ़ायरवॉल वाली दो स्थायी साइटों की स्थिति, बदलते कनेक्शन वाली कई छोटी शाखाओं से अलग होती है। टनल के अलावा यह भी समझना होता है कि संचालन कौन करेगा, एक्सेस कहाँ नियंत्रित होगा और कंपनी किन निर्भरताओं को बनाए रखने के लिए तैयार है।

इसलिए उत्पाद चुनने से पहले मैं आर्किटेक्चर समझना चाहता हूँ। पारंपरिक site-to-site VPN उपयुक्त हो सकता है। Tailscale या NetBird प्रबंधन और कनेक्शन बनाना आसान कर सकते हैं। Cloudflare Mesh डेटा का रास्ता प्रदाता के नेटवर्क में ले जाता है। इन्हीं अंतरों से मैं तय करता हूँ कि कौन-सा तरीका कहाँ उपयोगी है।

यहाँ विषय पूरी साइट के नेटवर्क जोड़ना है। घर से किसी कर्मचारी के व्यक्तिगत डिवाइस का एक्सेस, अतिरिक्त रिमोट एक्सेस उपयोग के रूप में अलग समझाया गया है।

हमारा उदाहरण: तीन जुड़े हुए साइट नेटवर्क

मुख्यालय 10.1.0.0/24, शाखा 10.2.0.0/24 और होम लैब 10.3.0.0/24 इस्तेमाल करते हैं। हर साइट का गेटवे दूर के नेटवर्क तक पहुँच देता है। उसके पीछे के प्रिंटर या NAS को अपना VPN क्लाइंट नहीं चाहिए। हर मॉडल का लक्ष्य समान है: इन तीन नेटवर्क के बीच नियंत्रित कनेक्टिविटी।

इससे लेयर 3 पर रूट किया गया नेटवर्क बनता है। साइटें अपने-आप एक ब्रॉडकास्ट डोमेन साझा नहीं करतीं और सभी स्थानीय खोज प्रोटोकॉल साइटों के बीच नहीं चलने लगते। DNS को आंतरिक नाम सही हल करने होंगे और स्थानीय राउटरों को दूर के नेटवर्क के रूट चाहिए।

मैं पहले जानना चाहता हूँ कि किस नेटवर्क को कौन-सी सेवाएँ चाहिए। शाखा को फ़ाइल सर्वर चाहिए हो सकता है, लेकिन लैब का प्रशासन नहीं। बैकअप सर्वर को अपना गंतव्य चाहिए, दूसरी साइट के हर उपकरण का एक्सेस नहीं। हर समाधान में ये निर्णय आवश्यक हैं।

Site-to-site कनेक्शन बताता है, टोपोलॉजी नहीं

Site-to-site का अर्थ नेटवर्क से नेटवर्क है। इसका मतलब यह नहीं कि सारा ट्रैफ़िक केंद्रीय फ़ायरवॉल से ही जाए। मुख्यालय को केंद्र बनाने वाला hub-and-spoke सामान्य है, लेकिन साइटों की जोड़ी के बीच सीधी टनल भी site-to-site है। Tailscale, NetBird और Cloudflare Mesh के साइट गेटवे भी यही काम कर सकते हैं।

Tailscale और NetBird पंजीकरण व समन्वय केंद्रीय होने पर भी डेटा को यथासंभव सीधे भेजते हैं। Cloudflare का नेटवर्क भौगोलिक रूप से फैला है, लेकिन साइटों का ट्रैफ़िक Cloudflare से होकर ही गुजरता है। यह साइटों के बीच सीधा peer-to-peer कनेक्शन नहीं है। अपने केंद्रीय फ़ायरवॉल की जगह प्रदाता का नेटवर्क ट्रांज़िट बिंदु बन जाता है।

सार्वजनिक IP और बदलती आवश्यकताएँ

सार्वजनिक IP का प्रश्न जल्दी सामने आता है। मैं बाहर से पहुँच संभव होने और पता स्थिर रहने में अंतर करता हूँ। स्थिर सार्वजनिक पता किसी पहुँच योग्य VPN endpoint की योजना आसान बनाता है, लेकिन हर साइट पर जरूरी नहीं। शाखा किसी पहुँच योग्य केंद्रीय गेटवे की ओर आउटबाउंड टनल बना सकती है। डिजाइन के अनुसार dynamic DNS बदलते पते में भी मदद करता है।

मुश्किल तब होती है जब दोनों सिरे प्रतिबंधित carrier-grade NAT के पीछे हों और कोई endpoint सीधे उपलब्ध न हो। विशेषकर मोबाइल इंटरनेट में जाँचना चाहिए कि ऑपरेटर कौन-से पते और इनबाउंड कनेक्शन वास्तव में देता है। Tailscale और NetBird NAT पार कर सीधा संपर्क आजमाते हैं और जरूरत पर relay इस्तेमाल करते हैं। Cloudflare Mesh प्रदाता नेटवर्क की ओर आउटबाउंड कनेक्शन बनाता है।

मैं चाहता हूँ कि अगला बदलाव भी संभालने योग्य हो। नई साइट, प्रदाता बदलना या इनबाउंड पहुँच रहित कनेक्शन एक छोटे सेटअप को अलग समस्या में बदल सकता है। इसका अर्थ चालू समाधान को पहले ही बदल देना नहीं, लेकिन टोपोलॉजी तय करने से पहले इन संभावनाओं पर विचार जरूरी है।

पारंपरिक site-to-site VPN: गेटवे संभालते हैं

दो फ़ायरवॉल या राउटर एन्क्रिप्टेड टनल बनाते हैं, अक्सर IPsec या हाथ से कॉन्फ़िगर किए WireGuard से। स्थानीय रूटिंग दूर के नेटवर्क का ट्रैफ़िक टनल में भेजती है। दूसरा गेटवे पैकेट डिक्रिप्ट करके गंतव्य नेटवर्क में आगे भेजता है।

तीन साइटों में मुख्यालय hub हो सकता है। शाखा और लैब उससे जुड़ते हैं। संरचना आसान है, लेकिन उनके बीच डेटा मुख्यालय से जाता है। Full mesh हर जोड़ी को सीधे जोड़ता है। n साइटों के लिए n × (n − 1) / 2 कनेक्शन चाहिए: तीन साइटों के लिए तीन, दस के लिए 45। Controller और गतिशील तरीके काम घटा सकते हैं; पारंपरिक VPN केवल हाथ से बनाए hub नेटवर्क तक सीमित नहीं हैं।

लाभ: मौजूदा फ़ायरवॉल और स्पष्ट साइट सीमाओं में फिट बैठता है। टनल के सिरे अपने नियंत्रण में रहते हैं। डेटा मार्ग में अतिरिक्त mesh प्रदाता नहीं होता; नियम, रूटिंग और लॉग मौजूदा प्रशासन में शामिल हो सकते हैं।

कमियाँ: साइट बढ़ने पर रूटिंग, चाबियों और संचालन का काम बढ़ता है। NAT, बदलते पते और अलग निर्माताओं से समस्या ढूँढ़ना कठिन होता है। मोबाइल उपयोगकर्ताओं के लिए अक्सर अलग रिमोट एक्सेस सेटअप चाहिए।

हर साइट पर स्थिर सार्वजनिक IP सार्वभौमिक शर्त नहीं है। कई मामलों में पहुँच योग्य hub और शाखाओं की आउटबाउंड टनल पर्याप्त हैं। Dynamic DNS और NAT traversal भी मदद कर सकते हैं। लेकिन दोनों सिरों पर सख्त CGNAT हो तो पहुँच योग्य endpoint या मध्यस्थ के बिना सीधा कनेक्शन कठिन होता है।

उचित फ़ायरवॉल वाली दो स्थिर साइटों के लिए यह अब भी समझदार विकल्प है। केवल दूसरे उत्पाद में कम कॉन्फ़िगरेशन खाने होने से काम करता VPN बदलना जरूरी नहीं।

Tailscale: सीधे कनेक्शन और केंद्रीय समन्वय

Tailscale, WireGuard में डिवाइस पंजीकरण, समन्वय और एक्सेस नीतियाँ जोड़ता है। नियंत्रण सेवा प्रतिभागियों को एक-दूसरे को खोजने में मदद करती है। जहाँ संभव हो, डेटा सीधे peers के बीच जाता है। NAT या फ़ायरवॉल रोकें तो relay दूसरा रास्ता देता है। DERP से होकर भी Tailscale peers के बीच डेटा एन्क्रिप्टेड रहता है।

Subnet router पूरी LAN को tailnet से जोड़ते हैं। Tailscale के दस्तावेज़ वाला site-to-site उदाहरण दोनों सिरों पर Linux इस्तेमाल करता है। पीछे के उपकरणों को agent नहीं चाहिए, लेकिन सही रूट जरूरी हैं। मूल स्रोत पते बचाने के लिए source NAT बंद करने पर वापसी का रास्ता खास तौर पर सोचकर बनाना पड़ता है।

लाभ: मौजूदा LAN उपकरण subnet router के जरिए जुड़ सकते हैं। गेटवे की सीधी लिंक केंद्रीय साइट से होकर जाने की बाध्यता हटाती हैं। उसी प्लेटफ़ॉर्म में व्यक्तिगत डिवाइस भी जोड़े जा सकते हैं।

कमियाँ: सीधा रास्ता सुनिश्चित नहीं। Relay से latency और throughput बदल सकते हैं। होस्ट की गई समन्वय सेवा संचालन की निर्भरता रहती है; योजना और सुविधाएँ तैनाती के अनुरूप चाहिए।

WireGuard एन्क्रिप्शन peer पर समाप्त होता है। अगर वह subnet router है, तो उसके बाद का LAN हिस्सा टनल के बाहर है। इसलिए निजी नेटवर्क में HTTPS और SSH उपयोगी रहते हैं।

NetBird: मिलता-जुलता mesh, स्वयं होस्ट करने का विकल्प

NetBird भी WireGuard पर आधारित है, सीधे कनेक्शन आजमाता है और जरूरत पर relay लेता है। Routing peer उन नेटवर्क को जोड़ते हैं जिनके उपकरण क्लाइंट नहीं चलाते। वर्तमान site-to-site गाइड Networks, Resources और संबंधित एक्सेस नीतियाँ बताती है।

लाभ: ओपन-सोर्स प्रोजेक्ट cloud सेवा के बजाय स्वयं होस्ट करने का विकल्प देता है। जब बुनियादी ढाँचा और प्रबंधन अपनी जिम्मेदारी में चाहिए तो यह महत्वपूर्ण है। समूह और नीतियाँ एक्सेस सीमित करने में मदद करती हैं।

कमियाँ: स्वयं होस्टिंग में अपडेट, बैकअप, निगरानी तथा समन्वय और relay की उपलब्धता अपनी जिम्मेदारी होती है। तेज इंस्टॉलेशन यह काम नहीं हटाता। दस्तावेज़ वाला Networks site-to-site डिजाइन masquerading चालू रखता है, इसलिए गंतव्य सीधे मूल स्रोत पता नहीं देखता। अन्य routing विकल्प अलग योजना माँगते हैं।

Tailscale और NetBird करीबी हैं, पर कॉन्फ़िगरेशन अदलने योग्य नहीं। मैं जरूरी रूटिंग और पहचान मॉडल के आधार पर दोनों को देखूँगा। ओपन सोर्स का मतलब हर सुविधा पर असीमित अधिकार भी नहीं; अपेक्षित तैनाती की लाइसेंस और सुविधाएँ जाँचनी चाहिए।

Cloudflare Mesh: प्रदाता नेटवर्क ही रास्ता बनता है

प्रतिभागी Cloudflare की ओर आउटबाउंड कनेक्शन बनाते हैं। साइटों के बीच ट्रैफ़िक उसके नेटवर्क से गुजरता है। हर साइट को बाकी सब से सीधे जोड़ना या अपना केंद्रीय VPN hub चलाना जरूरी नहीं। फिर भी भरोसे की सीमा और डेटा मार्ग सीधे WireGuard mesh से अलग हैं।

लाभ: कनेक्टिविटी और केंद्रीय Gateway नीतियाँ एक साथ मिलती हैं। जहाँ पहले से Cloudflare One है, वहाँ खास तौर पर विचार योग्य है। NAT के पीछे साइटें और मोबाइल क्लाइंट आउटबाउंड कनेक्शन से जुड़ते हैं।

कमियाँ: संचालन और रास्ता प्रदाता पर निर्भर हैं। संवेदनशील डेटा का प्रोसेसिंग भरोसे व गोपनीयता की जरूरतों के अनुरूप होना चाहिए। एप्लिकेशन के लिए TLS या SSH उपयोगी हैं। विशेष ऐप को रास्ते से लाभ है या नहीं, मापना होगा; वैश्विक backbone हर जगह बेहतर प्रदर्शन का प्रमाण नहीं।

नई तैनाती के लिए मैं वर्तमान दस्तावेज़ वाला क्लाइंट तरीका अपनाऊँगा। Cloudflare Mesh को beta बताता है और नोड की device profile में MASQUE जरूरी करता है। WireGuard के लिए high availability, IPv6 और hostname routes में सीमाएँ दर्ज हैं। केवल राउटर का WireGuard समर्थित होना उसे बराबर का Mesh node नहीं बनाता।

Mesh को किसी एक एप्लिकेशन के cloudflared टनल से भी अलग समझना चाहिए। यहाँ प्रतिभागियों और रूट किए नेटवर्क के बीच दोतरफ़ा निजी IP कनेक्टिविटी की बात है।

अंतर एक नज़र में

चुनते समय पहले मैं इन अंतरों को देखता हूँ। जरूरी subscription और वास्तविक रास्ता संबंधित वातावरण में जाँचना बाकी रहता है।

सुरक्षित साइट कनेक्टिविटी से मेरी अपेक्षा

सबसे सुरक्षित विकल्प पूछने पर मैं पहले अनुमत कनेक्शन और एक्सेस प्रबंधन देखता हूँ। एन्क्रिप्टेड टनल भी जरूरत से ज्यादा अनुमति दे सकती है। कौन-सा नेटवर्क कौन-सी सेवा तक जाए, प्रशासक कैसे सुरक्षित हों और एक्सेस कैसे वापस लिया जाए, यह तय होना चाहिए। प्रशासन और व्यक्तिगत पंजीकृत उपयोगकर्ताओं के लिए MFA, सीमित अधिकार और रखरखाव वाले गेटवे इस आकलन का भाग हैं।

एन्क्रिप्शन सीमाएँ भी भिन्न हैं। पारंपरिक VPN साइट गेटवे पर खत्म होती है। Tailscale और NetBird peers के बीच WireGuard चलाते हैं, जो subnet router भी हो सकते हैं। आगे की LAN अपने-आप एन्क्रिप्टेड नहीं। Cloudflare में प्रदाता नेटवर्क के अंदर प्रोसेसिंग भी कंपनी की जरूरतों से मेल खानी चाहिए। एप्लिकेशन में HTTPS या SSH उपयोगी रहते हैं।

आउटबाउंड कनेक्शन सेटअप आसान कर सकता है और शाखा में सार्वजनिक VPN सेवा खोलने से बचा सकता है। यह एक्सेस नीति का विकल्प नहीं। सार्वजनिक IP अपने-आप फ़ायरवॉल असुरक्षित भी नहीं बनाता। जोखिम वास्तव में खुले सेवाओं, उनकी सुरक्षा और संचालन से तय होता है। केवल उत्पाद नाम से मैं सुरक्षा क्रम नहीं बनाता।

स्वीकृति से पहले क्या जाँचना चाहता हूँ

आने-जाने दोनों रास्ते सही चाहिए। 10.2.0.0/24 का रूट जिम्मेदार राउटर या क्लाइंट पर हो। यदि गंतव्य किसी अन्य default gateway से जवाब दे, तो उचित वापसी रूट चाहिए। SNAT जवाब आसान करता है लेकिन दिखाई देने वाला पता बदलता है, जिससे लॉग और नियम प्रभावित होते हैं। यह सोचा हुआ डिजाइन निर्णय होना चाहिए।

High availability के लिए दो overlay node पर्याप्त नहीं। खराबी के बाद भी LAN उपकरण अपना अगला गेटवे पा सकें। उदाहरण के लिए Keepalived और VRRP आभासी गेटवे पता देते हैं। दूर के रूट भी स्वस्थ नोड चुनें। मैं देखना चाहता हूँ कि गेटवे या टनल टूटने पर नए और मौजूदा TCP सत्रों का क्या होता है। चलती प्रक्रिया और सफल ping केवल आंशिक उत्तर हैं।

कार्य-परीक्षण में जानबूझकर रोके कनेक्शन भी शामिल हों। SSH अनुमति और दूसरा ऐप निषिद्ध होना हो तो वही व्यवहार जाँचना चाहिए। ICMP सफलता TCP नियम लागू होने का प्रमाण नहीं। पंजीकरण, नीतियाँ और गंतव्य फ़ायरवॉल संगत हों।

फिर वे कम दिखने वाले विवरण हैं जो रोजमर्रा की उपयोगिता तय करते हैं: अलग prefix, आंतरिक नामों का हल और उचित MTU। न 192.168.x.x, न 10.x.x.x संघर्ष-मुक्त नेटवर्क की गारंटी है। छोटे ping चलें लेकिन बड़े ट्रांसफ़र अटकें तो मैं कनेक्शन पूरा नहीं मानता।

प्रदर्शन तुलना में असली लाइनों पर वही फ़ाइल ट्रांसफ़र और interactive ऐप चाहिए। सीधा या relay मार्ग, CPU लोड और इंटरनेट बदलने के बाद व्यवहार दर्ज हों। मेरा आकलन आर्किटेक्चर और संचालन के अंतरों का है; यह उत्पादों की मापी हुई गति रैंकिंग नहीं देता।

रिमोट एक्सेस: व्यक्तिगत उपकरण जोड़ना

घर से कर्मचारी का लैपटॉप कंपनी नेटवर्क से जुड़े तो यह remote access या client-to-site है। क्लाइंट लैपटॉप पर चलता है और पूरा घरेलू नेटवर्क अपने-आप मुख्यालय से नहीं जुड़ता। केंद्रीय फ़ायरवॉल की सेवा या इन प्लेटफ़ॉर्म के क्लाइंट इस्तेमाल किए जा सकते हैं। व्यक्तिगत पंजीकरण से अधिकार उपयोगकर्ता और समूह से भी जोड़े जा सकते हैं।

घर का ऑफिस site-to-site स्थान भी हो सकता है: वहाँ का गेटवे अनुमोदित नेटवर्क या VLAN मुख्यालय से जोड़ता है। फर्क काम की जगह नहीं, व्यक्तिगत डिवाइस या नेटवर्क जोड़ने का है। व्यक्तिगत उपकरण के लिए रिमोट एक्सेस का दायरा अक्सर सही है। बिना इरादे पूरा निजी घरेलू नेटवर्क उपलब्ध बनाने का कारण नहीं।

मेरे लिए कौन-सा तरीका कहाँ उचित है

कुछ स्थिर साइट और मौजूदा फ़ायरवॉल हों तो मैं पारंपरिक VPN से शुरू कर hub-and-spoke या सीधी टनल चुनूँगा। NAT के पीछे साइट, केंद्रीय प्रबंधन और यथासंभव सीधे डेटा मार्ग चाहिए हों तो Tailscale और NetBird की तुलना करूँगा। समन्वय स्वयं चलाना जरूरी हो तो NetBird जल्दी मूल्यांकन में आएगा। Cloudflare One की नीतियाँ पहले से हों तो Mesh, उसकी beta स्थिति और प्रदाता नेटवर्क में प्रोसेसिंग देखूँगा। अतिरिक्त रिमोट एक्सेस अलग चयन मानदंड है।

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

जब सर्वश्रेष्ठ समाधान पूछा जाए तो मैं कंपनी और उसके अगले बदलाव से मेल खाता सुझाव देना चाहता हूँ। मौजूदा फ़ायरवॉल वाली छोटी तैनाती में पारंपरिक VPN सही रह सकता है। दूसरी कनेक्शन स्थितियाँ या प्रबंधन जरूरतें mesh पर विचार उचित बनाती हैं। निर्णय इस पर होगा कि जरूरी कनेक्शन सुरक्षित चलाए, समझे और खराबी के बाद बहाल किए जा सकते हैं या नहीं।

अगली बार तक,
Joe