OpenVPN میگوید ncp-disable ناشناخته است: چه چیزی جای آن را گرفت؟
ncp-disable هرگز به معنای خاموش کردن رمزنگاری نبود و نسخه 2.6 این گزینه را حذف کرد. مشخص کنید کدام فایل دودویی خطا را تولید کرده و سیاست data-cipher را روی هر دو طرف اصلاح کنید.
کلاینت با خطای گزینههایی که به ncp-disable اشاره میکند از راهاندازی امتناع میکند، در حالی که پروفایل روی دستگاه قبلی کار میکرد. این پیام به معنای آن نیست که گزینه غلط نوشته شده یا رمزنگاری خراب است. یعنی فایل دودویی پیش روی شما اصلاً این دستور را نمیشناسد، و دو دلیل کاملاً متفاوت برای آن وجود دارد. اینکه کدام مورد صدق میکند تعیین میکند پروفایل را ویرایش کنید یا کلاینت را عوض کنید.
خطا میتواند از یک فایل دودویی جدیدتر بیاید
خطای گزینه ناشناخته به تجزیهکننده مربوط است، نه به تونل. نسخه 2.4 OpenVPN پارامترهای رمز قابل مذاکره را اضافه کرد، 2.5 کلیدی که آنها را غیرفعال میکرد منسوخ اعلام کرد و 2.6 آن را کاملاً حذف کرد. بنابراین پروفایلی که برای 2.3 یا 2.4 نوشته شده روی کلاینت فعلی شکست میخورد، حتی اگر هیچ چیز در فایل تغییر نکرده باشد. نسخهای که شکایت میکند جدیدتر است، نه قدیمیتر.
پیش از هر ویرایشی مشخص کنید کدام فایل اجرایی پیام را تولید کرده است. کلاینت دسکتاپ موتور خودش را همراه دارد، در حالی که فایل دودویی خط فرمان که جداگانه نصب شده نسخه خودش را دارد. این دو میتوانند روی یک دستگاه با هم اختلاف داشته باشند.
openvpn --version برای فایل دودویی که آزمایش میکنید این را روشن میکند. ممکن است کلاینت گرافیکی آن دستور را نشان ندهد؛ در این صورت صفحه درباره آن یا نسخه کتابخانه همراه را بخوانید.
این گزینه در واقع چه چیزی را کنترل میکرد
این دستور مذاکره پارامترهای رمزنگاری را غیرفعال میکرد، بنابراین هر دو طرف به رفتار انتخاب قدیمیتر که با تنظیم cipher هدایت میشد بازمیگشتند. هرگز رمزنگاری را غیرفعال نکرد و هرگز تونل را به متن ساده تبدیل نکرد. خواندن آن به عنوان یک کلید امنیتی اولین پیچ اشتباه است و به تغییراتی میانجامد که اتصال را بدتر میکند نه بهتر.
وقتی مذاکره وجود دارد، پرسش معادل این است که هر طرف حاضر است از کدام رمزها استفاده کند. این یک پرسش سیاستی است و سیاست در data-ciphers از نسخه 2.5 به بعد زندگی میکند.
نام قدیمیتر ncp-ciphers متعلق به 2.4 است. درهم آمیختن این دو نام میان طرفین منبع شایعی برای شکستهای مذاکره یکطرفه است. پروفایلی که هر دو را دارد پروفایلی است که دو نفر در زمانهای مختلف ویرایش کردهاند.
سیاست را جایگزین کنید، نه املا را
روی هر دو طرف data-ciphers را با یک انتخاب مشترک مورد نظر تنظیم کنید و فهرست را به اندازهای کوتاه نگه دارید که بازبین بتواند درباره آن استدلال کند. تغییر یک خط دلخواه چیزی را اثبات نمیکند؛ نتیجه به اشتراک دو فهرست و به آنچه پشته TLS پشتیبانی میکند بستگی دارد. با خواندن نتیجه مذاکرهشده به جای پیکربندی تأیید کنید که طرفین توافق دارند. سپس هر دو فهرست را در سابقه استقرار بنویسید تا تغییر بعدی از وضعیت شناختهشده شروع شود.
پروفایل را از طریق مالک آن بهروزرسانی کنید. افزودن یک گزینه نادیدهگرفتن برای پنهان کردن دستور منسوخ، پرسش سیاستی را بیپاسخ میگذارد.
اگر یک طرف قدیمیتر واقعاً به مدیریت سازگاری نیاز دارد، آن را به همان استقرار محدود کنید. بازگرداندن رفتار منسوخ بهصورت سراسری پیششرط اتصال طرفهای مدرن نیست. استثنا باید طرفی را که برایش وجود دارد نام ببرد.
دو خط که شبیه فهرست رمز هستند اما نیستند
روی هم چیدن دو خط رمز هم مذاکره را بازنمیگرداند و نتیجه پروفایلی است که شبیه فهرست به نظر میرسد اما مانند یک مقدار واحد رفتار میکند. یک خط با AES-256-CBC و خط بعدی با CBC تلاش رایجی است. CBC به تنهایی نام یک حالت است نه یک الگوریتم، بنابراین تجزیهکننده ممکن است آن را در یک جایگاه بپذیرد و در جایگاه بعدی رد کند. دستورهای تکراری cipher همان گزینه را دو بار تنظیم میکنند نه اینکه نامزدها را جمع کنند.
نامهای پذیرفتهشده را با openvpn --show-ciphers روی فایل دودویی هدف بررسی کنید، نه با کپی کردن فهرستی از راهنمایی که برای شاخه دیگری نوشته شده است. فهرست میان انتشارها تغییر میکند. نامی که در یک شاخه معتبر است لزوماً در شاخه دیگر معتبر نیست.
اگر هدف مقایسه عملکرد بود، الگوریتمها و بار کاری را ثبت کنید. تغییر به CBC سنجش نبود رمزنگاری نیست.
بررسی کنید اتصال واقعاً چه چیزی را مذاکره کرده است
یک اتصال تازه برقرار کنید و خط کانال داده در گزارش را بخوانید که رمز در حال استفاده را نام میبرد. مجموعه کانال کنترل جداگانه تعیین میشود، بنابراین فهرست مجاز در فایل فقط نشان میدهد چه چیزی پیشنهاد شده بود. وقتی دو طرف چیزی را انتخاب کردند که انتظارش را نداشتید، فهرستها جای نگاه کردن هستند نه رابط تونل. پس از هر تغییری نتیجه را روی اتصال دوم تأیید کنید، زیرا یک راهاندازی مجدد میتواند نشست ذخیرهشده در حافظه نهان را دوباره استفاده کند.
نتیجه مذاکرهشده را در سابقه استقرار کنار نسخه پروفایل نگه دارید. این همان واقعیتی است که به پرسش بعدی درباره اینکه کدام رمز واقعاً از ترافیک محافظت میکند پاسخ میدهد.