हब आणि स्पोक विरुद्ध पूर्ण मेश: तुमच्या साइटसाठी कोणती VPN टोपोलॉजी योग्य
दोन चालणारे बोगदे ही टोपोलॉजी नसते. हब, मेश किंवा काही थेट दुवे असलेला हब निवडण्यापूर्वी ट्रान्झिट, अपयशाचे वर्तन आणि बदलाचा खर्च यांची तुलना करा.
दोन शाखा कार्यालये दिवसभर एकमेकांशी बोलतात, आणि त्यांच्यातील बोगदा दुसर्या प्रदेशातील डेटा सेंटरमधून वळसा घालतो. प्रत्येक विनंती त्या वळसाची किंमत दोनदा मोजते, आणि फाइल सिंक चुकीचा वाटू लागेपर्यंत कोणालाही ते जाणवत नाही. टोपोलॉजीचा प्रश्न खरा तिथून सुरू होतो: कोणता आराखडा अधिक टिकाऊ दिसतो हा नाही, तर तुम्ही कोणत्या रहदारीच्या पद्धतीसाठी पैसे देत आहात हा आहे. दोन्ही रचना चालतात, आणि त्या वेगवेगळ्या प्रकारे, वेगवेगळ्या किमतीत अपयशी ठरतात.
सर्वात आधी पीअर संबंध मोजा
एन साइट असतील तर पूर्ण मेशला एन गुणिले एन वजा एक, दोनने भागले, बोगदे लागतात; हबला एन पुरतात. पाच साइटवर ते दहा विरुद्ध पाच, हे अजून सांभाळण्यासारखे वाटते. पंधरावर ते 105 विरुद्ध पंधरा, आणि फरक आता अंकगणित नाही, मनुष्यबळ आहे.
त्या प्रत्येक संबंधात तुम्हाला सांभाळावी लागणारी स्थिती असते. IPsec मध्ये याचा अर्थ सुरक्षा संघटना, ओळख, की किंवा प्रमाणपत्र, डेड-पीअर शोध आणि प्रत्येक दूरच्या प्रीफिक्ससाठी किमान एक मार्ग. WireGuard मध्ये याचा अर्थ प्रत्येक पीअरसाठी एक सार्वजनिक की आणि एक AllowedIPs ब्लॉक, जे प्रत्येक पीअरसाठी स्वस्त पडते पण शोध अजिबात न देता येते: नवीन साइट हा कोणत्याही प्रकारे प्रत्येक जुन्या साइटवरच बदल असतो.
निर्णय आराखड्याने नाही, रहदारीच्या मिश्रणाने घ्यावा
शाखांची रहदारी मुख्यतः केंद्रीय ERP किंवा फाइल क्लस्टरकडील विनंत्या असतील, तर हब हा तडजोड नाही, तोच योग्य आकार आहे: रहदारीला आधीच तिकडे जायचे होते, आणि एकच धोरण बिंदू जोडीने लिहिलेल्या नियमांच्या मेशपेक्षा तपासायला सोपा असतो. शाखा एकमेकांशी डेटा देवाणघेवाण करतात तेव्हा — दोन कार्यालयांमधील प्रतिकृती, साइटमधील आवाज, डझनभर अभियंते दिवसभर उघडत असलेला CAD शेअर — मेश आपली गुंतागुंत कमावतो.
अवघड प्रकरणे मधेच असतात, आणि तीच बहुसंख्य असतात. संघटनातक्त्यावरून अंदाज करण्यापेक्षा भांडण्यापूर्वी मोजा.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
तक्ता नियम म्हणून नाही, बरोबरी सोडवणारा म्हणून वाचा. चारपैकी तीन ओळी एकाच बाजूला दाखवतात तेव्हा सहसा रचना ठरते; विभागणी म्हणजे संकरित, आणि परिपक्व जाळी बहुतेक शेवटी तेच चालवतात.
हबला फॉरवर्ड करायला सांगावे लागते
दोन चालणारे स्पोक-ते-हब बोगदे स्पोक-ते-स्पोक प्रवेश निर्माण करत नाहीत. हबवर IP फॉरवर्डिंग सुरू असणे, प्रत्येक स्पोक जाळीकडे मार्ग, तीही रहदारीला परवानगी देणारा फायरवॉल नियम आणि परतीचा मार्ग ठरवलेला असणे आवश्यक; प्रत्येक स्पोकला दुसर्या साइटच्या प्रीफिक्ससाठी मार्ग लागतो. Linux हबवर ते net.ipv4.ip_forward=1 आणि एक FORWARD साखळी आहे, जी ती जोडी गुपचूप टाकून देत नाही; आणि धोरणाधारित IPsec मध्ये दोन्ही टोकांना दूरचे स्पोक उपजाळे सूचीबद्ध करणारे ट्राफिक निवडक असतात. strongSwan चे फॉरवर्डिंग नोंदी तुम्ही चुकवत असलेला थर तोच असेल तेव्हा कर्नेल आणि फायरवॉल बाजू सांगतात. स्वस्त चाचणी म्हणजे एका स्पोककडून दुसर्यावरील सेवेकडे रहदारी पाठवत हबचे काउंटर पाहणे; कधीही न वाढणारा नियम म्हणजे मार्ग नाही, क्रम चुकीचा आहे.
केंद्रीय धोरण हाच उपयुक्त भाग. शाखांना एकमेकांकडे न जाता सामायिक सेवांकडे जाण्याची परवानगी देता येते, आणि तो प्रवेश तक्ता स्पष्ट लिहून ठेवणे उपयुक्त ठरते. गायब मार्ग हे कोणी वाचू शकेल अशा नियमाचा वाईट पर्याय आहेत.
अर्धवट केलेली आवृत्ती पाहा: स्पोक A हबमार्गे स्पोक B कडे जातो, हब दोन्ही बाजूंना मार्ग देतो, आणि हबचा फायरवॉल A कडून नवीन जोडण्यांना परवानगी देतो पण B कडून नाही. पहिली दिशा छान चाचणीत जाते आणि दुसरी लटकते, जे मार्गदोष वाटते, पण नाही.
आधी अपयशाची रचना करा, मग सामान्य मार्गाची
एकच हब हा सामायिक अवलंब आणि रहदारीची अडचण असतो, आणि हब रचना सहसा इथेच चुकतात. दोन हब म्हणजे प्रत्येक स्पोककडे दोन बोगदे असतात, आणि परतीचा मार्ग जाणार्या मार्गाशी जुळला पाहिजे; जुळला नाही तर स्थितीपूर्ण फायरवॉल उत्तरे टाकून देतो आणि लक्षण म्हणजे उघडून मग मरणारे जोडणी. मोठ्या तैनाती हे स्थिर प्रीफिक्सऐवजी बोगद्यांवरील मार्गक्रमण प्रोटोकॉलने सोडवतात, जे जास्त यंत्रसामग्री आहे पण अंदाज काढून टाकते. तुम्ही काय निवडले तरी परतीचा मार्ग जाणार्या मार्गाच्या शेजारी लिहा, कारण परतीचा अर्धा भाग कोणीही चाचणीत घेत नाही.
मेश तो धोका पसरवतो: एका साइटचा दुवा कोसळला तरी इतर वेगळे होत नाहीत. तो मार्गनिवड तुम्हाला चकित करू शकणार्या जागा वाढवतो, आणि अनुप्रयोग सत्रे मदतीशिवाय मार्गबदल टिकवू शकत नाहीत.
कोणतीही रचना फेलओव्हरमध्ये TCP सत्र स्वतः जिवंत ठेवत नाही. अनुप्रयोग पुन्हा जोडू शकत नसेल, तर टोपोलॉजी तुमची अडचण नाही.
बदलाच्या खर्चावरून निवडा, मग मार्ग तपासा
हबपासून सुरुवात करा, कारण चूक होणे तिथे स्वस्त आहे, आणि रहदारी ज्यांना न्याय्य ठरवते त्या जोड्यांसाठी थेट बोगदे जोडा. तो संकरित रचना निर्णय न घेणे नाही; बहुतेक संस्था वर्षभरात ज्यावर येतात तीच रचना आहे. महत्त्वाचे म्हणजे प्रत्येक थेट दुव्याला सांगितलेले कारण आणि एक मालक असावा.
एक नाही, दोन्ही आराखडे तपासा. सामान्य मार्गासाठी traceroute प्रत्येक साइटवरून प्रत्येक सेवा प्रीफिक्सकडे चालवा आणि हॉप आराखड्याशी जुळतात का ते पाहा. अपयशाच्या मार्गासाठी एक बोगदा बंद करून पुन्हा करा, कारण सर्व काही सुरू असतानाच चालणारा मार्ग रचला गेलेला नाही, फक्त संरचित केला गेला आहे.
दोन्ही आराखडे प्रवेश तक्त्यासोबत ठेवा, आणि साइट जोडली की ते पुन्हा पाहा; तुम्ही सांभाळत असलेला खर्च पुढील बदलाचा खर्च आहे, सध्याच्या चित्राची सुबत्ता नाही.