چرا افزودن opt-verify خطای رمزنگاری OpenVPN شما را برطرف نمی‌کند
این گزینه سازگاری رشته‌های گزینه‌ها را بررسی می‌کرد و در 2.7 حذف شده است. پروفایلی که هنوز تجزیه می‌شود چیزی درباره لایه رمزنگاری، TLS یا گواهی اثبات نمی‌کند.
پیشنهادی پیدا می‌کنید که opt-verify را اضافه کنید، خط را اضافه می‌کنید، و خطای رمزنگاری دقیقاً همان‌جا که بود می‌ماند. این نتیجه قابل پیش‌بینی است، زیرا گزینه هرگز بر سر رمزنگاری مذاکره نکرد. این یک بررسی سازگاری گزینه‌ها بود، که در 2.6 منسوخ و در 2.7 حذف شد، و پروفایلی که با آن هنوز تجزیه می‌شود چیزی را اعمال نکرده است.
دانستن اینکه این خط پیش‌تر چه می‌کرد کمک می‌کند، پیش از آنکه نتیجه بگیرید همان قطعه گمشده است. تاریخچه همچنین توضیح می‌دهد چرا اکنون نمی‌تواند کمک کند.
گزینه پیش‌تر چه چیزی را اعمال می‌کرد
راهنمای 2.6 opt-verify را منسوخ علامت می‌زند و رفتار پیشین را توصیف می‌کند: سرور کلاینت‌هایی را که گزینه‌های اعلام‌شده‌شان با گزینه‌های خودش نمی‌خواند حذف می‌کند و چیزهایی مانند نوع دستگاه و MTU را مقایسه می‌کند. آن بررسی همچنین به فعال ماندن بررسی سازگاری گزینه‌ها وابسته است، بنابراین سروری که با disable-occ اجرا می‌شود هرگز آن را نداشته است. توجه کنید که مقایسه از چه ساخته شده است: متنی که پیکربندی طرف مقابل را توصیف می‌کند. چیزی درباره اینکه کانال داده از کدام رمزنگاری استفاده خواهد کرد نمی‌گوید.
این نخستین دلیل است که پرچم نمی‌تواند خطای رمزنگاری را تعمیر کند. انتخاب رمزنگاری را سیاست data-ciphers و آنچه هر دو طرف پشتیبانی می‌کنند تعیین می‌کند، و یک بررسی سازگاری متنی نه آن فهرست را گسترش می‌دهد و نه مذاکره را انجام می‌دهد. دلیل دوم دامنه است: بررسی درباره این است که آیا گزینه‌های اعلام‌شده سازگار به نظر می‌رسند، نه درباره کیفیت مسیری که حاصل می‌شود.
2.7 وقتی خط را می‌بیند چه می‌کند
در 2.7 گزینه وجود ندارد. تجزیه‌گر هنوز نام را می‌شناسد، به همین دلیل پروفایل قدیمی بدون خطای نحوی بارگذاری می‌شود، و گزارش می‌دهد که گزینه حذف شده است نه اینکه بی‌صدا از آن بگذرد. شناختن یک نام و اعمال یک رفتار چیزهای متفاوتی هستند، و اکنون فقط اولی رخ می‌دهد. یادداشت‌های حذف دلیل را بیان می‌کنند: وقتی پارامترها قابل مذاکره باشند، دو طرف می‌توانند به‌طور مشروع رشته‌های گزینه‌های متفاوتی داشته باشند در حالی که درباره اتصال توافق دارند.
بنابراین پروفایلی که تجزیه می‌شود شاهدی بر اجرای هیچ بررسی پذیرشی نیست. اگر تنها نشانه شما این است که کلاینت متصل شده، آموخته‌اید که نحو پذیرفته شده است.
شکست در واقع کجا زندگی می‌کند
نخستین خطای مشخص را پیش از تغییر هر چیزی نگه دارید، زیرا پیام‌های بعدی معمولاً پیامدهای آن هستند. شکست مذاکره کانال داده به سیاست تأییدشده رمزنگاری و به قابلیت‌هایی تعلق دارد که هر دو طرف واقعاً اعلام می‌کنند. شکست نسخه یا مجموعه TLS به کانال کنترل تعلق دارد. رد گواهی به هویت و زنجیره اعتماد نیاز دارد، نه به پرچم سازگاری.
موتور را در هر دو سر نیز مشخص کنید. یک برنامه دسکتاپ ممکن است ساخت متفاوتی از باینری خط فرمانی که با آن آزمایش کرده‌اید همراه داشته باشد، و پشتیبانی گزینه‌ها میان آن‌ها متفاوت است. مستندات آن موتور را بررسی کنید، به‌جای اینکه فرض کنید هر برنامه‌ای که پروفایلی وارد می‌کند یکسان رفتار می‌کند.
قصد را جایگزین کنید، نه فقط خط را
اگر سرور مدیریت‌شده قدیمی‌تری واقعاً به بررسی سازگاری تکیه داشت، ثبت کنید که پیش از ارتقا چه محدودیتی را اعمال می‌کرد. نگه داشتن یک گزینه نادیده‌گرفته‌شده در پروفایل جدیدتر نمی‌تواند آن سیاست را حفظ کند، و حذف بی‌هدف خطوط هم نمی‌تواند.
به پیشنهاد قدیمی که همه رمزنگاری‌ها غیرفعال هستند با فعال کردن هر الگوریتم تاریخی پاسخ ندهید.
پس از یک اصلاح تأییدشده، نتایج مذاکره‌شده را روی اتصال تازه بررسی کنید و برنامه‌ای را که کاربر واقعاً نیاز دارد آزمایش کنید. نسخه سرور و سیاست مؤثر را کنار آن نتیجه نگه دارید تا نفر بعدی ببیند چه چیزی توافق شده، نه فقط چه چیزی پذیرفته شده است.
هدف یک محدودیت پشتیبانی‌شده و مسیری احراز هویت‌شده و کارآمد است، نه یک پرچم قدیمی که هنوز تجزیه می‌شود.