OpenVPN auth-nocache: در ورود بعدی چه اتفاقی میافتد
پاک کردن اعتبارنامههای OpenVPN از حافظه، احراز هویت بعدی را تغییر میدهد. کلاینت تعاملی، فایل اعتبارنامه و سرویس هرکدام به رفتار متفاوتی نیاز دارند.
auth-nocache را روشن کنید و هشدار ذخیرهسازی رمز در حافظه پنهان ناپدید میشود، همراه با نسخهای از اعتبارنامهها که OpenVPN برای مذاکره مجدد بعدی نگه میداشت. اینکه این وضع به یک پرسش، تلاش دوباره بیصدا یا تونل قطعشده تبدیل شود، به این بستگی دارد که اعتبارنامهها بار دوم از کجا بیایند. بنابراین این مقایسه میان شکلهای استقرار است، نه داوری دربارهٔ این گزینه. پیش از ویرایش هر پروفایلی، شکلی را که واقعاً اجرا میکنید بخوانید.
مجموعهٔ دوم اعتبارنامهها باید از کجا بیاید
OpenVPN گزینهٔ auth-nocache را روی رازهایی اعمال میکند که auth-user-pass و askpass جمع میکنند: پس از استفاده، فرایند آنها را دور میریزد نه اینکه برای دستدادن بعدی نگه دارد. مذاکرهٔ مجدد با زمانسنج میرسد، بهطور پیشفرض ساعتی یک بار، پس درخواست دوم مدتها پس از رفتن کسی که رمز را تایپ کرده بود میرسد. همان شکاف، تمام ماجراست. اگر حافظه پنهان روشن بماند، کلاینت نسخهٔ ذخیرهشده را بدون پرسیدن از کسی بازپخش میکند؛ اگر خاموش باشد، باید راز را جای دیگری پیدا کند یا شکست بخورد.
پس هر جایی را که راز در آن لحظه میتواند از آن بیاید فهرست کنید و صادق باشید که کدامیک از آنها روی میزبان وجود دارد. شخصی پشت ترمینال، فایلی که auth-user-pass یا askpass میتواند بخواند، یا توکن نشستی که سرور صادر میکند، سه چیزی هستند که اینجا مهماند. اگر هیچیک از آنها موجود نباشد، مذاکرهٔ مجدد یک ساعت پس از تغییر شکست میخورد، نه در لحظهای که تغییر را دادید.
سه شکل، سه نقطهٔ شکست
کلاینت رومیزی با شخصی در برابرش حالت خفیف است: پرسش برمیگردد، کسی دوباره رمز را تایپ میکند و هزینه توجه است. سرویس، کانتینر یا روتری که OpenVPN را بیترمینال اجرا میکند حالت سخت است، چون کسی برای پاسخ دادن نیست و اتصال مجددی که پیشتر بیصدا بود اکنون تونل را پایان میدهد. شکل ترکیبی میان آن دو مینشیند و تا وقتی نشستی که میتوانست به پرسش پاسخ دهد از میان نرفته، مانند حالت رومیزی رفتار میکند. چیزی که آنها را جدا میکند نصب بودن رابط گرافیکی نیست، بلکه وجود منبع اعتبارنامه در زمان مذاکرهٔ مجدد است.
پیش از هر تغییری استقرار خود را به یکی از این سه شکل نسبت دهید، چون توصیهای که آنلاین پیدا میکنید تقریباً همیشه برای شکل اول نوشته شده است. اعمال پاسخ رومیزی بر سرویس بیترمینال همان راهی است که تونلی که ماهها کار میکرد، هر ساعت شروع به افتادن میکند.
دستور یا پرچم: یکی را انتخاب کنید و بدانید کدام را به کار بردید
درون پروفایل، auth-nocache خطی مستقل است؛ در فراخوانیای که پروفایل را صریحاً نام میبرد، پرچمی در همان خط فرمان است و راهنمای OpenVPN هر دو شکل را فهرست میکند. هر دو با نگهداشتن اعتبارنامهها یک کار را میکنند و هیچکدام به نوع رابط دست نمیزند یا هشدار نامرتبطی را در همان گزارش تعمیر نمیکند. تفاوت در ماندگاری است: پرچم فقط همان اجرا را پوشش میدهد، بنابراین سرویسی که از فایل unit یا اسکریپت پوششی دوباره راهاندازی شود آن را نخواهد داشت مگر اینکه پوشش هم آن را منتقل کند.
auth-nocache
openvpn --config /path/client.ovpn --auth-nocacheتصمیم بگیرید کدام مصنوع مالک این تنظیم است، آن را همانجا تغییر دهید و هیچجای دیگر. پروفایلی که روی لپتاپ ویرایش شده بههمراه یک unit از systemd که آن را با پرچم نقض میکند، همان جفتی است که پس از راهاندازی مجدد رفتار متناقض میسازد.
فایل اعتبارنامه راز را جابهجا میکند، نه حذف
نشان دادن auth-user-pass به یک فایل به هر مذاکرهٔ مجدد بعدی منبعی میدهد و رمز را نیز جایی میگذارد که از راهاندازیهای مجدد جان سالم به در میبرد. بپرسید چه کسی میتواند آن فایل را بخواند، آیا سرویسدهنده پس از رها کردن امتیازها هنوز میتواند آن را بخواند، و وقتی فایلسیستم فقطخواندنی سوار شده یا نمای کانتینر مسیر را پنهان میکند چه میشود. راز روی دیسک و راز در حافظه دو مسئلهٔ متفاوتاند، و حل یکی دیگری را سر جایش میگذارد. چرخش همان مرحلهای است که از قلم میافتد: رمزی که روی سرور عوض شده ولی در فایل نه، شکستی میدهد که مانند خطای شبکه خوانده میشود.
فایل را در مالکیت حسابی نگه دارید که سرویسدهنده را اجرا میکند، برای هیچکس دیگری خواندنی نباشد و بیرون از نسخههای پشتیبانی باشد که میزبان را ترک میکنند. گزینهٔ سمت سرور auth-gen-token در OpenVPN پس از ورود موفق یک توکن نشست به کلاینت میدهد، که چیز کوچکتری برای رها کردن است تا رمز حساب. مرحلهٔ چرخش را در هر حال کنار فایل بنویسید، چون فایل معمولاً بیشتر از کسی که آن را ساخته عمر میکند.
طولانی کردن مذاکرهٔ مجدد هزینه را جابهجا میکند، آن را برنمیدارد
پیشنهاد دیگر بالا بردن reneg-sec است تا وقتی پرسش بهقدری نادر شود که بتوان نادیدهاش گرفت. این برنامهٔ چرخش کلید نشست را از نو مینویسد و همان مشکل اعتبارنامه را به لحظهای دیرتر و کمپیشبینیتر میراند؛ منبع اعتبارنامه نمیسازد. سیاستی که به دلیلی کلیدها را طبق برنامه تمدید میکند نباید فقط برای پرهیز از تایپ رمز شل شود.
اتصال مجدد را آزمایش کنید نه نشستی را که در آن نشستهاید، چون نشست زنده چیزی را ثابت نمیکند. تونل را از سمت سرور بیندازید، یا سرویس کلاینت را دوباره راهاندازی کنید، و ببینید مذاکرهٔ مجدد بعدی وقتی کسی پای صفحهکلید نیست چه میکند. اگر دوباره وصل شد، سازوکاری را که راز را تأمین کرد نام ببرید؛ اگر نه، هزینهٔ واقعی این گزینه را روی این میزبان یافتهاید. هر یک از این دو نتیجه پاسخی به شما میدهد که در زمان قطعی دوام میآورد، نه پاسخی که در زمان آزمایش دوام آورد.
در ناوگانی مدیریتشده، مالک استقرار باید بتواند سه چیز را نام ببرد: اعتبارنامه از کجا میآید، کجا ذخیره میشود و چه کسی آن را میچرخاند. اگر هر یک از این پاسخها همان کسی باشد که میزبان را راهاندازی کرده، این گزینه هنوز آنجا امن نیست.