एक ग्राहक धेरैमध्ये एक OpenVPN सर्भरमा जोडिन्छ र त्यसपछि त्यस नोडमा चल्ने सानो सेवा चाहिन्छ: स्थिति पृष्ठ, मेट्रिक्स अन्त्य बिन्दु, ब्याकअप एजेन्ट। हरेक नोडलाई एउटै निजी सेवा ठेगाना दिँदा ग्राहकको कन्फिगरेसन कुन सर्भरमा पुग्यो भन्ने कुराबाट स्वतन्त्र भई उस्तै रहन्छ। त्यो सुविधा वास्तविक छ, र यसलाई बढी अर्थ लगाउनु पनि सजिलो छ: साझा ठेगानाले तपाईं कुन नोडसम्म पुग्नुभयो भन्ने बताउँछ, केही थप छ भनेर होइन।

हरेक नोडमा एउटै ठेगाना किन काम गर्छ

हरेक नोडले ठेगाना स्थानीय रूपमा राख्छ र त्यसको लागि जवाफ दिन्छ, त्यसैले आफ्नो वर्तमान सुरुङबाट त्यहाँ पुग्ने ग्राहकले त्यस सुरुङको अर्को छेउमा सेवा पाउँछ। नोडहरूबीच केही समन्वय हुँदैन, र एउटा नोडबाट अर्कोमा कुनै ट्राफिक जाँदैन।

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

त्यसैले उही कन्फिगरेसन तिनीहरूबीच राउटिङ प्रोटोकल बिना हरेक सर्भरमा काम गर्छ। यही कारणले डिजाइनले स्वास्थ्यबारे केही भन्दैन: ठेगाना होस्टसँग बाँधिएको हुनाले, सेवा उपयोगी छ कि छैन भन्नेसँग होइन, बिरामी नोडमा पनि स्वस्थ नोडमा जस्तै उपस्थित हुन्छ।

यसलाई सुरुङमा होइन, लूपब्याकमा तोक्नुहोस्

ठेगाना लूपब्याक इन्टरफेसमा राख्दा यो कुनै पनि सुरुङ उपकरणको जीवनकालबाट अलग हुन्छ, त्यसैले पुनः जडान वा कन्फिगरेसन पुनः लोडले यसलाई हटाउँदैन। होस्ट रहेसम्म ठेगाना रहन्छ।

lo मा रहेको ठेगाना फिल्टर होइन। सेवाले अझै त्यसमा सुन्नुपर्छ, र होस्टको फायरवालले अझै वास्तविक आउँदो मार्ग मूल्याङ्कन गर्छ, जो सुरुङ इन्टरफेसमा आउँछ। लूपब्याक भनेको स्थानीय मात्र हो भनी मान्नेहरू अन्ततः वैध ग्राहकहरूलाई रोक्छन् वा नचाहेको कुरा खुलाउँछन्।

तोकाइलाई hook बाट फेरि थप्नुको सट्टा होस्टको सञ्जाल कन्फिगरेसनमार्फत टिकाउ बनाउनुहोस्। सुरुङ नउठेको नोडमा सेटअप hook चल्दैन, र सेवा ठेगाना सुरुङको गतिविधिमा निर्भर हुनु हुँदैन। ठेगाना तपाईंको वितरणले व्यवस्थापन गर्ने इन्टरफेस कन्फिगरेसनमा राख्नुहोस्, त्यसपछि एक पटक पुनः सुरु गरी जाँच्नुहोस्। पुनः सुरु गर्नु नै पछिको कन्फिगरेसन परिवर्तन सहने एक मात्र परीक्षण हो।

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

एउटा मार्ग धकेल्नुहोस् र एउटै गन्तव्य अभिप्रेत गर्नुहोस्

ग्राहकलाई ठेगानाका लागि होस्ट मार्ग चाहिन्छ, जो उसले जोडिने सर्भरले दिन्छ। हरेक सर्भरले उही गन्तव्य दिने भएकाले ग्राहक सर्दा प्रोफाइल बदलिँदैन।

सेवालाई दोष दिनुअघि ग्राहकले के स्थापना गर्यो जाँच्नुहोस्।

ip route get 10.250.0.1

HTTP सेवाका लागि ठेगानालाई नाम र त्यो नामका लागि प्रमाणपत्र दिनुहोस्। साझा IP पहिचान होइन, र यसले TLS प्रमाणीकरण हटाउँदैन, एउटा निजी कुञ्जी हरेक नोडमा प्रतिलिपि गर्नु पनि न्यायोचित ठहराउँदैन। साझा ठेगानामा रिजोल हुने नामले प्रमाणपत्रको कथा सामान्य राख्छ र आवश्यक परे नोडगत पहिचान राख्न दिन्छ।

साझा ठेगानाले के गर्न सक्दैन

यसले विफलताको बेला हस्तान्तरण दिँदैन। छानिएको नोड मरेमा ठेगाना पनि त्यसैसँग मर्छ, र ग्राहकले अन्तै पुनः जोडिनुपर्छ।

यसले जीवित TCP सत्र स्थानान्तरण गर्दैन, किनकि नयाँ जडान पुरानोबारे केही नजान्ने अर्को होस्टमा टुंगिन्छ।

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

सेवाको पहिचान नामसँगै राख्नुहोस्

ठेगानाको अर्थ लेख्नुहोस्: यो ग्राहक अहिले जोडिएको नोडको सेवासम्म पुग्छ। त्यो एउटा वाक्यले यो ढाँचाले तान्ने अधिकांश गलतफहमी रोक्छ।

त्यसपछि भागहरू सँगै अभिलेख गर्नुहोस्: ठेगाना, यो बस्ने इन्टरफेस, सर्भरले धकेल्ने मार्ग, र सेवाले प्रस्तुत गर्ने नाम र प्रमाणपत्र। भविष्यको पाठकले प्रमाणित गर्न सक्ने चार साना तथ्य, उसले जाँच्ने क्रममै।

आवश्यकता नोड-स्थानीय सेवाका लागि स्थिर गन्तव्य भए, यो ढाँचा मिल्छ र लगभग केही खर्च गर्दैन।

आवश्यकता उपलब्धता भए, एक तह माथि जानुहोस्: लोड ब्यालेन्सर, स्वास्थ्य जाँच सहितको सेवा नाम, वा नोड कसरी प्रतिस्थापन गर्ने पहिले नै जान्ने अर्केस्ट्रेसन प्रणाली।

यसलाई चाँडै निर्णय गर्दा साझा ठेगाना जे छ त्यही, एउटा सुविधाजनक लेबल रहन्छ, कहिल्यै नडिजाइन गरिएको काम चुपचाप अपेक्षा गरिने घटक बन्नुको सट्टा।

सम्बन्धित लेखहरू