ipp.txt मा एउटा लाइन सम्पादन गर्नु ठेगाना आरक्षित गरेजस्तो लाग्छ, तर त्यस्तो होइन। त्यो फाइल, जसलाई ifconfig-pool-persist ले नाम दिन्छ, साझा नामसँग पछिल्लो पटक कुन ठेगाना थियो भनी रेकर्ड गर्छ, ताकि पूल सुविधाजनक हुँदा त्यही ठेगाना फर्काउन सकोस्। यसमा केही पनि अर्को जडानलाई त्यो नम्बरसँग बाँध्दैन।

तलका जाँचहरू क्रममा चलाउनुहोस्। प्रत्येकले या त संयन्त्र पुष्टि गर्छ या रोकिएर इनपुट सुधार्न भन्छ।

स्थायित्व फाइल के का लागि हो

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

यदि तपाईंलाई कुनै विशेष क्लाइन्टका लागि विशेष ठेगाना चाहिन्छ भने, अभिलेखित संयन्त्र ifconfig-push हो, र त्यो त्यस क्लाइन्टको स्वामित्वको कन्फिगरेसनमा पर्छ।

सही क्लाइन्ट छानिएको छ कि जाँच्नुहोस्

स्पष्ट आवंटन क्लाइन्टको साझा नामबाट खोजिन्छ, त्यसैले गलत पहिचानका लागि नाम दिइएको फाइल कहिल्यै पढिँदैन। सर्भरले त्यस क्लाइन्टको नाम के मान्छ भनी पुष्टि गर्नुहोस्, विशेष गरी जहाँ username-as-common-name ले प्रमाणीकरणपछि त्यो बदल्छ। त्यसपछि फाइलको नाम त्यो मानसँग ठ्याक्कै मिल्छ कि भनी, अक्षरका ठुला-साना रूपसहित पुष्टि गर्नुहोस्।

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

सङ्ख्याहरू टोपोलोजीसँग मिल्छन् कि जाँच्नुहोस्

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

ठेगानालाई यसको स्वामित्व लिन सक्ने अरू सबैसँग जाँच्नुहोस्: अर्को स्पष्ट आवंटन, गतिशील पूलको दायरा, र स्थिर होस्ट मान्ने कुनै पनि स्थिर मार्ग। पूलसँग ओभरल्याप हुने ठेगाना पूलले त्यो अरू कसैलाई नदिएसम्म काम गर्नेछ, र त्यो असफलता अनियमित देखिनेछ।

नयाँ जडानमा नतिजा जाँच्नुहोस्

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

प्रमाणहरू सँगै राख्नुहोस्: क्लाइन्टको नाम, मिलेको फाइल, आवंटित ठेगाना र त्यो आएको पूल।

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

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