CA مشترک، درهای جداگانه: یک سرویس برای هر پرونده پذیرش
گواهی‌ای که بررسی‌های مرجع مشترک را می‌گذراند بلیت ورود به همه سرویس‌ها نیست. پذیرش باید در پرونده‌ای مخصوص هر سرویس باشد که دیمن می‌خواهد.
گواهی‌ای که در برابر مرجع مشترک اعتبارسنجی می‌شود آزمون اعتماد را گذرانده است، نه آزمون عضویت. این دو تصمیم غالباً با هم یکی می‌شوند چون هر دو در زمان اتصال رخ می‌دهند، و این یکی‌شدن نامرئی می‌ماند تا وقتی کسی که نباید در سرویسی باشد به آن پذیرفته شود. راه‌حل مرجع دوم نیست؛ تصمیم دومی است که برای هر سرویس گرفته می‌شود و همان جایی ثبت می‌شود که دیمن آن را می‌خواند. این دو را جدا نگه دارید تا بیشتر سردرگمی در این زمینه از بین برود.
زنجیره مورد اعتماد درباره عضویت در سرویس چیزی نمی‌گوید
دو سرویس می‌توانند یک سلسله‌مراتب صادرکننده را بپذیرند و در عین حال جمعیت‌های متفاوتی داشته باشند. یک لپ‌تاپ به اولی تعلق دارد و نباید به دومی برسد، در حالی که مشتریان دیگر همان سلسله‌مراتب واقعاً به آنجا تعلق دارند. حذف مرجع از آن سرویس همه کسانی را که به‌طور مشروع از آن استفاده می‌کنند بیرون می‌گذارد، پس کار، پذیرش است نه اعتماد.
تصور دو قفل روی یک در کمک می‌کند. گواهی قفل بیرونی را باز می‌کند و تصمیمی مخصوص هر سرویس قفل درونی را؛ هیچ‌کدام جای دیگری را نمی‌گیرد. سرویسی که فقط قفل بیرونی دارد اصلاً عضویت را اعمال نمی‌کند، تنها احراز هویت می‌کند. پیش از هر تغییری هر دو تصمیم را بنویسید، چون سیاستی که فقط در قالب اتصالی کارآمد وجود دارد قابل حسابرسی نیست. آنچه در ادامه می‌آید درباره قفل درونی است.
بازنویسی‌های اختیاری را به دروازه پذیرش تبدیل کنید
پوشه پیکربندی مشتری معمولاً یک تسهیل است: فایل‌های درون آن تنظیمات مشتریانی را که نام می‌برند بازنویسی می‌کنند و مشتری بدون فایل صرفاً با پیش‌فرض‌های سرور اجرا می‌شود. یک دستور این تسهیل را به دروازه تبدیل می‌کند، به‌طوری که نبودن فایل یعنی اتصال رد می‌شود.
client-config-dir /etc/openvpn/service-a/clients
ccd-exclusiveنسخه اجتماعی OpenVPN 2.6 ccd-exclusive در صفحه راهنمای خود دقیقاً همین شرط را مستند می‌کند، و جست‌وجوی فایل نام‌برده بر هویت مؤثر مشتری استوار است. ساخت‌های دیگر و سرورهای مدیریت‌شده توسط محصول ممکن است متفاوت باشند، پس پیش از تکیه بر همان معناشناسی در جای دیگر، نسخه نصب‌شده را تأیید کنید.
مسیر بالا را نمونه بگیرید و طرح مستقرشده را بررسی کنید، نه اینکه پوشه‌ای بسازید که راهنمایی از خود درآورده است. بررسی‌های موجود گواهی، بررسی هویت سرور و احراز هویت حساب را دقیقاً همان‌طور که بودند بگذارید، چون این قطعه شرطی می‌افزاید و چیزی را برنمی‌دارد. تغییر را پیش از تولید آماده کنید، چون رد شدن در نقطه‌ای اشتباه شبیه خطای گواهی به نظر می‌رسد و بررسی را به سمت مرجع می‌فرستد. سپس تأیید کنید که خط گزارش برای مشتری ردشده نام فایل پیکربندی غایب را می‌آورد، نه زنجیره را.
یک پوشه برای هر سرویس، نه یک فهرست مشترک
عضویت از آن سرویسی است که آن را اعمال می‌کند، پس هر سرویس پوشه و فایل‌های خودش را نگه می‌دارد. نشان دادن دو سرویس به یک فهرست باعث می‌شود عضویت را شریک شوند چه کسی قصدش را داشته باشد چه نه، و تغییر حاصل به‌سختی به یک تصمیم ردیابی می‌شود. مرجع مشترک می‌تواند مشترک بماند؛ فایل‌های پذیرش نمی‌توانند. جدا نگه داشتن آن‌ها همچنین یعنی اشتباه در یک سرویس نمی‌تواند دیگری را بی‌صدا گسترش دهد.
ورودی DEFAULT همان موردی است که مردم را گمراه می‌کند. وقتی فایل نام‌برده پیدا نشود تنظیمات جایگزین می‌دهد، اما همان فایل نام‌برده‌ای نیست که دروازه می‌خواهد، پس به‌تنهایی نمی‌تواند مشتری را بپذیرد. مشتری‌ای را آزمایش کنید که هیچ ورودی ندارد و رد شدن را تأیید کنید؛ اگر آن مشتری پذیرفته شود، جایگزین اعمال می‌شود و ccd-exclusive در آن نمونه اعمال نمی‌شود.
هویت مؤثر تعیین می‌کند کدام فایل خوانده می‌شود
جست‌وجو از هویتی استفاده می‌کند که مشتری واقعاً با آن احراز هویت کرده است، که معمولاً نام مشترک گواهی است. جایی که سرور نام کاربری و گذرواژه را نیز بررسی می‌کند و آن نام را به نام مشترک نگاشت می‌کند، فایل باید به‌جای آن با نام کاربری احراز هویت‌شده مطابقت داشته باشد. ناسازگاری پوشه‌ای پر از نام‌های فایل محتمل باقی می‌گذارد که هیچ‌گاه انتخاب نمی‌شوند.
خواندن نیمه دیگر است. دیمن معمولاً پس از راه‌اندازی امتیازات را رها می‌کند، پس حساب کاهش‌یافته به دسترسی خواندن پوشه و هر ورودی درون آن نیاز دارد. مشتریان نباید بتوانند از هیچ مسیر قابل‌نوشتنی ورودی خودشان را بسازند، چون پذیرش خودخدمتی کل سازوکار را بی‌اثر می‌کند. مجوزهای اتصال و اشتراک را بررسی کنید نه فقط حالت فایل را، چون پوشه‌ای که برای یک حساب بسته به نظر می‌رسد ممکن است برای حسابی دیگر باز باشد. سپس تأیید کنید که فرایند در حال اجرا واقعاً از کدام حساب استفاده می‌کند، نه اینکه فایل unit کدام حساب را نام می‌برد. این دو تنها زمانی یکی هستند که چیز دیگری آن‌ها را تغییر نداده باشد.
رد شدن، پذیرش و لغو را جداگانه مشاهده کنید
هویتی را که به سرویس تعلق دارد آزمایش کنید و تأیید کنید که متصل می‌شود. گواهی معتبری بدون ورودی را آزمایش کنید و تأیید کنید که رد می‌شود. هویتی را که به سرویس دیگر پذیرفته شده آزمایش کنید و تأیید کنید که اینجا پذیرفته نمی‌شود. نمونه سرویس و هویت مؤثر را کنار هر نتیجه ثبت کنید، چون نتیجه‌ای بدون این زمینه را هیچ‌کس دیگری نمی‌تواند بازتولید کند.
پس‌گرفتن عملیاتی جدا از لغو است. ویرایش پرونده پذیرش یک حق سرویس را برمی‌دارد در حالی که هویت در همه جای دیگر معتبر می‌ماند، در حالی که کلید افشاشده پاسخ لغو سازمان را می‌خواهد. از پیش تصمیم بگیرید با نشست‌هایی که هم‌اکنون برپا هستند چه می‌شود، چون نه ویرایش پوشه و نه فهرست لغو آن‌ها را به‌تنهایی پایان نمی‌دهند.
پذیرش تنها دروازه نخست است. پیوستن به یک سرویس درباره زیرشبکه‌ها، پایگاه‌های داده یا رابط‌های مدیریتی پشت آن چیزی نمی‌گوید، و سیاست آن منابع باید جداگانه نوشته و آزمایش شود.