OpenVPN क्लाइंट गेटवे के IPsec सिलेक्टर क्यों चूक जाते हैं

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

गेटवे का ping उस फ़्लो को जाँचता है जिसे आपका क्लाइंट कभी इस्तेमाल नहीं करता

स्रोत पता तय करता है कि कौन सी नीति लागू होगी। गेटवे पर बना पैकेट अपने स्थानीय LAN या अपने टनल एंडपॉइंट के पते के साथ निकलता है, और जो नीति उससे मेल खाती है वह ठीक उसी मामले के लिए लिखी गई थी। क्लाइंट का पैकेट OpenVPN इंटरफ़ेस पर क्लाइंट पूल के पते के साथ आता है, जो बिल्कुल अलग सिलेक्टर है।

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

वह दूर का प्रीफ़िक्स पुश करें जिसकी एप्लिकेशन को सचमुच ज़रूरत है

जुड़े क्लाइंट के लिए 10.8.0.0/24 और सुरक्षित दूर के नेटवर्क के लिए 172.30.239.0/25 की यह उदाहरण जोड़ी लें। क्लाइंट को उस दूसरे प्रीफ़िक्स का रूट चाहिए, गेटवे के LAN का नहीं और किसी दूसरे टनल पते का भी नहीं। पूल में पुश किया गया रूट ही क्लाइंट को वह ट्रैफ़िक गेटवे को सौंपने पर मजबूर करता है। इसके बिना पैकेट कभी उस नीति-निर्णय तक नहीं पहुँचता जिसे आप डीबग कर रहे हैं।

जो Community सर्वर पुश किए गए रूट स्वीकार करता है, वहाँ निर्देश असली मास्क लेता है: push "route 172.30.239.0 255.255.255.128"। Access Server वही गंतव्य इंस्टॉल किए गए संस्करण की प्राइवेट-नेटवर्क या एक्सेस-रूल सेटिंग्स से कॉन्फ़िगर करता है, और राउटेड या अनुवादित मोड सोच-समझकर चुना जाता है। मालिक कॉन्फ़िगरेशन के बजाय जनरेट की गई फ़ायरवॉल चेन संपादित करना ही वह रास्ता है जिससे काम करता सेटअप दोबारा बनाना असंभव हो जाता है।

जुड़ने के बाद सर्वर का इरादा नहीं, क्लाइंट की रूटिंग टेबल पढ़ें। सिर्फ़ पूल को ढकने वाला रूट मतलब पुश कभी नहीं पहुँचा, और टनल से डिफ़ॉल्ट रूट इस ज़रूरत से बड़ा है और आगे आपको चौंकाएगा। मास्क और प्रीफ़िक्स दोनों जाँचें, क्योंकि /25 को /24 के रूप में पुश करने से पड़ोसी पतों का ट्रैफ़िक ऐसे रास्ते में जाता है जो उसे ढो नहीं सकता। फिर पुष्टि करें कि क्लाइंट ने उस गंतव्य के लिए टनल इंटरफ़ेस चुना है।

सिलेक्टरों में क्लाइंट पूल शामिल करें

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

कॉन्फ़िगर किए गए प्रस्तावों के साथ-साथ बातचीत तय नीति भी जाँचें, जैसे strongSwan पर ipsec statusall या आपके कार्यान्वयन के बराबर का स्टेटस कमांड। नीति-आधारित IPsec में सामान्य रूट किसी भौतिक इंटरफ़ेस की ओर हो सकता है जबकि मेल खाता ट्रैफ़िक अब भी एन्क्रिप्ट होता है, इसलिए टनल डिवाइस का न होना कुछ साबित नहीं करता। सिलेक्टर जोड़ियों की तुलना उस पूल और प्रीफ़िक्स से करें जो आपने लिखा था।

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

सोच-समझकर राउटिंग या अनुवाद चुनें

राउटिंग क्लाइंट का पता दूर के पक्ष के लिए दिखने योग्य रखती है, इसलिए दूर के लॉग और प्रति-स्रोत नियम अर्थपूर्ण रहते हैं, और यह माँग करती है कि दूर का गेटवे पूल तक वापसी का रास्ता जाने। अनुवाद पूल को एक पते के पीछे छिपा देता है, जो वापसी-मार्ग की समस्या हटा देता है और प्रति-क्लाइंट पहचान नष्ट कर देता है।

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

फ़ॉरवर्डिंग और जवाब पर लूप बंद करें

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

एक असली क्लाइंट-से-एप्लिकेशन अनुरोध से सत्यापित करें, और देखें कि वह OpenVPN इंटरफ़ेस, IPsec निर्णय और दूर के होस्ट से गुज़रता है। जवाब को अलग अवलोकन के रूप में देखें, क्योंकि पहुँचता अनुरोध और कभी न लौटने वाला जवाब क्लाइंट की जगह से एक जैसे दिखते हैं। एक ट्रेस किया गया अनुरोध गेटवे के कितने भी ping से ज़्यादा मूल्यवान है।

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