एक OpenVPN क्लाइंट पर दो सेवा पते: iroute और lo

एप्लिकेशन अपने टनल पते पर उत्तर देता है, और जो पता आपने इसके लिए दस्तावेज़ किया है वह कहीं नहीं जाता। OpenVPN लॉग में कुछ शिकायत नहीं करता, पीयर जुड़ा दिखता है, और हब ठीक एक क्लाइंट सूचीबद्ध करता है। अंतर यह है कि क्लाइंट पर दूसरा पता दो अलग तथ्य हैं: होस्ट को उसका मालिक होना चाहिए, और हब को जानना चाहिए कि कौन सा पीयर उसका मालिक है। एक को दूसरे के बिना संभालें और ट्रैफ़िक या तो हब पर मर जाता है या घर का मार्ग बिना पहुँचता है।

उपनाम स्थानीय है, स्वामित्व दूर है

टनल पते पर बातचीत होती है, इसलिए दोनों सिरे हैंडशेक के दौरान उसे सीखते हैं। अतिरिक्त सेवा पते पर बिल्कुल बातचीत नहीं होती, इसलिए उसे जोड़ने से हब पर अपने आप कुछ नहीं बदलता। क्लाइंट तुरंत पते का मालिक हो सकता है और सर्वर वह ट्रैफ़िक फिर भी अपने डिफ़ॉल्ट मार्ग पर भेजेगा या उसे गिरा देगा। दो रिकॉर्ड, दो अलग जगहों पर बनाने होंगे।

क्लाइंट पर पता होस्ट का है, और लूपबैक उस सेवा पहचान का स्वाभाविक घर है जो कभी भौतिक लिंक पर नहीं दिखनी चाहिए। हब पर पीयर-से-प्रीफ़िक्स मैपिंग एक अलग घोषणा है जिसे केवल सर्वर पढ़ता है। कोई भी रिकॉर्ड दूसरे को निहित नहीं करता।

अपने नोट्स में भी दोनों रेंज अलग रखें। उदाहरण के पते दस्तावेज़ीकरण मान हैं, और उन्हें असली LAN के साथ ओवरलैप करना काम कर रहे सेटअप को टूटा दिखाने का सबसे तेज़ तरीका है।

क्लाइंट पर पता स्थायी रूप से जोड़ें

सेवा पते को होस्ट प्रीफ़िक्स के साथ लूपबैक पर रखें, ताकि होस्ट उसे पहुँचने योग्य सबनेट के बजाय स्थानीय इनपुट माने। ip address add 10.66.0.10/32 dev lo एक पते के लिए ऐसा करता है, और दूसरे पते के लिए कमांड दोहराना दो सेवाओं का मॉडल बनाता है।

इसे एक बार की परीक्षा के रूप में चलाएँ, फिर इसे उस चीज़ में ले जाएँ जो होस्ट के नेटवर्क कॉन्फ़िगरेशन का मालिक है, क्योंकि रनटाइम जोड़ रीबूट पर गायब हो जाता है और पुनः कनेक्शन के बीच नकलें जमा होती हैं। नेटवर्क के बाद क्रमित systemd यूनिट एक विकल्प है, और डिस्ट्रिब्यूशन नेटवर्क मैनेजर दूसरा। आप जो भी चुनें, एप्लिकेशन के बाइंड होने से पहले पता मौजूद होना चाहिए, वरना सेवा गलत सॉकेट पर उठती है। मैन्युअल कमांड के बाद नहीं, रीबूट के बाद ip address show dev lo से जाँचें।

बाइंडिंग एड्रेसिंग से अलग निर्णय है। हर पते पर सुनने वाला एप्लिकेशन उन इंटरफ़ेस पर ट्रैफ़िक स्वीकार करता है जिनका आपने कभी इरादा नहीं किया, इसलिए उसे विशिष्ट सेवा पते की ओर इंगित करें। तब स्थानीय इनपुट नीति के पास मिलाने के लिए कुछ सटीक होता है।

इसे उस CCD फ़ाइल में दावा करें जिसे हब वास्तव में पढ़ता है

सर्वर पर, स्वामित्व की घोषणा प्रमाणित सामान्य नाम द्वारा चुनी गई प्रति-क्लाइंट फ़ाइल में जाती है, client-config-dir द्वारा नामित निर्देशिका के अंदर। पंक्ति iroute 10.66.0.10 255.255.255.255 है, प्रति पता एक, और यह सर्वर को बताती है कि उस गंतव्य के लिए कौन सा पीयर ट्रैफ़िक प्राप्त करे।

दो विवरण इसे चुपचाप तोड़ते हैं। फ़ाइल का नाम उस नाम से मेल खाना चाहिए जिसे सर्वर वास्तव में उपयोग करता है, जो तब अलग होता है जब username-as-common-name खेल में हो। और iroute केवल TUN मोड में क्लाइंट कॉन्फ़िगरेशन निर्देशिका कॉन्फ़िगर होने पर लागू होता है, इसलिए ब्रिज्ड परिनियोजन में वही पंक्ति कुछ नहीं करती। मौजूदा फ़ाइल में पंक्तियाँ जोड़ें, उसे बदलें नहीं, क्योंकि उसमें पहले से स्थिर पता या push विकल्प हो सकते हैं। OpenVPN 2.6 संदर्भ निर्देशिका और स्वामित्व निर्देश दोनों का दस्तावेज़ीकरण करता है।

हब के अपने कर्नेल को भी उन गंतव्यों तक मार्ग चाहिए ताकि स्थानीय रूप से उत्पन्न ट्रैफ़िक टनल प्रक्रिया में प्रवेश करे। सर्वर कॉन्फ़िगरेशन में route 10.66.0.10 255.255.255.255 उस ट्रैफ़िक को कवर करता है जो सर्वर स्वयं उत्पन्न करता है, जबकि अन्य क्लाइंट को गंतव्य स्वयं सीखने के लिए push "route 10.66.0.10 255.255.255.255" चाहिए।

रूटिंग और प्राधिकरण अलग रहते हैं। धकेला गया मार्ग क्लाइंट को बताता है कि पैकेट कहाँ भेजें और कुछ प्रदान नहीं करता; सेवा को अभी भी कॉलर को अपनी शर्तों पर स्वीकार करना है।

इनपुट नीति और उत्तर मार्ग जाँचें

उपनाम को संबोधित पैकेट मालिक होस्ट पर स्थानीय इनपुट के रूप में पहुँचता है, इसलिए सवाल यह है कि स्थानीय फ़ायरवॉल उस स्रोत और पोर्ट की अनुमति देता है या नहीं। पूरा पता खोलने के बजाय VPN स्रोत रेंज से विशिष्ट सेवा पोर्ट की अनुमति दें।

उत्तरों को कॉलर तक वापसी मार्ग चाहिए। सामान्य टनल पूल के भीतर के कॉलर के लिए वह मार्ग पहले से मौजूद है, क्योंकि टनल डिवाइस उसे ले जाता है। किसी अन्य रूटेड नेटवर्क के पीछे का कॉलर उस नेटवर्क के वापसी मार्ग की भी ज़रूरत रखता है, और यहीं असममित सेटअप पैकेट खोते हैं।

उसी पोर्ट पर किसी दूसरे पते से बंधे दूसरे श्रोता पर ध्यान दें, क्योंकि कर्नेल जो सॉकेट मेल खाता है उसी को देता है और परिणाम अनियमित लगते हैं। ss -lntp से जाँचें और पुष्टि करें कि बंधा पता सेवा उपनाम है। यहाँ स्रोत NAT आवश्यक नहीं है, और इसे जोड़ने से वह कॉलर पहचान छिप जाती है जिस पर आपके लॉग निर्भर हैं।

पते और स्वामित्व अलग-अलग जाँचें

दो चरणों में जाँचें। पहले पुष्टि करें कि मालिक होस्ट स्वयं से अपने उपनाम पर सेवा तक पहुँच सकता है, जो बाइंड और फ़ायरवॉल समस्याओं को रूटिंग से अलग करता है। फिर एप्लिकेशन के अपने प्रमाणीकरण का उपयोग करते हुए असली VPN कॉलर से जाँचें। जब पहला पास हो और दूसरा विफल हो, तो छूटा हुआ टुकड़ा हब की ओर है।

उन विफलता विधियों को भी जाँचें जो कनेक्शन के बाद भी बची रहती हैं: टनल बंद होने पर उपनाम आवंटित रहता है, और पीयर अनुपस्थित होने पर हब अपना मार्ग रखता है। कोई भी वस्तु अकेले यह सिद्ध नहीं करती कि सेवा पहुँच योग्य है, इसलिए दो-चरणीय परीक्षा लैपटॉप से एक पिंग से बेहतर है।