شکست دست‌دهی TLS در OpenVPN: روی کدام شاخه هستید؟
پایان مهلت، گواهی ردشده و کانال کنترلی ناسازگار به اصلاح‌های متفاوتی نیاز دارند. رویدادهای پیش از قطع ارتباط را بخوانید تا شاخهٔ درست را انتخاب کنید.
خطی که می‌گوید دست‌دهی TLS شکست خورده، پایان یک داستان است، نه آغاز آن. آنچه اهمیت دارد رویداد بلافاصله پیش از آن است، زیرا همان رویداد نام می‌برد که کدام‌یک از چهار ایراد کاملاً متفاوت را دارید. پایان مهلت، ناسازگاری کانال کنترل، رد شدن گواهی و شکست پس از مذاکره همه یک عنوان تولید می‌کنند. شاخه را بر پایهٔ شواهد انتخاب کنید تا اصلاح دیگر حدس نباشد.
آخرین رویداد پیش از شکست را بخوانید
به‌جای خواندن سطر آخر، به بالا بروید. رویداد پیش از قطع ارتباط معمولاً مرحله را نام می‌برد: هیچ پاسخی، خطایی هنگام تبادل بسته‌های کنترل، نتیجهٔ بررسی، یا مذاکرهٔ موفق که به دنبال آن نتیجهٔ احراز هویت می‌آید. هر یک از این‌ها به مسئول متفاوتی تعلق دارد. همان یک سطر تعیین می‌کند کدام بخش زیر صدق می‌کند.
متن خطا را همراه با نسخهٔ کلاینت، نقطهٔ پایانی و انتقال ذخیره کنید. کلیدها، گذرواژه‌ها و پروفایل‌های ویرایش‌نشده را از هر چیزی که عمومی می‌چسبانید بیرون نگه دارید.
یک خطای اول دقیق از گزیدهٔ طولانی گزارش ارزشمندتر است. مرحله را نام می‌برد، و مرحله مسئول را نام می‌برد.
شاخهٔ یکم: چیزی برنگشت
اگر کلاینت نخستین بستهٔ خود را فرستاد و چیزی قابل استفاده دریافت نکرد، مشکل در مسیر یا نزد شنونده است. تأیید کنید که پروفایل با گزینه‌ای که اپراتور واقعاً ارائه می‌دهد مطابقت دارد: نشانی، درگاه و UDP یا TCP. سپس بررسی کنید آیا نقطهٔ پایانی از این شبکه اصلاً قابل دسترسی است. پیش از ادامه یادداشت کنید کدام‌یک از این دو بررسی شکست خورد.
مرورگری که صفحه‌ای را روی همان نام میزبان بارگذاری می‌کند فقط ثابت می‌کند یک سرویس وب پاسخ داده است. حتی یک اتصال TCP پذیرفته‌شده هیچ نمی‌گوید دربارهٔ اینکه آیا OpenVPN مذاکره را کامل کرده است.
اگر پروفایل در شبکهٔ مطمئن دیگری کار می‌کند، آن مقایسه را نگه دارید. این محدودیت را به یک مسیر یا یک واسطه نسبت می‌دهد.
شاخهٔ دوم: کانال کنترل مطابقت ندارد
وقتی تبادل آغاز می‌شود و سپس متوقف می‌شود، تنظیمات کانال کنترل نخستین مظنون هستند. tls-auth و tls-crypt باید با استقرار مطابقت داشته باشند، و مواد از سرور دیگر تبادل مفیدی تولید نمی‌کند. این شکست پیش از هر ورود به حساب رخ می‌دهد. پروفایلی که از سرور قدیمی‌تر کپی شده معمولاً منبع آن است.
بازنشانی گذرواژه آن تنظیمات را جایگزین نمی‌کند، و قرض گرفتن کلید از سرویس دیگر اصلاح سازگاری نیست. پروفایل را از کانال تأییدشدهٔ اپراتور بگیرید و نسخهٔ کلاینتی را که انتظار دارد یادداشت کنید.
خطای مذاکرهٔ مشخص را ثبت کنید، نه اینکه انبوهی از الگوریتم‌های قدیمی‌تر را روشن کنید تا ببینید چه چیزی می‌ماند. متن خطای ثبت‌شده چیزی است که به اپراتور امکان بررسی سمت خود را می‌دهد.
شاخهٔ سوم: گواهی رد شد
یک شکست صریح بررسی، گواهی‌ای را که نمی‌پسندد نام می‌برد. ابتدا ساعت دستگاه را بررسی کنید، سپس بخوانید کدام شیء شکست خورد: گواهی سرور، گواهی کلاینت، یا یک صادرکننده در زنجیره. انقضا، صادرکنندهٔ نامعتبر و هویتی غیرمنتظره سه پیام متفاوت هستند.
بررسی را روشن نگه دارید تا مواد اصلاح‌شده را به دست آورید. پذیرش گواهی نامرتبط خطا را برمی‌دارد بی‌آنکه ثابت کند به سرور موردنظر رسیده‌اید.
یادداشت کنید که شکست از شبکه پیروی می‌کند یا از پروفایل. خطای گواهی که همه‌جا ظاهر می‌شود مشکل مسیر نیست.
شاخهٔ چهارم: مذاکره تمام شد و چیز دیگری شکست خورد
وقتی تبادل هویت موفق می‌شود، شکست باقی‌مانده به احراز هویت یا به مسیریابی تعلق دارد. رد صریح حساب یک پرسش احراز هویت است، و تونل متصل با سایت‌های دسترسی‌ناپذیر پرسشی از مسیریابی یا DNS است. ادامهٔ جایگزینی گزینه‌های TLS در آن مرحله به مرحله‌ای که پیش‌تر کار می‌کرد آسیب می‌زند.
وقتی مشکل را گزارش می‌کنید، بگویید آیا همهٔ شبکه‌ها شکست می‌خورند، آیا پروفایل دیگری کار می‌کند، و آیا سرور تلاش را ثبت کرده است. سکوت سمت سرور و رد شدن از سوی آن در دو مرز متفاوت قرار دارند.