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 मॅन्युअल हेल्परचे आर्ग्युमेंट आणि त्याचा विस्तार दस्तऐवजीकरण करते, जे कोणता निर्देश आपल्या शेजाऱ्यासारखेच संकेतन घेतो असे गृहीत धरण्यापूर्वी वाचण्यासारखे आहे.