macOS पर OpenConnect: पैकेज, रिलीज़ आर्काइव या git क्लोन

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

एक ही नाम के नीचे दो अलग मशीनें

पैकेज का रास्ता एक ही कमांड है, और जिनका काम विकास करना नहीं बल्कि कनेक्ट करना है, उनके लिए यह सही डिफ़ॉल्ट है।

brew install openconnect

यह क्या स्थापित करता है, कमांड से अधिक महत्वपूर्ण है। आपको क्लाइंट की बाइनरी मिलती है, और vpnc-script भी मिलती है जिसे क्लाइंट इंटरफ़ेस, रूट और रिज़ॉल्वर को प्रोग्राम करने के लिए बुलाता है। दोनों जोड़ी में काम करते हैं: बाइनरी TLS सत्र समाप्त करती है और परिणामी इंटरफ़ेस स्क्रिप्ट को सौंपती है, और स्क्रिप्ट वह हिस्सा है जो जानता है कि यह ऑपरेटिंग सिस्टम अपना नेटवर्क कैसे बदलना चाहता है।

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

स्रोत का रास्ता असल में क्या करता है

रिलीज़ आर्काइव जनरेट किए गए बिल्ड सिस्टम के साथ आता है, इसलिए परिचित ./configure शुरू से ही मौजूद रहता है। git चेकआउट में नहीं, क्योंकि जनरेट की गई फ़ाइलें बिल्ड उत्पाद हैं, प्रोजेक्ट द्वारा संग्रहीत चीज़ें नहीं। यही पूरा कारण है कि ./autogen.sh चेकआउट के निर्देशों में दिखता है, रिलीज़ आर्काइव में नहीं।

./autogen.sh
./configure
make
make install

हर पंक्ति कुछ विशेष करती है, और यह जानना कि कौन विफल हुई, बहुत अनुमान बचाता है। autogen चरण configure बनाने के लिए autotools चलाता है। configure चरण क्लाइंट के लिए आवश्यक कंपाइलर, लाइब्रेरी और हेडर की जाँच करता है, फिर जो मिला उसे दर्शाने वाली makefile लिखता है। make चरण संकलन करता है। install चरण परिणामों को आपके पाथ में कहीं कॉपी करता है।

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

सत्र और नेटवर्क कॉन्फ़िगरेशन अलग हैं

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

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

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

जानें आप कौन-सी बाइनरी चला रहे हैं

हाथ से स्थापित बिल्ड और पैकेज की गई बाइनरी साथ-साथ शांति से रह सकती हैं, और कौन चलेगी यह आपके पाथ पर निर्भर करता है, आपके इरादों पर नहीं। किसी को संस्करण संख्या बताने से पहले यह पता करें।

which -a openconnect
openconnect --version
brew list --versions openconnect

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

क्लाइंट स्थापित करना गेटवे की मंज़ूरी नहीं है

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

प्रोजेक्ट के बिल्ड निर्देश autotools क्रम और नेटवर्क स्क्रिप्ट की आवश्यकता को अधिक विस्तार से बताते हैं, और उन्हीं का पालन करें, न कि किसी ब्लॉग पोस्ट का जो आपके macOS संस्करण से पुराना है। यदि लक्ष्य केवल कनेक्ट करना है, तो पैकेज लें, स्क्रिप्ट रखें और कंपाइलर को बाहर रखें।