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

دو کانال، دو پیکربندی

یک OpenVPN نشست یک کانال کنترل و یک کانال داده دارد. کانال کنترل دست‌دادن TLS را اجرا می‌کند که همتاها را احراز هویت و کلیدها را مذاکره می‌کند. کانال داده بسته‌هایی را که ترافیک شما را حمل می‌کنند رمز می‌کند.

data-ciphers دومی را پیکربندی می‌کند. کانال کنترل گزینه‌های خودش را دارد، و بررسی‌های هویت نمایه موضوعی سوم و جداگانه است. تغییر یکی دیگری را درست نمی‌کند، از این رو نمایه می‌تواند درست به نظر برسد و باز در مرحله‌ای مشخص شکست بخورد.

وقتی یک پرونده پیکربندی می‌خوانید، این سه را در جعبه‌های خودشان نگه دارید.

مذاکره را از گزارش بخوانید

گزارش کلاینت وقتی اتصال موفق می‌شود هر دو نتیجه را نام می‌برد. یک خط درباره کانال کنترل و جزئیات TLS آن گزارش می‌دهد و خطی دیگر درباره رمزنگاری انتخاب‌شده کانال داده.

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

سپس فهرست‌های پیشنهادی را در دو طرف مقایسه کنید. نامی که نسخه یک همتا یا پایه رمزنگاری‌اش ارائه نمی‌دهد نمی‌تواند برگزیده شود، هر قدر هم که زود در فهرست همتای دیگر ظاهر شود.

چگونه انتخاب در واقع رخ می‌دهد

سرور هنگام دست‌دادن فهرست data-ciphers خود را به کلاینت می‌راند و کلاینت نخستین ورودی آن فهرست را که خودش هم پشتیبانی می‌کند برمی‌گزیند. پس ترتیب به پیکربندی سرور تعلق دارد، نه کلاینت.

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

نسخه‌های تازه‌تر فهرست پیش‌فرض را تغییر دادند و گزینه‌ای را که پیش‌تر آن را نگه می‌داشت تغییر نام دادند، پس دو همتا روی نسخه‌های مختلف می‌توانند بدون آن‌که کسی نمایه را ویرایش کند اختلاف داشته باشند. پیش از فرض یک غلط تایپی، نسخه را در هر طرف بررسی کنید.

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

همتاهای قدیمی‌تر به پشتیبان عامدانه نیاز دارند

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

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

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

یکپارچگی بررسی را حفظ کنید

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

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

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

اگر تونل برقرار شود و سایت‌ها باز هم شکست بخورند، رمزنگاری دیگر مظنون نیست. با مسیریابی و DNS ادامه دهید. ترتیب کار: هر دو خط گزارش را بخوانید، هر دو فهرست را مقایسه کنید، نسخه‌ها را بررسی کنید، پشتیبان را فقط برای همتایی که به آن نیاز دارد بیفزایید، سپس مسیر نوسازی را دوباره بیازمایید.

مقالات مرتبط