نشست اول برنده است: محدودکردن ورودهای OpenVPN پیش از اخراج

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

دو قرارداد پشت یک تنظیم پنهان است

با غیرفعال بودن هم‌زمانی، اتصال دومی که همان نام گواهی را ارائه می‌کند می‌تواند نشستی را که در حال اجراست جابه‌جا کند. روشن کردن هم‌زمانی چند نشست را هم‌زمان مجاز می‌کند که عکس یک محدودیت است. هیچ‌کدام از این دو وضعیت سیاست رد کردن نیست، پس تصمیم باید جای دیگری گرفته شود.

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

اخراج پیش از قلاب اتصال شما رخ می‌دهد

در مسیر کد سرور 2.6، آماده‌سازی اولیه برای کلاینت جدید نمونه‌های موجود با همان نام را وقتی هم‌زمانی غیرفعال است حذف می‌کند. این حذف پیش از اجرای زنجیره گرداننده‌های اتصال رخ می‌دهد. بنابراین اسکریپتی که تکراری را تشخیص دهد و خطا برگرداند تازه‌وارد را پس از آنکه نشست موجود از پیش حذف شده رد می‌کند - دقیقاً همان نتیجه‌ای که سیاست می‌خواست جلوگیری کند. ترتیب فراخوانی‌ها در پیاده‌سازی بالادست تنها پاسخ قابل اتکا برای ساخت شماست.

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

تصمیم را به احراز هویت منتقل کنید

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

هر نمونه جدید باید از این دروازه بگذرد، از جمله اتصال‌های دوباره و هر مسیری که بدون پرسش دوباره احراز هویت می‌کند. دروازه‌ای که برخی نمونه‌ها هرگز به آن نمی‌رسند چیزی را محافظت نمی‌کند و این از قلم افتادن تا زمانی که کسی دور زدن را بیازماید نامرئی می‌ماند.

توکن‌ها می‌توانند از کنار دروازه بگذرند

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

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

رزرو را به نمونه گره بزنید، نه به نشانی

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

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

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

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