pfSense OpenVPN: किसी दूसरे राउटर के पीछे के नेटवर्क तक पहुँचना

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

कोई नियम बदलने से पहले एक पैकेट को इन तीन निर्णयों से गुज़ारें, क्योंकि हर मालिक का नियंत्रण अलग है और विफलता का तरीक़ा भी अलग है।

एक पैकेट, तीन रूटिंग निर्णय

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

इनमें से किसी एक की विफलता वही उपयोगकर्ता रिपोर्ट देती है। इसीलिए डिबगिंग का क्रम उपकरणों से ज़्यादा मायने रखता है।

क्लाइंट को प्रीफ़िक्स दें, अनुमान नहीं

IPv4 टनल नेटवर्क /30 से बड़ा होने पर pfSense SSL/TLS सर्वर पर, IPv4 Local network(s) फ़ील्ड जुड़ते समय क्लाइंट को रूट वितरित करता है। क्लाइंट के अपने आप कोई बना लेने के भरोसे के बजाय नीचे का प्रीफ़िक्स वहाँ जोड़ें। फिर जुड़ने के बाद क्लाइंट की वास्तविक तालिका पढ़ें, क्योंकि route-nopull वाली प्रोफ़ाइल या रूट फ़िल्टर सर्वर द्वारा भेजे गए को नज़रअंदाज़ कर सकते हैं। सर्वर पूरी तरह सही हो सकता है जबकि क्लाइंट कुछ भी इंस्टॉल न करे।

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

pfSense को आंतरिक राउटर की ओर इंगित करें

pfSense में स्थिर रूट के लिए परिभाषित और पहुँचने योग्य गेटवे चाहिए, और उस गेटवे के लिए चुना गया इंटरफ़ेस वही होना चाहिए जो वास्तव में वहाँ पहुँचता है, जैसा Netgate की स्थिर-रूट मार्गदर्शिका बताती है। एक उदाहरण लेआउट में ट्रांज़िट लिंक फ़ायरवॉल पर 192.168.77.1 और आंतरिक राउटर पर 192.168.77.2 है, और सेवा नेटवर्क उसके पीछे 172.16.30.0/25 पर है। तब रूट प्रीफ़िक्स और अगले हॉप का नाम देता है, सेवा के पते का नहीं। दूर के नेटवर्क का पता गेटवे के रूप में इस्तेमाल करना ऐसा रूट बनाने का आम तरीक़ा है जो सही दिखता है और कहीं फ़ॉरवर्ड नहीं करता।

किसी इंटरफ़ेस को नाम देना उसके पीछे के नेटवर्क का वर्णन नहीं करता। स्थिर रूट वही वर्णन है।

दूर के पक्ष को पूल पता होना चाहिए

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

इस डिज़ाइन के लिए कोई अनुवाद आवश्यक नहीं है, और क्लाइंट का स्रोत पता दृश्यमान रखने से नीचे का नेटवर्क अपनी नीति लागू कर सकता है।

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

तीन मालिकों की योजना को अनुमत एप्लिकेशन के साथ सहेजें, ताकि अगला प्रशासक रास्ते को फिर से खोजने के बजाय उसे फिर से बना सके।