pfSense VPN सर्वर और क्लाइंट के रूप में: दो रास्ते, एक राउटर

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

कोई भी सेटिंग छूने से पहले दोनों भूमिकाओं के नाम तय करें

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

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

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

सर्वर के उत्तर WAN पथ पर ही रखें

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

आउटबाउंड टनल को अपना ही अंत-बिंदु खाने न दें

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

चुनें कि किन उपयोगकर्ताओं को एग्ज़िट मिले

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

तय करें कि एग्ज़िट विफल होने पर क्या होगा

विफलता का व्यवहार होने से पहले लिखें: जब आउटबाउंड टनल गिरे, तो उपयोगकर्ता सामान्य WAN पर लौटते हैं या एग्ज़िट लौटने तक अवरुद्ध रहते हैं? दोनों उत्तर उचित हैं, और उपकरण आपके लिए नहीं चुनेगा। हटाया गया रूट या मृत गेटवे की ओर इशारा करती नीति अपने आप पूर्ण अवरोध का नतीजा नहीं देती। यदि अवरोध चाहिए, तो नीति को यह स्पष्ट कहना होगा, और एग्ज़िट हटाकर ही उसकी जाँच होनी चाहिए, उसके बारे में सोचकर नहीं। यदि वापसी चाहिए, तो उपयोगकर्ताओं को बता दें, क्योंकि चुपचाप सामान्य रास्ता लेने वाला ट्रैफ़िक ठीक वही ट्रैफ़िक है जिसे किसी ने ढका हुआ माना था।

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

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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