نصب‌کننده پورتال VPN: بسته، پروفایل یا بازسازی؟

دکمه دانلود یک پورتال VPN دقیقاً یک فایل برمی‌گرداند، و آن فایل می‌تواند دو چیز بسیار متفاوت باشد: نصب‌کننده آماده فروشنده همراه با یک پروفایل پیکربندی که کنارش سفر می‌کند، یا ساختی که سازمان خودش کامپایل کرده است. صفحه در هر دو حالت یکسان به نظر می‌رسد، پس دکمه نمی‌تواند بگوید کدام را دارید. پشت آن سه پرسش است — چه کسی فایل اجرایی را منتشر کرده، نصب چه پیکربندی‌ای می‌نویسد، و چه کسی آن را وقتی نسخه بعدی کلاینت می‌رسد تعمیر می‌کند. پرسش اول را از فراداده‌های مصنوع، دوم را از محتوای بسته و سوم را فقط از تیمی که مالک استقرار است پاسخ می‌دهید.

قفل مرورگر انتقال را پوشش می‌دهد، نه مصنوع را.

نقطه پایانی دانلود در واقع چه چیزی برمی‌گرداند

بیشتر پورتال‌ها درخواست دانلود را به یک راه‌انداز کوچک می‌سپارند که یا فایل ذخیره‌شده را جریان می‌دهد یا فایلی را همان‌جا می‌سازد، و سپس پیش از خروج پاسخ، نام فایل و نوع محتوا را تعیین می‌کند. آنچه می‌رسد یک ظرف است: MSI، PKG، DEB یا RPM، یا یک پوشش خوداستخراجی پیرامون یکی از آن‌ها. درون آن فایل دودویی کلاینت است و هیچ چیز در نام فایل به‌طور قابل اعتماد نمی‌گوید که آن دودویی از فروشنده آمده یا از خط ساخت داخلی. فایلی به نام client-setup.exe یک تصمیم نام‌گذاری را ثبت می‌کند، نه یک واقعیت منشأ.

بایت‌های دانلودشده را با چک‌سام منتشرشده فروشنده مقایسه کنید. عدم تطابق سوءنیت را اثبات نمی‌کند؛ اثبات می‌کند فایل ساخت فروشنده نیست، و این همان تمایزی است که ارزش اقدام دارد.

پروفایل کجا به کلاینت وارد می‌شود

تنظیمات از پیش پر شده معمولاً به صورت فایلی جداگانه سفر می‌کنند که نصب‌کننده آن را در مسیری برای هر کاربر یا هر ماشین کپی می‌کند: یک پروفایل JSON یا XML در Windows، یک پروفایل پیکربندی در macOS، یک قطعه زیر /etc در Linux. مقادیر آن فایل — نام میزبان‌های دروازه، لنگرهای اعتماد، گاهی مواد ثبت‌نام — در اولین اجرا به پیش‌فرض‌های کلاینت تبدیل می‌شوند. به همین دلیل یک دانلود می‌تواند هم رمز و هم کد را حمل کند.

بپرسید مسیر ارتقا با پروفایل چه می‌کند. بسته به بسته‌بندی، ممکن است از به‌روزرسانی کلاینت جان سالم به در ببرد، توسط آن بازنویسی شود، یا در نسخه جدید در اعتبارسنجی طرح شکست بخورد.

زنجیره امضا چه چیزی را اثبات نمی‌کند

امضای کد هویت ناشر را به هش فایل پیوند می‌دهد، و در Windows مهر زمانی Authenticode به امضا اجازه می‌دهد بیشتر از گواهی‌ای که آن را ساخته زنده بماند. نتیجه معتبر به دو پرسش پاسخ می‌دهد: کدام ناشر این بایت‌ها را امضا کرده و آیا پس از آن تغییر کرده‌اند. این نتیجه سرویس‌های نصب‌کننده، نوشته‌های رجیستری یا درایورهای همراه را برنمی‌شمارد، و تصمیم نمی‌گیرد که آیا باید به آن ناشر اینجا اعتماد کرد. مستندات 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

موضوع امضاکننده را بخوانید، نه فقط واژه وضعیت را. اینکه یک مرجع گواهی داخلی ساختی درون‌سازمانی را امضا کند انتظار می‌رود؛ همان گواهی روی بسته‌ای که ادعا می‌کند انتشار فروشنده است، انتظار نمی‌رود.

برای بسته‌ای فقط با پروفایل، آرشیو را باز کنید و هر نام میزبان و کلید جاسازی‌شده را داده‌ای بدانید که باید حساب شود. اگر پروفایل چیزی قابل استفاده مجدد داشته باشد، توزیع از طریق پورتال آن را به رازی مشترک با برنامه استقرار تبدیل می‌کند.

تعیین مالکیت پیش از استقرار

پرسش آخر هیچ فرمانی پشتش ندارد. پیدا کنید چه کسی مصنوع را وقتی فروشنده کلاینت جدیدی می‌فرستد به‌روز می‌کند، چه کسی کلید امضای ساخت داخلی را نگه می‌دارد، و پروفایل وقتی نقطه پایانی جابه‌جا می‌شود چگونه چرخانده می‌شود. آن نام‌ها را کنار پیوند دانلود بنویسید.

اگر هیچ‌کس مالک آن پاسخ نیست، دانلود کانالی توزیع بدون قرارداد نگهداری است، و این همان یافته‌ای است که ارزش گزارش دارد.