OpenVPN सर्भर सहायक: नेटवर्क र नेटमास्क, कहिल्यै CIDR होइन

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

सहायकले स्वीकार गर्ने दुई आर्गुमेन्ट

पहिले नेटवर्क लेख्नुहोस् र त्यसपछि मास्क, ठेगानासँग केही पनि नजोडी:

server 10.72.16.0 255.255.240.0

यो /20 को रूप हो। तलको लाइन गल्ती हो, र यो रनटाइममा होइन, विकल्प पार्सिङमा असफल हुन्छ:

server 10.72.16.0/20 255.255.240.0

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

मास्क लेख्नुअघि नेटवर्क पङ्क्तिबद्ध गर्नुहोस्

पहिलो ठेगाना दायराको नेटवर्क ठेगाना हो, त्यसभित्रको सुविधाजनक क्लाइन्ट ठेगाना होइन। /20 का लागि दायरा 10.72.16.0 देखि 10.72.31.255 सम्म चल्छ, र तीमध्ये पहिलो मात्र मान्य नेटवर्क आर्गुमेन्ट हो। /21 ले 255.255.248.0 प्रयोग गर्छ र 10.72.16.0 देखि 10.72.23.255 सम्म समेट्छ, त्यसैले त्यसको लाइन server 10.72.16.0 255.255.248.0 हो।

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

सर्भरको तर्फबाट पूल पुष्टि गर्नुहोस्

इन्स्टन्स अगाडिको पृष्ठभूमिमा विस्तृत लगिङसहित सुरु गर्नुहोस् र सहायकले निकाल्ने लाइनहरू पढ्नुहोस्। यसले बनाएको पूल सुरुवातमा छापिन्छ, जुन हातले गणित गर्नुभन्दा बढी भरपर्दो हुन्छ:

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

आउटपुटको माथिल्लो भागनजिक पूल सारांश खोज्नुहोस्। त्यसमा सहायकले आरक्षित गरेको दायरा सूचीबद्ध हुन्छ, र त्यो दायरा तपाईंको मनसायसँग मिलेन भने मास्कको गणितले जे भने पनि लाइनका आर्गुमेन्ट गलत हुन्छन्।

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

टोपोलोजी विचार गरेर क्लाइन्टको मास्क पढ्नुहोस्

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

निष्कर्षमा पुग्नुअघि कन्फिगर गरिएको टोपोलोजी र तोकिएको ठेगाना सँगै जाँच्नुहोस्:

ip -4 addr show tun0

ठेगाना पूलभित्र छ र मास्क पूलभन्दा साँघुरो छ भने त्यो टोपोलोजीले आफ्नो काम गरिरहेको हो। ठेगाना पूलबाहिर छ भने पूल गलत छ, र क्लाइन्ट पक्षको कुनै पनि जाँचले त्यो सुधार्ने छैन।

चलिरहेको पूल परिवर्तन गर्ने

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

लाइन परिवर्तन गर्नुहोस्, रिस्टार्ट गर्नुहोस् र प्रयोगकर्ताहरूलाई फर्किन दिनुअघि स्टार्टअप पूल फेरि पढ्नुहोस्। नयाँ दायरा कुनै कुरासँग ठोक्कियो भने त्यही स्टार्टअप आउटपुटले तुरुन्तै देखाउँछ, र फर्काउनु भनेको एउटा लाइनको सम्पादन र अर्को रिस्टार्ट हो।

परिवर्तनपछि केही समय पुरानो दायरा आरक्षित राख्नुहोस्। ढिलो जोडिने क्लाइन्टहरूले अझै अघिल्लो पूलको ठेगाना राख्न सक्छन्, र ती ठेगानाहरू पुनः प्रयोग गर्ने नयाँ दायराले राउटिङ खराबीजस्तो देखिने दोहोरो बाँडफाँट सिर्जना गर्छ। OpenVPN 2.6 म्यानुअल ले सहायकका आर्गुमेन्ट र त्यसको विस्तारको दस्तावेजीकरण गर्छ, जुन कुनै निर्देशनले आफ्नो छिमेकीजस्तै संकेतन लिन्छ भनेर मान्नुअघि पढ्न लायक छ।