हब और स्पोक या पूरा मेश: आपकी साइटों के लिए कौन-सी VPN टोपोलॉजी सही है

दो शाखा दफ़्तर पूरे दिन एक-दूसरे से बात करते हैं, और उनके बीच की टनल किसी दूसरे क्षेत्र के डेटा सेंटर से होकर घूमती है। हर अनुरोध उस घुमाव की कीमत दो बार चुकाता है, और किसी को तब तक पता नहीं चलता जब तक फ़ाइल सिंक अजीब लगने न लगे। टोपोलॉजी का सवाल ठीक यहीं से शुरू होता है: यह नहीं कि कौन-सा आरेख ज़्यादा टिकाऊ दिखता है, बल्कि यह कि आप किस ट्रैफ़िक पैटर्न के लिए भुगतान कर रहे हैं। दोनों डिज़ाइन काम करते हैं, और वे अलग-अलग तरीक़ों से, अलग-अलग लागत पर विफल होते हैं।

बाक़ी कुछ भी करने से पहले पीयर संबंधों को गिनें

N साइटों के साथ पूरे मेश को N गुणा N घटा एक, भाग दो, टनल चाहिए; हब को N चाहिए। पाँच साइटों पर यह पाँच के मुक़ाबले दस है, जो अब भी संभालने योग्य लगता है। पंद्रह पर यह पंद्रह के मुक़ाबले 105 है, और अंतर अब गणित का नहीं, कर्मचारियों का है।

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

फ़ैसला ट्रैफ़िक का मिश्रण करे, चित्र नहीं

अगर शाखाओं का ट्रैफ़िक मुख्यतः किसी केंद्रीय ERP या फ़ाइल क्लस्टर के अनुरोध हैं, तो हब समझौता नहीं, सही आकार है: ट्रैफ़िक पहले ही वहाँ जाना चाहता था, और एक नीति-बिंदु जोड़ी-आधारित नियमों के मेश से ज़्यादा आसानी से ऑडिट होता है। मेश अपनी जटिलता तब कमाता है जब शाखाएँ आपस में डेटा का आदान-प्रदान करती हैं — दो दफ़्तरों के बीच प्रतिकृति, साइटों के बीच आवाज़, एक CAD शेयर जिसे दर्जनों इंजीनियर पूरे दिन खोलते हैं।

मुश्किल मामले बीच में होते हैं, और वही बहुमत हैं। संगठन चार्ट से अनुमान लगाने के बजाय बहस से पहले मापें।

तालिका को नियम नहीं, निर्णायक मानें। चार में से तीन पंक्तियाँ एक दिशा में हों तो डिज़ाइन आम तौर पर तय हो जाता है; विभाजन का अर्थ हाइब्रिड है, जिस पर ज़्यादातर परिपक्व नेटवर्क अंततः पहुँचते ही हैं।

हब को अग्रेषित करने का कहना पड़ता है

दो चलती हुई स्पोक-से-हब टनल स्पोक-से-स्पोक पहुँच नहीं बनातीं। हब को IP अग्रेषण चालू, हर स्पोक नेटवर्क तक एक रूट, ट्रांज़िट की अनुमति देने वाला फ़ायरवॉल नियम और वापसी मार्ग की गणना चाहिए; हर स्पोक को दूसरी साइट के प्रीफ़िक्स के लिए रूट चाहिए। Linux हब पर यह net.ipv4.ip_forward=1 के साथ FORWARD एक श्रृंखला है जो जोड़ी को चुपचाप नहीं गिराती, और नीति-आधारित IPsec में ये ट्रैफ़िक चयनक होते हैं जो दोनों सिरों पर दूरस्थ स्पोक सबनेट सूचीबद्ध करते हैं। strongSwan में अग्रेषण संबंधी टिप्पणियाँ कर्नेल और फ़ायरवॉल पक्ष को कवर करती हैं, जब वही आपकी छूटी हुई परत हो। एक सस्ता परीक्षण यह है कि एक स्पोक से दूसरी ओर की सेवा तक ट्रैफ़िक भेजें और हब के काउंटर देखें; जो नियम कभी नहीं बढ़ता उसका अर्थ है क्रम ग़लत है, रूट नहीं।

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

आधे-अधूरे संस्करण से सावधान रहें: स्पोक A हब से होकर स्पोक B की ओर रूट करता है, हब दोनों दिशाओं में रूट करता है, और हब का फ़ायरवॉल A से नए कनेक्शन की अनुमति देता है पर B से नहीं। पहली दिशा अच्छी तरह परखी जाती है और दूसरी अटक जाती है, जो रूटिंग ख़राबी जैसा लगता है और है नहीं।

पहले विफलता की डिज़ाइन करें, फिर सामान्य मार्ग की

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

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

दोनों में से कोई डिज़ाइन अपने आप फ़ेलओवर के दौरान TCP सत्र जीवित नहीं रखता। अगर अनुप्रयोग फिर से जुड़ नहीं सकता, तो टोपोलॉजी आपकी समस्या नहीं है।

बदलाव की लागत से चुनें, फिर मार्गों को सत्यापित करें

हब से शुरू करें, क्योंकि ग़लत होने के लिए वह सस्ती चीज़ है, और जिन जोड़ियों का ट्रैफ़िक इसे न्यायोचित ठहराता है उनके लिए सीधी टनल जोड़ें। वह हाइब्रिड निर्णय न ले पाने की विफलता नहीं है; यह वह डिज़ाइन है जिस पर ज़्यादातर संगठन एक साल के भीतर पहुँच जाते हैं। महत्वपूर्ण यह है कि हर सीधे लिंक का घोषित कारण और स्वामी हो।

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

दोनों चित्रों को पहुँच मैट्रिक्स के साथ रखें, और साइट जुड़ने पर उन्हें फिर देखें; जिस लागत का आप प्रबंधन कर रहे हैं वह अगले बदलाव की लागत है, मौजूदा तस्वीर की सुंदरता नहीं।