नए Ubuntu पर GlobalProtect का Linux क्लाइंट क्यों विफल होता है

उचित अनुमान यह है कि आपके GlobalProtect पोर्टल से मिला .deb टूटा हुआ है, या विक्रेता ने खराब बिल्ड जारी किया है। सामान्यतः ऐसा नहीं होता। विक्रेता का Linux इंटरफ़ेस अब भी Qt5 WebKit से जुड़ा है, और नए Ubuntu संस्करण उसे अब नहीं देते, इसलिए पैकेज ऐसी लाइब्रेरी माँग रहा है जिसे आपके वितरण ने जानबूझकर हटा दिया। यह पैकेजिंग की बेमेल है, खराब डाउनलोड नहीं, और यही अंतर तय करता है कि आप दोपहर पैकेज थोपने में बिताएँगे या दस मिनट दूसरा क्लाइंट चुनने में।

.deb टूटा नहीं है

जिस निर्भरता को वितरण अब नहीं रखता, वह लाइब्रेरी के रिटायर होने का सामान्य परिणाम है। Qt5 WebKit को बाद के Ubuntu अभिलेखागारों और Debian से हटा दिया गया, और कारण माँग की कमी नहीं बल्कि सुरक्षा रखरखाव था। जब ऐसा होता है, तो हर वह पैकेज जो अब भी उससे जुड़ा है, स्थापित नहीं हो सकता, चाहे वह कितना अच्छा बना हो।

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

निर्भरता को थोपने के बजाय उसकी पुष्टि करें

पैकेज को स्पष्ट रूप से स्थापित करें ताकि टूल अनसुलझी निर्भरता का नाम बताए, आपको सारांश न दे। फिर पूछें कि क्या आपके संस्करण में कोई उम्मीदवार है भी, क्योंकि „यहाँ उपलब्ध नहीं” और „इस मिरर से अस्थायी रूप से अनुपस्थित” पूरी तरह अलग निर्णयों की ओर ले जाते हैं:

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

अगर apt-cache policy कोई उम्मीदवार नहीं बताता, तो उसे स्थापित करने का प्रयास छोड़ें और विकल्प चुनना शुरू करें। दिलचस्प बात अनुपस्थित पैकेज का नाम नहीं है; दिलचस्प बात यह है कि विक्रेता का निर्भरता ग्राफ़ उन वितरणों के साथ नहीं बढ़ा जो आपके उपयोगकर्ता चलाते हैं।

पुराने पैकेज थोपना डेस्कटॉप के साथ क्या करता है

जो समाधान घूम रहा है वह यह है कि लाइब्रेरी किसी पुराने संस्करण से खींच ली जाए। मौजूदा Ubuntu पर यह Qt5 के माइनर संस्करण के टकराव पर जाकर रुकता है: पुराने पैकेज libqt5core5t64 को पीछे खींचते हैं, और फिर स्थापित KDE और PyQt पैकेज ऐसा ABI संस्करण माँगने लगते हैं जो घटाई गई लाइब्रेरी अब नहीं देती। परिणाम एक आंशिक अपग्रेड है जो असंबंधित अनुप्रयोगों को तोड़ देता है, और यह उस दोपहर से कहीं बुरा है जिससे आपने शुरू किया।

यह परिणाम अपेक्षित है, दुर्भाग्य नहीं। Qt की माइनर संस्करणों के लिए ABI अपेक्षाएँ कड़ी हैं, और एक वितरण एक सुसंगत समुच्चय देता है। दूसरे संस्करण से एक लाइब्रेरी मिलाना कोई लक्षित सुधार नहीं; यह दूसरा, कम नियंत्रित अपग्रेड है।

यही सलाह विफलता के रनटाइम संस्करण पर भी लागू है। पुराने क्लाइंट का हैंडशेक सफल कराने के लिए OpenSSL का सिस्टम-व्यापी सुरक्षा स्तर घटाना एक अनुप्रयोग ठीक करने के लिए मशीन पर हर TLS कनेक्शन बदल देता है, जिसमें वह पैकेज मैनेजर भी शामिल है जिसकी आपको ज़रूरत होगी जब कुछ और टूटेगा।

openconnect यह प्रोटोकॉल बोलता है

OpenConnect GlobalProtect का प्रोटोकॉल सीधे लागू करता है, और प्रोटोकॉल नोट्स दोनों आह्वान और दोनों सर्वर इंटरफ़ेस के बीच विभाजन का वर्णन करते हैं। पोर्टल सेटिंग्स और गेटवे सूची बाँटता है; गेटवे टनल समाप्त करता है:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

अगर पोर्टल वह गेटवे शामिल न करे जिसकी आपको ज़रूरत है, --usergroup=gateway या ऐसा URL जो /gateway पर समाप्त होता है, पोर्टल चरण छोड़ देता है। जब कई गेटवे दिए जाते हैं, --authgroup=NAME उनमें से चुनता है। प्रमाणीकरण उपयोगकर्ता नाम और पासवर्ड है, वैकल्पिक रूप से क्लाइंट प्रमाणपत्र के साथ, और SAML गेटवे व्यवहार में network-manager-openconnect के ज़रिए काम करते हैं, हाथ से लिखी कमांड लाइन के बजाय।

सख्त posture नीति वाला गेटवे टनल देने से पहले HIP रिपोर्ट भी माँग सकता है। OpenConnect एक बना और भेज सकता है, लेकिन अगर गेटवे ऐसी सूची माँगे जो वह नहीं बना सकता, तो कोई फ्लैग वह नीति नहीं बदलता; यह सर्वर पक्ष का निर्णय है।

टनल की पुष्टि करें, और जानें कि openconnect क्या ठीक नहीं करेगा

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

ip -4 addr show
ip route
resolvectl status

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

IPv6 फिर अलग मामला है। PAN ने इसे GlobalProtect 4.0 में जोड़ा, और OpenConnect का समर्थन संस्करण 9.0 से प्रयोगात्मक बताया जाता है, इसलिए यह न मानें कि पता परिवार IPv4 जैसा व्यवहार करता है केवल इसलिए कि टनल ऊपर आ गया। और अगर गेटवे ऐसा posture जाँच थोपे जिसे ओपन सोर्स क्लाइंट पूरा नहीं कर सकता, तो विक्रेता का क्लाइंट समर्थित LTS संस्करण पर चलाएँ, वर्चुअल मशीन में अगर आपका वर्कस्टेशन आगे बढ़ चुका है। यह डेस्कटॉप को सुरक्षित रखता है और पुरानी निर्भरता को ऐसी सीमा के भीतर रखता है जिसे आप फिर से बना सकते हैं।