OpenConnect csd-wrapper: लगइन अघि स्क्रिप्टको अडिट गर्नुहोस्

प्रोफाइलमा --csd-wrapper थप्दा स्थानीय स्क्रिप्ट लगइनको समयमा चलाउने डेमनलाई दिइन्छ, त्यसैले तपाईंको अगाडिको निर्णय कोड समीक्षा हो, प्राथमिकता टगल होइन। यो विकल्प गेटवेको होस्ट-जाँच घटक प्रतिस्थापन गर्न सकियोस् भनेर छ, र यसले तपाईंले दिनुभएको स्क्रिप्टको बाटो लिन्छ। तलका सबै कुरा परिनियोजनको मालिकले कुन पोस्चर जाँच आवश्यक छ भनी पहिले नै भनिसकेको मान्छन्; यदि त्यो भाग अझै खुला छ भने पहिले त्यसलाई टुंग्याउनुहोस्। निर्देशिकामा चार चरण छन्: असफल भएको चरण पत्ता लगाउनुहोस्, स्क्रिप्ट पढ्नुहोस्, यो कुन पहिचानमा चल्छ छान्नुहोस्, र नतिजा प्रमाणित गर्नुहोस्।

चरण 1: असफल भएको चरण पत्ता लगाउनुहोस्

क्लाइन्टको अन्तिम सन्देश सामान्यतया कुकीबारे हुन्छ, जुन श्रृंखलाको अन्त्य हो, सुरुवात होइन। HTTPS लगइन, सर्भर प्रमाणपत्र जाँच, प्रमाणीकरण आदानप्रदान र पोस्चर घटक सबै त्यो सन्देशअघि बस्छन्।

प्रयोग भइरहेको संस्करण र लगइन ठेगाना टिप्नुहोस्, त्यसपछि विस्तृत आउटपुट आफ्नै टर्मिनलमा राखेर प्रयास दोहोर्याउनुहोस्। पुनः प्रयास नभएको पहिलो त्रुटि पढ्नुहोस्, ट्रान्स्क्रिप्टको अन्तिम लाइन होइन। यदि लग कुनै मूल्याङ्कन घटकको नाम आउनुअघि नै रोकिन्छ भने, तब र्यापर अझै तपाईंको समस्या होइन। त्यो बिन्दुमा थप्दा पछि तपाईंले रक्षा गर्नुपर्ने सतह मात्र फराकिलो हुन्छ।

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

ट्रान्स्क्रिप्ट स्थानीय राख्नुहोस्, किनकि कुकी र प्रमाणीकरण प्रतिक्रियाहरू पहुँच सामग्री हुन्। च्याट थ्रेडमा टाँसिएको ट्रेस प्रमाण-पत्र चुहावट हो, मूल्याङ्कन चरण हानिरहित देखिए पनि। त्रुटिको पाठ र प्रवाहमा यो देखा परेको बिन्दु साझा गर्नुहोस्, पेलोड कहिल्यै होइन।

चरण 2: स्क्रिप्ट प्रोफाइलमा पस्नुअघि पढ्नुहोस्

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

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

पूरै फाइल चार प्रश्न मनमा राखेर पढ्नुहोस्: यसले बाहिर जाने HTTP कल गर्छ कि, प्रमाण-पत्र फाइल वा वातावरण चर पढ्छ कि, अस्थायी डाइरेक्टरीबाहिर लेख्छ कि, र कुनै शाखाले केही ननापी उत्तीर्ण पोस्चर रिपोर्ट गर्छ कि। त्यो अन्तिम ढाँचा लग लाइन जोडिएको नीति बाइपास हो। प्रतिलिपि गरिएका र्यापरहरूले यसलाई विश्वसनीय देखिने जाँचको पछाडि लुकाउँछन्। यदि स्क्रिप्टले यन्त्रलाई हेर्नुअघि नै यन्त्र ठीक छ भन्ने निर्णय गर्छ भने त्यहीँ रोक्नुहोस्।

प्याक गरिएका पेलोड पनि जाँच्नुहोस्, किनकि पढ्न सकिने हेडरले फाइलको बाँकी भागबारे केही प्रमाणित गर्दैन। फोरम थ्रेडबाट स्क्रिप्ट डाउनलोड गर्दा त्यो भरपर्दो हुँदैन, केवल यसको नाम वास्तविक होस्ट-जाँच घटकसँग मिल्ने भएर मात्र। कसले स्थापना गर्यो, कहाँबाट आयो र कसरी अद्यावधिक हुनेछ टिप्नुहोस्।

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

चरण 3: र्यापर कुन पहिचानमा चल्छ छान्नुहोस्

--csd-user ले CSD, TNCC वा HIP कार्यक्रम चल्ने समयमा विशेषाधिकार घटाउँछ। त्यो खाता स्थानीय कार्यान्वयन व्यवस्थाको भाग हो, गेटवेमा पेस गरिएको प्रयोगकर्ता नाम होइन।

र्यापरलाई अन्तरक्रियात्मक शेल नभएको, sudo अधिकार नभएको र आवश्यक नपर्ने समूह सदस्यता नभएको समर्पित खाता दिनुहोस्। स्क्रिप्ट र यसले जाँच्ने विशिष्ट फाइलहरूमा पढ्ने पहुँच दिनुहोस्, त्यसपछि VPN प्रोफाइल छुनुअघि विशेषाधिकार घटाउने परीक्षण गर्नुहोस्। समस्या यहाँ खोज्नु क्लाइन्टभित्र खोज्नुभन्दा सस्तो हुन्छ।

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

विशेषाधिकार घटाउँदा खराब स्क्रिप्टले पुर्याउन सक्ने हानि सीमित हुन्छ। तर यसले कोड समीक्षा गर्दैन, प्रतिवेदन सत्य बनाउँदैन, वा गेटवे प्रशासकले यो कार्यान्वयनलाई यन्त्र नीति पूरा गरेको रूपमा स्वीकार्छ भनी स्थापित गर्दैन।

चरण 4: परिवर्तनलाई उल्टाउन सकिने राख्नुहोस्

प्रोफाइल सम्पादन गर्नुअघि ब्याकअप लिनुहोस्, र र्यापरलाई संस्करण नियन्त्रणमा राख्नुहोस् ताकि रोलब्याकले प्रतिलिपि खोज्नुको सट्टा ज्ञात ह्यास पुनर्स्थापित गरोस्। स्क्रिप्टको बाटो, ह्यास, कार्यान्वयन प्रयोगकर्ता र स्वीकृत गर्ने व्यक्ति एउटै ठाउँमा लेख्नुहोस्।

उल्टाउन विकल्प हटाउनुहोस्, क्लाइन्ट पुनः सुरु गर्नुहोस् र मूल त्रुटि फर्किएको पुष्टि गर्नुहोस्। रोलब्याकपछि पनि गेटवेले लगइन अस्वीकार गर्छ भने अरू केही पनि बदलिएको छ, र त्यो भिन्नता खोज्नु र्यापर फेरि प्रयास गर्नुअघि आउँछ। परिवर्तन विन्डोभरि अघिल्लो प्रतिलिपि राख्नुहोस्, जुन धेरै टोलीका लागि अर्को मर्मत विन्डो सकिएसम्म भन्ने अर्थ हुन्छ।

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

दोस्रो समस्या सिर्जना गर्ने सर्टकटहरू

आवश्यक जाँच नचलाई सहायकलाई अनुरूप स्थिति रिपोर्ट गर्न नदिनुहोस्, र अर्को अपरेटिङ सिस्टमसँग मिलाउन प्लेटफर्म पहिचान ओभरराइड नगर्नुहोस्। फरक प्लेटफर्म दाबी गर्नु वास्तविक यन्त्रले नीति पूरा गर्छ भन्ने प्रमाण होइन। यसले तपाईंलाई प्रत्येक भावी लगइनमा झुट बोल्ने क्लाइन्टसँग छोड्छ।

सर्भर प्रमाणीकरण बन्द गर्नु, पुरानो कुकी पुनः चलाउनु र नसमीक्षा गरिएका स्क्रिप्टहरू थुपार्नु — यी सबै देखिने असफलतालाई नदेखिने असफलतासँग बदल्छन्। यदि स्थापित क्लाइन्टले समर्थित प्रवाह पूरा गर्न सक्दैन भने आफ्नो भएको प्रवाह मोड्नुको सट्टा स्वीकृत विकल्प माग्नुहोस्।

OpenConnect म्यानुअल --csd-wrapper र --csd-user लाई छुट्टाछुट्टै कागजात गर्छ, र यही महत्त्वपूर्ण संकेत हो: स्क्रिप्ट र पहिचान दुई निर्णय हुन्। तिनीहरूलाई छुट्टाछुट्टै समीक्षा गर्नुहोस् र दुवै लेख्नुहोस्। त्यसपछि लगइन प्रम्प्ट कोड टाँसेर समाधान गर्ने पहेली रहँदैन।