VPN पोर्टल इंस्टॉलर: पैकेज, प्रोफ़ाइल या पुनर्निर्माण?

किसी VPN पोर्टल का डाउनलोड बटन ठीक एक फ़ाइल लौटाता है, और वह फ़ाइल दो बहुत अलग चीज़ों में से एक हो सकती है: साथ में चलने वाली कॉन्फ़िगरेशन प्रोफ़ाइल वाला विक्रेता का तैयार इंस्टॉलर, या संगठन द्वारा स्वयं संकलित किया गया बिल्ड। पृष्ठ दोनों स्थितियों में एक जैसा दिखता है, इसलिए बटन आपको नहीं बता सकता कि आपके पास कौन-सा है। इसके पीछे तीन प्रश्न हैं — निष्पादन-योग्य फ़ाइल किसने प्रकाशित की, इंस्टॉल कौन-सा कॉन्फ़िगरेशन लिखता है, और अगली क्लाइंट रिलीज़ आने पर इसे कौन ठीक करता है। पहले का उत्तर आप आर्टिफ़ैक्ट के मेटाडेटा से देते हैं, दूसरे का पैकेज की सामग्री से, और तीसरे का केवल उस टीम से जो परिनियोजन की स्वामी है।

ब्राउज़र का ताला स्थानांतरण को ढकता है, आर्टिफ़ैक्ट को नहीं।

डाउनलोड एंडपॉइंट वास्तव में क्या लौटाता है

अधिकांश पोर्टल डाउनलोड अनुरोध को एक छोटे हैंडलर को सौंपते हैं जो या तो संग्रहीत फ़ाइल को स्ट्रीम करता है या मौके पर फ़ाइल जोड़ता है, फिर प्रतिक्रिया जाने से पहले फ़ाइल नाम और सामग्री प्रकार तय करता है। जो आता है वह एक कंटेनर है: MSI, PKG, DEB या RPM, या उनमें से किसी के चारों ओर स्व-निष्कर्षक आवरण। अंदर क्लाइंट की बाइनरी होती है, और फ़ाइल नाम में कुछ भी विश्वसनीय रूप से नहीं कहता कि वह बाइनरी विक्रेता से आई या आंतरिक बिल्ड पाइपलाइन से। client-setup.exe नाम की फ़ाइल नामकरण का निर्णय दर्ज करती है, मूल का तथ्य नहीं।

डाउनलोड किए गए बाइट्स की तुलना विक्रेता के प्रकाशित चेकसम से करें। बेमेल दुर्भावना साबित नहीं करता; यह साबित करता है कि फ़ाइल विक्रेता का बिल्ड नहीं है, और यही वह भेद है जिस पर कार्रवाई करना उचित है।

प्रोफ़ाइल क्लाइंट में कहाँ प्रवेश करती है

पहले से भरी सेटिंग्स आम तौर पर एक अलग फ़ाइल के रूप में यात्रा करती हैं जिसे इंस्टॉलर प्रति-उपयोगकर्ता या प्रति-मशीन पथ में कॉपी करता है: Windows पर JSON या XML प्रोफ़ाइल, macOS पर कॉन्फ़िगरेशन प्रोफ़ाइल, Linux पर /etc के अंतर्गत एक अंश। उस फ़ाइल में मौजूद मान — गेटवे होस्टनाम, ट्रस्ट एंकर, कभी-कभी नामांकन सामग्री — पहले लॉन्च पर क्लाइंट के डिफ़ॉल्ट बन जाते हैं। इसीलिए एक डाउनलोड कोड के साथ-साथ रहस्य भी ले जा सकता है।

पूछें कि अपग्रेड पथ प्रोफ़ाइल के साथ क्या करता है। पैकेजिंग के आधार पर यह क्लाइंट अपडेट में बच सकती है, उससे अधिलेखित हो सकती है, या नए संस्करण में स्कीमा सत्यापन में विफल हो सकती है।

हस्ताक्षर श्रृंखला क्या साबित नहीं करती

कोड साइनिंग प्रकाशक की पहचान को फ़ाइल हैश से बाँधती है, और Windows पर Authenticode टाइमस्टैम्प हस्ताक्षर को उस प्रमाणपत्र से अधिक जीने देता है जिसने उसे बनाया। वैध परिणाम दो प्रश्नों का उत्तर देता है: किस प्रकाशक ने इन बाइट्स पर हस्ताक्षर किए, और क्या वे बाद में बदले। यह इंस्टॉलर की सेवाओं, रजिस्ट्री लेखन या साथ आए ड्राइवरों की सूची नहीं देता, और यह तय नहीं करता कि उस प्रकाशक पर यहाँ भरोसा किया जाना चाहिए या नहीं। Microsoft का Authenticode दस्तावेज़ इस तंत्र का वर्णन करता है और उस संकीर्ण दायरे के बारे में स्पष्ट है।

पोर्टल प्रमाणीकरण तीसरे प्रश्न का उत्तर देता है: कि सत्र इच्छित सर्वर तक पहुँचा। तीन अलग जाँचें, तीन अलग विफलता विधियाँ।

किसी के चलाने से पहले आर्टिफ़ैक्ट सत्यापित करें

फ़ाइल को अलग-थलग मशीन पर रखें और कुछ भी चलाने से पहले उसका मेटाडेटा पढ़ें। ये कमांड तीन मुख्य प्लेटफ़ॉर्म पर प्रकाशक के प्रश्न का उत्तर देते हैं।

# Windows PowerShell
Get-AuthenticodeSignature .\client-setup.exe | Format-List Status, SignerCertificate, TimeStamperCertificate

# macOS
pkgutil --check-signature ./Client.pkg
codesign -dv --verbose=4 /Applications/Client.app

# Debian/Ubuntu
dpkg-deb -I ./client_amd64.deb
sha256sum ./client_amd64.deb

केवल स्थिति शब्द नहीं, हस्ताक्षरकर्ता का विषय पढ़ें। आंतरिक प्रमाणपत्र प्राधिकरण का आंतरिक बिल्ड पर हस्ताक्षर करना अपेक्षित है; विक्रेता की रिलीज़ होने का दावा करने वाले पैकेज पर वही प्रमाणपत्र अपेक्षित नहीं है।

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

रोलआउट से पहले स्वामित्व तय करना

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

यदि उस उत्तर का कोई स्वामी नहीं है, तो डाउनलोड रखरखाव अनुबंध के बिना वितरण चैनल है, और यही वह निष्कर्ष है जिसकी रिपोर्ट करना उचित है।