OpenVPN इंजन या Tunnelblick: Mac VPN सत्र का मालिक कौन है?

Homebrew एक OpenVPN प्रोग्राम इंस्टॉल करता है; Tunnelblick एक प्रबंधक इंस्टॉल करता है जो एक या अधिक इंजन चलाता है। ये अलग परतें हैं, और उपयोगी सवाल यह नहीं है कि आपको टर्मिनल इस्तेमाल करना पसंद है या नहीं। सवाल यह है कि कॉन्फ़िगरेशन, DNS बदलाव, क्रेडेंशियल का अनुरोध और सत्र खत्म होने पर सफ़ाई किसकी है। इन परतों के लिए एक ही मालिक होना ही सेटअप को अनुमान-योग्य बनाता है।

नीचे दी गई पाँच जाँचें क्रम से करें। जिस पहली जाँच में दो मालिक हों, वही वे अजीब आधे-जुड़े हालात बनाती है जिन्हें लोग OpenVPN पर ही दोष देते हैं। हर जाँच उस सबूत का नाम लेती है जो उसे तय करता है।

पहली जाँच: कौन-सी OpenVPN बाइनरी वास्तव में चल रही है

जुड़े रहते हुए pgrep -fl openvpn चलाएँ और पूरी कमांड लाइन पढ़ें। पहला पथ वही इंजन है जो वास्तव में चल रहा है। Apple Silicon पर Homebrew इंस्टॉल आमतौर पर /opt/homebrew के नीचे रहता है, जबकि Intel Mac /usr/local इस्तेमाल करते हैं, और Tunnelblick अपने ही एप्लिकेशन बंडल के अंदर से इंजन चलाता है।

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

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

दूसरी जाँच: DNS और रूट कौन बदलता है

इंजन OpenVPN के अपने up और down निर्देश चला सकता है, लेकिन प्रबंधक उसी जीवन-चक्र का मालिक हो सकता है। Tunnelblick की नेमसर्वर सेटिंग्स उसके मानक कनेक्शन और डिस्कनेक्शन स्क्रिप्ट नियंत्रित करती हैं, और जब वह एकीकरण सक्रिय हो, तो प्रोफ़ाइल के प्रतिस्पर्धी निर्देशों को अनदेखा किया जा सकता है।

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

पहले कनेक्शन से पहले तय करें कि कौन-सी परत DNS की मालिक है, फिर दोनों को रहने देने के बजाय हारने वाला निर्देश हटा दें। रूट बदलाव भी वही नियम मानते हैं: एक मालिक, कॉन्फ़िगरेशन में दिखने वाला, दस्तावेज़ीकृत पुनर्स्थापना पथ के साथ।

तीसरी जाँच: क्रेडेंशियल कहाँ से आते हैं

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

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

चौथी जाँच: प्रोसेस को कौन शुरू करता, निगरानी रखता और रोकता है

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

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

आप कोई भी मालिक चुनें, तय करें कि स्लीप, नेटवर्क बदलाव और लॉगआउट पर क्या होता है। प्रबंधक आमतौर पर उन घटनाओं को संभालता है; खाली प्रोसेस आमतौर पर नहीं, और परिणामी पुराना रूट या रिज़ॉल्वर सर्वर की खराबी समझ लिया जाता है।

पाँचवीं जाँच: हैंडओवर कैसे सत्यापित होता है

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

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

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

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