هیچ چیز در OpenVPN الزام نمی‌کند که گواهی از Easy-RSA بیاید، و ناوگانی که از قبل یک PKI سازمانی دارد معمولاً نباید دومی بسازد. کار واقعی انتخاب ابزار نیست، بلکه تصمیم‌گیری درباره معنای هویت‌های صادرشده، اینکه تونل کدام همتایان را می‌پذیرد، و اینکه تمدید و ابطال چگونه به تأییدکننده می‌رسند است. پنج گام زیر را به ترتیب طی کنید، زیرا گام بعدی نمی‌تواند تصمیم نقشی را که در گام اول گرفته شده ترمیم کند.

به جای یک هویت مشترک، دو نقش صادر کنید

هر همتا به گواهی خودش و کلید خصوصی متناظر نیاز دارد. از تیم PKI یک هویت سرور با کاربرد سرور و هویت‌های مشتری جداگانه با کاربرد مشتری بخواهید تا تونل هنگام دست‌دهی بتواند آن دو را از هم تشخیص دهد.

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

ورودی‌های اعتماد را در هر طرف وصل کنید

مشتری و سرور هر یک به لنگر اعتماد، هویت خودشان و انتظار نقش صریح نیاز دارند. قطعه‌ای از مشتری که هر سه را بیان کند چنین است.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

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

گواهی‌های میانی را بدون گسترش اعتماد تحویل دهید

دو طرف لازم نیست یک زنجیره صدور را شریک باشند. وقتی همتایی گواهی امضاشده توسط یک میانی را ارائه می‌دهد، طرف تأییدکننده به آن میانی در دسترس نیاز دارد، و OpenVPN ورودی لنگر اعتماد را از گواهی‌های اضافی که برای کامل‌کردن زنجیره ارائه‌شده محلی به کار می‌روند متمایز می‌کند. مرجع گزینه‌های TLS در OpenVPN 2.6 هر دو را مستند می‌کند.

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

با تیم PKI توافق کنید که تمدید و ابطال چگونه به تأییدکنندگان VPN می‌رسند، از جمله اینکه کدام صادرکننده‌ها اهمیت دارند و چه کسی فهرست را منتشر می‌کند. نقطه توزیع CRL جاسازی‌شده در یک گواهی یک دستور است، نه شاهدی بر اینکه چیزی آن را واکشی کرده است.

تصمیم بگیرید ابطال واقعاً چگونه می‌رسد

crl-verify تأییدکننده را وادار می‌کند به یک فایل یا نقطه پایانی مراجعه کند، و این ترتیب به یک مالک و مسیر تازه‌سازی نیاز دارد. فهرستی که هنگام استقرار یک بار کپی می‌شود، نخستین بار که گواهی‌ای ابطال شود بی‌صدا از محافظت از شما دست می‌کشد.

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

پذیرش را با یک مشتری واقعی ثابت کنید

مشتری‌ای را که باید مجاز باشد وصل کنید و جزئیات گواهی مذاکره‌شده را در گزارش تأیید کنید. سپس مواردی را که باید شکست بخورند امتحان کنید: گواهی مشتری که به‌عنوان سرور ارائه شود، گواهی از صادرکننده‌ای بیرون از لنگر اعتماد، و گواهی ابطال‌شده اگر یکی اضافه دارید.

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

مقالات مرتبط