OpenVPN इन्जिन वा Tunnelblick: Mac VPN सत्र कसको हो?
टर्मिनल विभाजक रेखा होइन। सत्र कसको हो निर्णय गर्नुहोस्: तपाईंले सुरु गर्ने इन्जिन, वा DNS, प्रमाणहरू र सफाई सम्हाल्ने प्रबन्धक।
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 एकीकरण सक्रिय गर्नुहोस् र त्यसको विरोध गर्ने प्रोफाइल निर्देशनहरू हटाउनुहोस्। त्यसपछि ती तीनै जाँच दोहोर्याउनुहोस्। चल्ने तर रिजोल्भर परिवर्तन भएको छोड्ने जडान टनेल उठे पनि असफल हस्तान्तरण हो।
प्याकेजिङले सर्भरसँगको अनुकूलता टुंगो लगाउँदैन। सेवाका आफ्नै ग्राहक आवश्यकता जाँच्नुहोस्, र त्यसको प्रबन्धन आफैं दिने इरादा भएमा मात्र इन्जिन मात्र छान्नुहोस्।