OpenVPN بعداً یک نشست OTP را قطع میکند: احراز هویت مجدد به چه چیزی نیاز دارد
نشستی که یک ساعت بعد میمیرد معمولاً یک تجدید کلید است که کدی را میخواهد که قبلاً استفاده شده است. بین توکنی که سرور صادر میکند و یک چالش تعاملی تازه یکی را انتخاب کنید.
از سمت کلاینت مانند یک قطع اتصال تصادفی یک ساعت پس از شروع یک نشست فعال به نظر میرسد. آیکون سینی ناپدید میشود، تونل دوباره ساخته میشود و گزارش، خطای احراز هویت را نشان میدهد نه خطای شبکه. آنچه واقعاً رخ داده این است که نشست دوباره مذاکره کرده و دستدادن دوم به مدارکی نیاز داشته که کلاینت دیگر نسخه معتبری از آنها نداشته است. کد یکبارمصرفی که هنگام ورود کار میکرد نمیتواند دوباره کار کند، بنابراین تجدید کلید دقیقاً همانطور که طراحی شده شکست میخورد.
راهحل تصمیمی درباره این است که دستدادن دوم چه چیزی ارائه کند، نه یک زمانسنج تلاش مجدد طولانیتر.
تبادل را از دیدگاه کلاینت دنبال کنید
هنگام ورود، کلاینت نام کاربری، گذرواژه و کدی از دستگاه توکن میفرستد و سرور این ترکیب را میپذیرد. سپس نشست تا زمانی که محرک مذاکره مجدد فعال شود ادامه مییابد و این کار یک دستدادن TLS تازه درون تونل موجود آغاز میکند. آن دستدادن دوباره احراز هویت میخواهد. اگر مسیر احراز هویت سرور گذرواژه بههمراه یک کد یکبارمصرف جاری انتظار داشته باشد، کلاینت کد تازهای برای ارائه ندارد مگر اینکه کاربر حاضر باشد و آن را تایپ کند.
بیشتر کلاینتها وسط نشست اعلانی باز نمیکنند، بنابراین دستدادن زماندار تمام میشود و تونل میافتد. کاربر اتصال مجدد میبیند، نه اعلان احراز هویت، و به همین دلیل اولین گزارش معمولاً شبکه را سرزنش میکند.
auth-gen-token تغییر میدهد که چه کسی به سؤال دوم پاسخ دهد
auth-gen-token گزینهای است که به سرور اجازه میدهد پس از ورود موفق توکنی صادر کند، و مذاکرههای مجدد بعدی بهجای تکرار گذرواژه و کد، همان توکن را ارائه میکنند. دفترچه راهنما عمر و رفتار تمدید آن را مستند میکند، و توکن باید بهعنوان مدرکی با انقضای خودش تلقی شود. در مسیر پیشفرض سرور خودش توکن را اعتبارسنجی میکند، نه اینکه دوباره احرازگر گذرواژه بیرونی را فرا خواند.
با یک یکپارچهسازی احراز هویت بیرونی، این تقسیم تغییر میکند. افزونه باید وضعیت توکن را بفهمد و بررسیهای خودش را اعمال کند، زیرا سرور دیگر تنها مؤلفهای نیست که تصمیم میگیرد نشست ادامه یابد یا نه. برخورد با توکن بهعنوان یک کد عددی یکبارمصرف دیگر، پیادهسازی این قابلیت نیست.
تصمیم بگیرید که با وضعیت حساب چه میشود
توکنی که از دسترسی یک حساب عمر بیشتری میکند یک حفره سیاستی است. تصمیم بگیرید حساب غیرفعالشده، عضویت گروه حذفشده یا دستگاهی که لغو شده، در حالی که توکن هنوز معتبر است، چگونه اعمال شود. عمرهای کوتاه توکن پنجره را کوچکتر میکنند؛ مسیر لغو صریح آن را عمدی میکند. پاسخ را قبل از فعال کردن گزینه بنویسید، زیرا مسیر پیشفرض در هر مذاکره مجدد با احرازگر بیرونی مشورت نمیکند.
در استقرار چندسروری، راز امضای توکن باید مشترک باشد، وگرنه ممکن است کلاینت به گرهی فرستاده شود که نمیتواند توکنش را اعتبارسنجی کند.
انقضا و اتصال مجدد را آزمایش کنید، نه فقط ورود را
فاصله مذاکره مجدد را در یک پروفایل آزمایشی کم کنید تا دستدادن دوم وقتی شما تماشا میکنید رخ دهد، سپس هر دو گزارش را دنبال کنید. تأیید کنید که توکن هنگام ورود صادر میشود، هنگام تجدید کلید ارائه میشود و بر اساس عمر پیکربندیشده تازه یا دوباره صادر میشود. سپس انقضای توکن و اتصال مجدد کامل را تحمیل کنید، زیرا کلاینتی که تمیز وصل میشود همچنان میتواند در مسیر تجدید کلید شکست بخورد.
حذف حساب را آخر از همه آزمایش کنید. آن مورد به شما میگوید سیاستی که نوشتید اجرا میشود یا فقط مستند شده است.
آن را با غیرفعال کردن تمدید درست نکنید
تنظیم فاصله مذاکره مجدد روی صفر در هر دو طرف، علامت بیماری و چرخش کلید را با آن حذف میکند. این کار مشکل بازپخش مدارک را پشت تغییری در سیاست پنهان میکند که هیچکس آن را بررسی نکرده است. تمدید را نگه دارید و بر اساس حضور یا نبود کاربر بین توکنی که سرور صادر میکند و یک چالش تعاملی تازه انتخاب کنید.
یک زمانسنج تلاش مجدد طولانیتر، کد مصرفشده را دوباره معتبر نمیکند. فقط قطع اتصال را به تأخیر میاندازد و خواندن گزارش را سختتر میکند.