فشرده‌سازی OpenVPN: رد کردن، فقط دریافت یا LZO کامل؟
comp-lzo no یک رد قاطع نیست. رد کردن فشرده‌سازی، پذیرش یک‌طرفه در طول مهاجرت و نگه داشتن آن را مقایسه کنید و سپس بررسی کنید که offload چه می‌کند.
سه خط در یک پروفایل به نظر می‌رسد همه فشرده‌سازی را خاموش می‌کنند، در حالی که تنها یکی از آن‌ها واقعاً این کار را می‌کند. تفاوت مهم است، چون هشداری که می‌خواهید ساکت کنید یک نشانه است، در حالی که سیاست تعیین می‌کند آیا طرف مقابل هنوز می‌تواند فشرده‌سازی کند. مقایسه گزینه‌ها روی یک محور، یعنی اینکه هر کدام پس از تغییر چه چیزی را مجاز می‌کند، بیشتر ابهام را از میان برمی‌دارد. اینکه کدام را می‌خواهید بستگی دارد به اینکه در حال مهاجرت هستید یا در حال تثبیت.
سه سیاست که در فایل پیکربندی شبیه هم به نظر می‌رسند
هر گزینه به پرسش دیگری پاسخ می‌دهد. allow-compression no محموله‌های فشرده را به‌طور کامل رد می‌کند، allow-compression asym آنچه می‌رسد را از حالت فشرده خارج می‌کند و هرگز آنچه خارج می‌شود را فشرده نمی‌کند، و comp-lzo no قدیمی جای push طرف مقابل را برای فعال کردن فشرده‌سازی باز می‌گذارد. تنها اولی سیاستی است که سرور نمی‌تواند آن را نقض کند.
پیش از انتخاب، هر سه را در یک جدول بنویسید، چون نام‌ها به‌قدری نزدیک‌اند که بازبین را گمراه کند. دو مورد از آن‌ها هنوز کد از حالت فشرده خارج کردن را روی بسته‌های دریافتی اجرا می‌کنند و استدلال امنیتی دقیقاً به همین مربوط است. سومی توانایی را برمی‌دارد به‌جای اینکه جهت آن را محدود کند. اگر سابقه تغییر می‌گوید فشرده‌سازی غیرفعال شده است، دقیقاً یک ردیف آن جمله را برآورده می‌کند.
هشداری که تحقیق را آغاز کرد هدف نیست. ساکت کردن آن در حالی که یک سیاست سهل‌گیرانه برجاست، گزارش تمیزی و مواجهه‌ای بدون تغییر به دست می‌دهد.
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
معنای no در گزینه قدیمی LZO
در گزینه منسوخ LZO، no فشرده‌سازی را برای سمت محلی خاموش می‌کند بدون اینکه طرف مقابل را از فعال کردن آن در جایی که سیاست اجازه می‌دهد منع کند. همین عدم تقارن دلیل آن است که انتقال یک پروفایل به رد قاطع، رفتار را به روش‌هایی تغییر می‌دهد که آزمون آزمایشگاهی با یک سرور ممکن است هرگز آشکار نکند.
نگرانی امنیتی مشروط است نه مطلق. وقتی مهاجم می‌تواند متن روشن برگزیده را کنار یک راز بگذارد و ببیند فشرده‌سازی اندازه ترافیک رمزنگاری‌شده را چگونه تغییر می‌دهد، یک کانال اطلاعاتی وجود دارد. تغییر LZO به LZ4 الگوریتم و قالب‌بندی را عوض می‌کند، نه آن سازوکار را.
پس چارچوب صادقانه به این مربوط است که شما چه چیزی را حاضرید مجاز کنید، نه به اینکه کدام الگوریتم اکنون توصیه می‌شود. رد قاطع تنها گزینه‌ای است که به همکاری طرف مقابل وابسته نیست.
فقط دریافت یک وضعیت مهاجرت است، نه مقصد
پذیرش نامتقارن وجود دارد تا یک طرف بتواند فشرده‌سازی را متوقف کند در حالی که طرف دیگر هنوز انتظارش را دارد. این یک پل است و پل‌ها به تاریخ پایان و یک مسئول نیاز دارند. ثبت کنید کدام همتاها هنوز ترافیک فشرده می‌فرستند، چون سیاست دقیقاً همان ترافیک را مجاز می‌کند. بدون آن فهرست، وضعیت مهاجرت به‌خاطر اینرسی به پیکربندی دائمی تبدیل می‌شود.
کلاینت نمی‌تواند سرور ناسازگار را با ویرایش فایل خودش مجبور کند که قالب‌بندی قدیمی را رها کند. جهت push روی سرور تعیین می‌شود، پس مهاجرت در واقع در پیکربندی سرور و فایل‌های به‌ازای هر کلاینت آن کامل می‌شود.
حالت‌های stub قالب‌بندی را حفظ می‌کنند و خودِ کار فشرده‌سازی را رد می‌کنند، و جایگزین مستقیم گزینه قدیمی‌تر نیستند. پیش از انتخاب یکی از آن‌ها، آن‌ها را در برابر قدیمی‌ترین همتایی که هنوز باید پشتیبانی کنید بیازمایید.
کجا offload کانال داده پاسخ را تغییر می‌دهد
Offload کانال داده پردازش بسته را به هسته منتقل می‌کند و پروفایلی که هنوز به قالب‌بندی فشرده‌سازی وابسته است ممکن است در آن مسیر جا نشود. خطا همیشه پرصدا نیست: کلاینت متصل می‌شود و سپس رفتاری متفاوت از تونلی که آزموده‌اید نشان می‌دهد.
بررسی کنید کدام پیاده‌سازی پیش و پس از تغییر فعال است، نه فقط اینکه اتصال موفق می‌شود. وقتی مسیر offload قالب‌بندی فشرده‌سازی را رد می‌کند، سیاست رد قاطع و استقرار با offload همسو می‌شوند، در حالی که سیاست سهل‌گیرانه و استقرار با offload همسو نمی‌شوند.
این ترکیب آزمون خودش را می‌طلبد، چون دقیقاً همان‌جاست که فایلی که درست به نظر می‌رسد، بی‌صدا فایلِ در حال استفاده نیست. وضعیت مذاکره‌شده را با نیتی که در پروفایل ثبت شده مقایسه کنید، چون تنها یکی از آن‌ها در گزارش دیده می‌شود.
یک سیاست انتخاب کنید و سپس نتیجه مذاکره‌شده را بررسی کنید
وقتی می‌توانید هر دو طرف را تغییر دهید رد قاطع را انتخاب کنید، وقتی هنوز نمی‌توانید پذیرش نامتقارن را، و فشرده‌سازی کامل را تنها وقتی که می‌توانید بگویید چرا مواجهه پذیرفتنی است. سپس آنچه مذاکره شده را بررسی کنید نه آنچه فایل می‌گوید. گزارش آرام‌تر تنها وقتی مدرک است که با سیاستی که قصد استقرارش را داشتید همخوان باشد.
تصمیم را کنار پروفایلی که به آن مربوط است نگه دارید، همراه با تاریخ و همتاهایی که هنوز معاف‌اند. شش ماه بعد، آن یادداشت تفاوت میان یک استثنای عمدی و حادثه‌ای است که هیچ‌کس نمی‌تواند تاریخش را بگوید. آن را در همان مخزن پروفایل بنویسید تا ویرایشگر بعدی دلیل را پیش از دستور ببیند.