हब-स्पोक र पूर्ण मेसबीच: तपाईंका साइटका लागि कुन 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 हरेक साइटबाट हरेक सेवा प्रिफिक्सतर्फ चलाउनुहोस् र हपहरू रेखाचित्रसँग मिल्छन् कि भनी पुष्टि गर्नुहोस्। असफलताको मार्गका लागि एउटा सुरुङ बन्द गरेर दोहोर्याउनुहोस्, किनकि सबै चालु हुँदा मात्र चल्ने मार्ग डिजाइन गरिएको होइन, कन्फिगर मात्र गरिएको हो।
दुवै रेखाचित्र पहुँच म्याट्रिक्ससँगै राख्नुहोस्, र साइट थपिँदा फेरि हेर्नुहोस्; तपाईंले साँच्नुभएको लागत अर्को परिवर्तनको लागत हो, अहिलेको चित्रको सुन्दरता होइन।