एक Pi, दो OpenVPN इंस्टेंस: प्रत्येक यूनिट क्या पढ़ती है
एक Pi पर दो OpenVPN डेमन अलग-अलग कॉन्फ़िग फ़ाइलें पढ़ते हैं और अलग-अलग हुक से बाहर निकलते हैं। हर इंस्टेंस को मैप करें, फिर पेलोड का रास्ता अलग से जाँचें।
किसी प्रोफ़ाइल को छूने से पहले OpenVPN प्रक्रियाओं की गिनती करें। जो Pi रोमिंग उपयोगकर्ताओं को स्वीकार करता है और साथ ही अपस्ट्रीम सेवा को डायल करता है, वह दो डेमन चलाता है, और उनमें से प्रत्येक आपके द्वारा टाइप किए गए इंस्टेंस नाम से चुनी गई कॉन्फ़िगरेशन फ़ाइल पढ़ता है। फिर पैकेज किए गए टेम्पलेट प्रत्येक डेमन को उसकी अपनी कार्यशील निर्देशिका, उसकी अपनी रनटाइम स्थिति फ़ाइल और उसका अपना टनल उपकरण देते हैं। यह विभाजन गलत करने पर आप एक शाम ऐसी फ़ाइल में सही सेटिंग बदलने में बिताएँगे जिसे चल रही प्रक्रिया कभी नहीं खोलती।
हर इंस्टेंस नाम अपनी फ़ाइल चुनता है
OpenVPN 2.6 के साथ आने वाली यूनिट फ़ाइलों में, प्रारंभिक आर्ग्युमेंट में एक इंस्टेंस प्लेसहोल्डर होता है जो @ चिह्न के बाद के पाठ से भरा जाता है। सर्वर टेम्पलेट सर्वर कॉन्फ़िगरेशन निर्देशिका से चलता है और अपने आर्ग्युमेंट को वहाँ %i.conf के विरुद्ध हल करता है, जबकि क्लाइंट टेम्पलेट क्लाइंट निर्देशिका से वही करता है। इसलिए [email protected] सर्वर निर्देशिका में admits.conf पढ़ता है और [email protected] क्लाइंट निर्देशिका में uplink.conf पढ़ता है, और दोनों नामों में से किसी का भी दूसरी निर्देशिका में कोई अर्थ नहीं है।
पैकेज ने अपस्ट्रीम डिफ़ॉल्ट रखे हैं यह मानने के बजाय मशीन पर ही मैपिंग की पुष्टि करें। वितरण का ड्रॉप-इन कार्यशील निर्देशिका या कॉन्फ़िग आर्ग्युमेंट को सीधे बदल सकता है।
systemctl cat [email protected]
systemctl cat [email protected]उस आउटपुट में WorkingDirectory पंक्ति और कॉन्फ़िग आर्ग्युमेंट पढ़ें, क्योंकि सक्षम यूनिट ही एकमात्र चीज़ है जो तय करती है कौन-सी फ़ाइल लोड होगी। जो ड्रॉप-इन --config को ExecStart में जोड़ता है, वह टेम्पलेट का रास्ता सही दिखने पर भी टेम्पलेट को हरा देता है। जब जानना हो कि स्थानीय ओवरराइड लागू है या नहीं, तो फ़्रैगमेंट और ड्रॉप-इन के रास्ते पूछें। अगर दोनों भूमिकाएँ एक ही फ़ाइल पर हल हों, तो आपके पास एक ही प्रक्रिया है जो सर्वर और क्लाइंट दोनों बनने की कोशिश कर रही है, और उस फ़ाइल में बाद वाला विकल्प चुपचाप जीत जाता है।
स्थानीय परिवहन और फ़ॉरवर्ड किया गया पेलोड अलग हुक से टकराते हैं
सर्वर का हर रोमिंग उपयोगकर्ता से एन्क्रिप्टेड कनेक्शन Pi पर ही बनता है, इसलिए उसके बाहरी उत्तर स्थानीय आउटपुट हुक से बाहर जाते हैं। क्लाइंट का अपने अपस्ट्रीम साथी से कनेक्शन भी स्थानीय रूप से बना आउटपुट है, भले ही वह दूर के नेटवर्क तक पहुँचता है। फ़ॉरवर्ड किया गया पेलोड तीसरी श्रेणी है, और कर्नेल उसे पैकेट के लिए आउटबाउंड डिवाइस पहले ही चुन लेने के बाद ही मिलाता है।
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
फ़ॉरवर्ड श्रृंखला के भीतर किसी आउटबाउंड इंटरफ़ेस से मेल खाने वाला नियम उस पैकेट को अनुमति दे सकता है या गिरा सकता है जिसे रूटिंग पहले ही उस इंटरफ़ेस को सौंप चुकी है, लेकिन वह कभी इंटरफ़ेस नहीं चुनता। जब एक होस्ट एक टनल समाप्त करता है और दूसरी शुरू करता है, तो उपयोगकर्ता पेलोड को अपस्ट्रीम टनल में भेजने वाली नीति और Pi के अपने एन्क्रिप्टेड उत्तरों की रक्षा करने वाली नीति अलग निर्णय हैं। वे संयोग से एक ही भौतिक नेटवर्क कार्ड पर पहुँचते हैं, इसीलिए उन्हें भ्रमित किया जाता है।
यही अंतर एक आम आधी-असफलता की व्याख्या करता है। उपयोगकर्ता जुड़ते हैं, हैंडशेक पूरा होता है, और उनका ट्रैफ़िक फिर भी गलत रास्ते से निकलता है, क्योंकि हैंडशेक स्थानीय था और पेलोड फ़ॉरवर्ड हुआ था और दोनों में से केवल एक की कभी जाँच हुई थी।
आयातित रूट आपके उपयोगकर्ताओं को जाने वाले उत्तरों को निगल सकता है
क्लाइंट प्रोफ़ाइल की सुरक्षा सेटिंग तय करती है कि अपस्ट्रीम Pi की रूटिंग तालिका में क्या धकेल सकता है, और व्यापक रीडायरेक्ट वही विकल्प है जो काम करते दोहरे-भूमिका वाले होस्ट को टूटे हुए होस्ट में बदल देता है। अगर धकेला गया रूट रोमिंग उपयोगकर्ताओं के सार्वजनिक पतों को ढकता है, तो सर्वर उनके लिए जो उत्तर बनाता है वे अंडरले से बाहर निकलने के बजाय नए रूट का अनुसरण करके अपस्ट्रीम टनल में जा सकते हैं। लोग अक्सर पुष्टि करते हैं कि प्रदाता तक टनल अब भी काम करती है और वहीं रुक जाते हैं, क्योंकि वह ट्रैफ़िक टनल का अपना परिवहन है और बाकी सब गलत व्यवहार करते हुए भी वह बहता रहता है।
स्रोत या मार्क आधारित नीति ही दोनों धाराओं को अलग रखने का तरीका है। OpenVPN का लिनक्स मार्क विकल्प डेमन के अपने एन्क्रिप्टेड पैकेट पर फ़ायरवॉल मार्क लगाता है, जिसे फिर रूटिंग नियम समर्पित तालिका में भेज सकता है। स्रोत पते भी तब उतने ही अच्छे काम करते हैं जब सर्वर के बाहरी उत्तर हमेशा एक ही अंडरले पते से निकलते हों। दोनों दृष्टिकोणों को अपनी चुनी हुई तालिका में मान्य रूट और प्रदाता के एंडपॉइंट के लिए अपवाद चाहिए, वरना टनल खुद ऊपर आना बंद कर देती है।
कोई भी नियम लिखने से पहले कर्नेल से पूछें कि उत्तर वास्तव में कौन-सा रास्ता लेगा। नीचे दिए पते Pi के अंडरले पते और एक रोमिंग उपयोगकर्ता के सार्वजनिक पते के प्लेसहोल्डर हैं।
ip rule show
ip route get 198.51.100.7 from 192.0.2.10विभाजन सत्यापित करें, फिर एक बार में एक भूमिका रोकें
तीनों धाराओं को अलग-अलग जाँचें, क्योंकि काम करता हैंडशेक बाकी दो के बारे में कुछ साबित नहीं करता। नया इनबाउंड कनेक्शन स्वीकार करें, एक अनुमत एप्लिकेशन अपस्ट्रीम एग्ज़िट से भेजें, और पुष्टि करें कि दोनों प्रक्रियाएँ अब भी अपने-अपने साथियों तक पहुँचती हैं।
फिर क्लाइंट भूमिका रोकें और देखें कि सर्वर भूमिका क्या बनाए रखती है। किसी एक इंस्टेंस के लिए बनाया गया पर दोनों पर लागू किया गया रूट या मार्क नियम खोजने का यह सबसे सस्ता तरीका है।
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerआप जो देखना चाहते हैं वह यह है कि लिसनर अब भी बंधा है, टनल डिवाइस अब भी मौजूद है, और क्लाइंट भूमिका बंद होने के दौरान लॉग नई त्रुटियों से मुक्त है। अगर क्लाइंट रोकने से सर्वर के मौजूदा उपयोगकर्ताओं को जाने वाले उत्तर भी कट जाते हैं, तो दोनों भूमिकाएँ ऐसी चीज़ साझा करती हैं जो एक तक ही सीमित होनी चाहिए थी। लिखें कि हर बदलाव ने किस इंस्टेंस, किस कॉन्फ़िग फ़ाइल और किस फ़्लो मालिक को छुआ, क्योंकि इस होस्ट को डीबग करने वाला अगला व्यक्ति वरना वही खोज शून्य से दोहराएगा।