VPN पोर्टलको डाउनलोड बटनले ठ्याक्कै एउटा फाइल फर्काउँछ, र त्यो फाइल दुई धेरै फरक कुरा हुन सक्छ: सँगै यात्रा गर्ने कन्फिगरेसन प्रोफाइलसहित विक्रेताको तयार इन्स्टलर, वा संस्थाले आफैं कम्पाइल गरेको बिल्ड। पृष्ठ दुवै अवस्थामा उस्तै देखिन्छ, त्यसैले बटनले तपाईंसँग कुन छ भन्न सक्दैन। यसको पछाडि तीन प्रश्न छन् — executable फाइल कसले प्रकाशित गर्‍यो, इन्स्टलले कुन कन्फिगरेसन लेख्छ, र अर्को क्लाइन्ट रिलिज आउँदा यसलाई कसले मर्मत गर्छ। पहिलोको उत्तर तपाईं आर्टिफ्याक्टको मेटाडेटाबाट, दोस्रोको प्याकेजको सामग्रीबाट, र तेस्रोको परिनियोजनको मालिक टोलीबाट मात्र दिनुहुन्छ।

ब्राउजरको ताला स्थानान्तरण ढाक्छ, आर्टिफ्याक्ट होइन।

डाउनलोड एन्डपोइन्टले वास्तवमा के फर्काउँछ

अधिकांश पोर्टलले डाउनलोड अनुरोध सानो ह्यान्डलरलाई दिन्छन्, जसले या त भण्डारण गरिएको फाइल स्ट्रिम गर्छ या तत्कालै फाइल जोड्छ, त्यसपछि प्रतिक्रिया जानु अघि फाइलको नाम र सामग्री प्रकार तोक्छ। आउने कुरा एउटा कन्टेनर हो: 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

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

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

रोलआउट अघि स्वामित्व निर्धारण

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

यदि त्यो उत्तरको कुनै मालिक छैन भने, डाउनलोड मर्मत सम्झौताविनाको वितरण च्यानल हो, र त्यही रिपोर्ट गर्न योग्य खोज हो।

सम्बन्धित लेखहरू