کلید خصوصی VPN کجا باید زندگی کند: فایل، CNG یا TPM؟
بین فایل کلید، مخزن نرمافزاری غیرقابلصدور و TPM برای هویت VPN یکی را انتخاب کنید، سپس انتخاب را با فرمانها و طرح بازگشت اثبات کنید.
دو پرسش تعیین میکند کلید خصوصی VPN کجا تعلق دارد: آیا میتوان ماده کلید را از میزبان کپی کرد، و آیا یک فرایند میتواند آن را بدون حضور کسی پشت صفحهکلید به کار ببرد. برچسب بازاریابی یک مخزن به هیچکدام پاسخ نمیدهد. دیمن تونلی که باید پس از راهاندازی دوباره برگردد به استفاده بینظارت نیاز دارد، و این هر چیزی را که به PIN تایپشده توسط انسان وابسته باشد کنار میگذارد.
میان کپی و استفاده انتخاب کنید
کپی و استفاده به شکلهای متفاوت شکست میخورند، پس آنها را دو نیاز نه یک نیاز بدانید. مهاجمی که میتواند بایتهای کلید را بخواند هویت را به میزبان دیگری میبرد و ماشین اصلی متوجه نمیشود. مهاجمی که نمیتواند بایتها را بخواند اما به فرایند امضا میرسد تا وقتی آن دسترسی ادامه دارد همچنان احراز هویت میکند.
کلید فایلی بهسادگی کپی میشود، و به همین دلیل آسانترین برای پشتیبانگیری و بازیابی است. مخزن کلید نرمافزاری API را عوض میکند نه مرز را: ارائهدهنده فراخوانیهای صادرات خودش را رد میکند، اما همان بستر مدیر که کلید را نصب کرده معمولاً مسیرهای دیگری به ماده دارد. غیرقابلصدور بودن نزد ارائهدهنده نرمافزاری بیانیهای درباره عملیات پشتیبانیشده است، نه اثبات دیوار سختافزاری. آن را سد راهی در برابر کپی اتفاقی بدانید، نه محافظت در برابر کسی که از قبل نشست شما را دارد.
TPM یا کارت هوشمند عملیات امضا را داخل سختافزار اجرا میکند و فقط نتیجه را برمیگرداند. این مسیر کپی را میبندد و مسیر استفاده را برای هر چیزی که بتواند امضا بخواهد باز میگذارد.
مخزن را با دیمن تونل هماهنگ کنید
دیمن این را بیش از سیاست امنیتی محدود میکند. WireGuard کلید خصوصی base64 را از فایل یا ورودی wg set میگیرد و مسیری به مخزن گواهی ندارد، پس کلید رابط مبتنی بر TPM مطرح نیست. OpenVPN ساختهشده در برابر OpenSSL 3 میتواند کلید را از طریق URI ارائهدهنده بارگذاری کند، و strongSwan افزونه TPM را در کنار پشتیبانی PKCS#11 عرضه میکند، اما هر دو به نحوه کامپایل بسته شما بستگی دارند.
دیمنی که به مخزن انتخابشده نمیرسد مرز سختافزاری را به تزیین تبدیل میکند. کسی کلید را یک بار صادر میکند، آن را در فایلی رها میکند و بقیه طرح بیصدا روی همان کپی اجرا میشود.
تمدید نیمه دیگر تطبیق است و همانجاست که بیشتر طرحها از هم میپاشند. مخزنی که در نخستین ثبت کار میکند اما برای هر بازصدور ورود به کنسول میخواهد، نخستین بار که گواهی در ساعتی نامناسب منقضی شود دور زده میشود. مسیر بازصدور را وقتی کلید فعلی هنوز ماهها دارد آزمایش کنید.
پیش از جابهجایی کلید را سیاهه کنید
پیش از تغییر جای زندگیاش ثبت کنید کلید چیست، زیرا مهاجرتی که subject alternative names را از دست بدهد تونل را به گونهای میشکند که مانند خطای مسیریابی خوانده میشود. گواهی را تخلیه کنید، تأیید کنید کلید خصوصی همانجا که دیمن انتظار دارد خواناست و بررسی کنید جفت واقعاً تطبیق دارد.
openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256
دو خلاصه آخر باید یکسان باشند. اگر نیستند، دیمن نصب را تمام میکند و سپس در هر تلاش با خطای گواهی یا امضا شکست میخورد که هیچجا نزدیک علت واقعی را نشان نمیدهد. معادل WireGuard کوتاهتر است، چون کلید عمومی مستقیماً از خصوصی مشتق میشود: wg pubkey < /etc/wireguard/wg0.key باید کلید همتایی را چاپ کند که سرور شما از قبل ذخیره دارد.
مجوزها به همان سیاهه تعلق دارند. stat -c '%a %U:%G' /etc/wireguard/wg0.key باید 600 root:root برگرداند، و هر چیزی که برای گروه یا جهان خواناست یعنی کلید از قبل در دسترس فرایندهایی بوده که هرگز در نظر نداشتید.
مخزن و مسیر استفاده را بررسی کنید
راستیآزمایی سه بخش دارد و بخش سوم همان است که از قلم میافتد. تأیید کنید کلید در مخزن انتخابی وجود دارد، تأیید کنید دیمن همان کلید را بارگذاری کرده نه کپی باقیمانده، و سپس تأیید کنید که هنوز وقتی اثر صادرات رفته شروع میشود.
certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts
در Windows فرمان نخست مخزن شخصی را فهرست میکند و کنار هر ورودی ارائهدهنده کلید را چاپ میکند، و همانجاست که گواهیای که سختافزاری به نظر میرسد اما در ارائهدهنده نرمافزاری نشسته ظاهر میشود. دومی کلیدهای تحت اختیار ارائهدهنده رمزنگاری سکو را فهرست میکند، پس هویت VPNی که آنجا غایب است در حالی که گواهیاش حاضر است یعنی نیمه خصوصی جای دیگری زندگی میکند. روی دروازه Linux، ipsec listcerts گزارش میدهد strongSwan چه بارگذاری کرده، از جمله کلیدهای آمده از افزونه TPM. اثر انگشت یا هش کلید عمومی را با سیاهه مقایسه کنید نه با تعداد ورودیها.
آزمون منفی همان است که طرح را اثبات میکند. کلید صادرشده را از پوشه پیکربندی دیمن بیرون ببرید، سرویس را دوباره راه بیندازید و در گزارش بخوانید چه هویتی ارائه میکند. تونلی که باز هم بالا میآید از مخزن استفاده میکند؛ راهاندازی ناموفق یعنی طرح واقعاً روی یک کپی اجرا میشده.
تمدید و بازگشت را بنویسید
بازگشت میان دو خانواده بهشدت متفاوت است و این تفاوت به یادداشت طراحی تعلق دارد نه به تماس حادثه. کلید فایلی را میتوان رمزگذاریشده پشتیبان گرفت و بازیابی کرد، پس مهاجرت ناموفق برگشتپذیر است. کلید غیرقابلصدور اصلاً پشتیبانگیری نمیشود، و این بازصدور و ثبت دوباره را تنها مسیر بازیابی میکند وقتی دستگاه میمیرد.
انقضا را پیش از آنکه به قطعی تبدیل شود بررسی کنید: openssl x509 -in vpn.crt -noout -checkend 2592000 وقتی گواهی در سی روز منقضی شود با کد غیرصفر پایان مییابد، پس مستقیم در یک بررسی پایش جا میگیرد. اجرای هفتگی آن خط تمدیدی را میگیرد که کسی برنامهریزی نکرده بود.
حذف روی سرور رخ میدهد: همتا را پاک کنید یا شماره سریال را باطل کنید، سپس تأیید کنید تونل شکست میخورد، چون کلاینتی با نشست ذخیرهشده میتواند مدتی ابطال نیمهتمام را پنهان کند. ابطال باید به مسیر CRL یا OCSP متمرکزکننده هم برسد، نه فقط به پایگاه داده CA. گواهی سندی عمومی است و پروفایل RFC 5280 نحوه اعتبارسنجی آن را پوشش میدهد؛ هیچچیز در آن اعتبارسنجی از کلید خصوصی کپیشده پیش از چرخش محافظت نمیکند.
تصمیم را در یک جا بنویسید: کدام مخزن کلید را نگه میدارد، کدام فرایند میتواند استفاده کند، چه کسی میتواند بازصادرش کند و بازگشت چیست. همان بند چیزی است که حسابرسان میپرسند و چیزی که از تغییر کارکنان جان سالم به در میبرد.