नयाँ 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 संस्करणमा चलाउनुहोस्, भर्चुअल मेसिनमा यदि तपाईंको वर्कस्टेशन अगाडि बढिसकेको छ। यसले डेस्कटप सुरक्षित राख्छ र पुरानो निर्भरता त्यस्तो सीमाभित्र राख्छ जुन तपाईं फेरि बनाउन सक्नुहुन्छ।