VPN પોર્ટલ ઇન્સ્ટોલર: પેકેજ, પ્રોફાઇલ કે પુનર્નિર્માણ?

VPN પોર્ટલનું ડાઉનલોડ બટન બરાબર એક ફાઇલ પરત કરે છે, અને તે ફાઇલ બે તદ્દન અલગ વસ્તુઓ હોઈ શકે છે: સાથે મુસાફરી કરતી કન્ફિગરેશન પ્રોફાઇલ સાથે વેન્ડરનું તૈયાર ઇન્સ્ટોલર, અથવા સંસ્થાએ પોતે જ કમ્પાઇલ કરેલું બિલ્ડ. પૃષ્ઠ બંને કિસ્સામાં સરખું દેખાય છે, તેથી બટન તમને કહી શકતું નથી કે તમારી પાસે કયું છે. તેની પાછળ ત્રણ પ્રશ્નો છે — એક્ઝિક્યુટેબલ કોણે પ્રકાશિત કર્યું, ઇન્સ્ટોલ કઈ કન્ફિગરેશન લખે છે, અને આગલી ક્લાયન્ટ આવૃત્તિ આવે ત્યારે તેને કોણ સુધારે છે. પ્રથમનો જવાબ તમે આર્ટિફેક્ટના મેટાડેટામાંથી આપો છો, બીજાનો પેકેજની સામગ્રીમાંથી, અને ત્રીજાનો ફક્ત તે જ ટીમમાંથી જે રોલઆઉટની માલિક છે.

બ્રાઉઝરનું તાળું ટ્રાન્સફરને આવરે છે, આર્ટિફેક્ટને નહીં.

ડાઉનલોડ એન્ડપોઇન્ટ ખરેખર શું પરત કરે છે

મોટાભાગના પોર્ટલ ડાઉનલોડ વિનંતીને એક નાના હેન્ડલરને સોંપે છે, જે સંગ્રહિત ફાઇલને સ્ટ્રીમ કરે છે અથવા તત્ક્ષણ ફાઇલ જોડે છે, પછી પ્રતિસાદ નીકળતા પહેલાં ફાઇલનું નામ અને કન્ટેન્ટ પ્રકાર સેટ કરે છે. જે આવે છે તે કન્ટેનર છે: MSI, PKG, DEB અથવા RPM, અથવા તેમાંથી એકની આસપાસનું સ્વ-કાઢી નાખતું આવરણ. અંદર ક્લાયન્ટનું બાઇનરી હોય છે, અને ફાઇલના નામમાં કંઈ પણ વિશ્વસનીય રીતે કહેતું નથી કે તે બાઇનરી વેન્ડર તરફથી આવ્યું છે કે આંતરિક બિલ્ડ પાઇપલાઇનમાંથી. client-setup.exe નામની ફાઇલ નામકરણનો નિર્ણય નોંધે છે, મૂળની હકીકત નહીં.

ડાઉનલોડ કરેલા બાઇટ્સને વેન્ડરની પ્રકાશિત ચેકસમ સાથે સરખાવો. અસંગતિ દુર્ભાવના સાબિત કરતી નથી; તે સાબિત કરે છે કે ફાઇલ વેન્ડરનું બિલ્ડ નથી, અને તે જ તે ભેદ છે જેના પર કાર્ય કરવા યોગ્ય છે.

પ્રોફાઇલ ક્લાયન્ટમાં ક્યાં પ્રવેશે છે

પૂર્વ-ભરેલી સેટિંગ્સ સામાન્ય રીતે અલગ ફાઇલ તરીકે મુસાફરી કરે છે, જે ઇન્સ્ટોલર દરેક વપરાશકર્તા કે દરેક મશીનના પાથમાં કૉપિ કરે છે: Windows પર JSON કે XML પ્રોફાઇલ, macOS પર કન્ફિગરેશન પ્રોફાઇલ, નીચે એક ટુકડો /etc Linux પર. તે ફાઇલનાં મૂલ્યો — ગેટવે હોસ્ટનામ, ટ્રસ્ટ એન્કર, ક્યારેક નોંધણી સામગ્રી — પ્રથમ લોન્ચ પર ક્લાયન્ટનાં ડિફોલ્ટ બની જાય છે. તેથી જ એક ડાઉનલોડ કોડની સાથે રહસ્યો પણ લઈ જઈ શકે છે.

પૂછો કે અપગ્રેડ પાથ પ્રોફાઇલ સાથે શું કરે છે. પેકેજિંગ પ્રમાણે તે ક્લાયન્ટ અપડેટમાં ટકી શકે, તેનાથી ઓવરરાઇટ થઈ શકે, અથવા નવી આવૃત્તિમાં સ્કીમા માન્યતામાં નિષ્ફળ જઈ શકે.

સહીની સાંકળ શું સાબિત કરતી નથી

કોડ સાઇનિંગ પ્રકાશકની ઓળખને ફાઇલ હેશ સાથે બાંધે છે, અને 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

ફક્ત સ્થિતિ શબ્દ નહીં, સહી કરનારનો વિષય વાંચો. આંતરિક પ્રમાણપત્ર સત્તાધિકારી દ્વારા આંતરિક બિલ્ડ પર સહી કરવી અપેક્ષિત છે; વેન્ડરની આવૃત્તિ હોવાનો દાવો કરતા પેકેજ પર એ જ પ્રમાણપત્ર અપેક્ષિત નથી.

ફક્ત પ્રોફાઇલવાળા પેકેજ માટે, આર્કાઇવ ખોલો અને દરેક એમ્બેડ કરેલા હોસ્ટનામ અને કીને એવા ડેટા તરીકે ગણો જેનો હિસાબ આપવો પડે. જો પ્રોફાઇલમાં ફરી વાપરી શકાય તેવું કંઈ હોય, તો પોર્ટલ વિતરણ તેને રોલઆઉટ સમયપત્રક સાથેનું વહેંચાયેલું રહસ્ય બનાવે છે.

રોલઆઉટ પહેલાં માલિકી નક્કી કરવી

છેલ્લા પ્રશ્ન પાછળ કોઈ આદેશ નથી. વેન્ડર નવો ક્લાયન્ટ મોકલે ત્યારે આર્ટિફેક્ટ કોણ અપડેટ કરે છે, આંતરિક બિલ્ડ માટે સહીની કી કોઈ પાસે છે, અને એન્ડપોઇન્ટ ખસે ત્યારે પ્રોફાઇલ કેવી રીતે ફેરવાય છે તે શોધો. તે નામો ડાઉનલોડ લિંકની બાજુમાં લખો.

જો કોઈ તે જવાબનો માલિક ન હોય, તો ડાઉનલોડ જાળવણી કરાર વગરની વિતરણ કેનાલ છે, અને તે જ એવી શોધ છે જેની જાણ કરવા યોગ્ય છે.