مهلت TLS شصت ثانیه‌ای: کدام طرف واقعاً متوقف شد؟

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

به یک تلاش هویتی بدهید که بتوانید جستجو کنید

زمان شروع را با منطقهٔ زمانی‌اش یادداشت کنید، نام پروفایل، مقصدی که کلاینت واقعاً تفکیک کرد، درگاه، و اینکه اتصال UDP است یا TCP. اگر پروفایل چند ورودی راه دور دارد، بنویسید آن تلاش کدام را انتخاب کرد، چون تلاش دوباره ممکن است بدون تغییر فایلی که می‌خوانید به ورودی بعدی رفته باشد.

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

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

چهار مشاهده، چهار گام بعدی متفاوت

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

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

چهار نتیجه را در یادداشت‌های خود جدا نگه دارید. وسوسه این است که آن‌ها را در «سرور پاسخ نمی‌دهد» ادغام کنید، و همین عبارت است که مردم را وقتی مشکل واقعی قاعدهٔ دیوار آتش است به تغییر رمزها می‌فرستد. یادداشتی که فقط واژهٔ مهلت را ثبت کند، تمایزی را که همین حالا بابتش پرداختید دور انداخته است.

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

اتصال TCP که کامل می‌شود فقط ثابت می‌کند چیزی یک سوکت را پذیرفته است. ثابت نمی‌کند که شنونده همان سرویس OpenVPN است که پیکربندی کرده‌اید، و یک وب‌سرور روی همان نام میزبان به مرورگر بی‌نقص پاسخ می‌دهد در حالی که به تونل بی‌ربط است.

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

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

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

تمدید پنجره واقعاً چه چیزی را تغییر می‌دهد

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

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