TUN/TAP: آرگومان نامعتبر — ناسازگاری قالب‌بندی OpenVPN

کلاینت احراز هویت می‌شود، گزارش می‌گوید متصل است، و هیچ بسته‌ای از تونل عبور نمی‌کند. سرور تلاش را با write to TUN/TAP: Invalid argument (code=22) پایان می‌دهد که شبیه خرابی درایور است و معمولاً نیست. روی روترها و سرورهای کوچک Linux، این خط بیشتر یعنی دو طرف بر سر نحوه قالب‌بندی بسته‌های داده توافق ندارند، پس هسته بافر رمزگشایی‌شده‌ای را که به آن داده شده رد می‌کند. مسیریابی در آن نقطه هنوز آزمایش نشده است.

جدول مسیریابی درست و توافق قالب‌بندی خراب از دید کلاینت یکسان به نظر می‌رسند: متصل، و هیچ چیز کار نمی‌کند.

تونل بالا می‌آید و چیزی از آن عبور نمی‌کند

خطاهای نوشتن روی دستگاه تونل پس از رمزگشایی و پیش از مسیریابی رخ می‌دهند. دیمن بسته‌ای را رمزگشایی می‌کند، آن را به رابط می‌دهد، و رابط آن را رد می‌کند چون بافر با آنچه آن دستگاه انتظار دارد مطابقت ندارد. کد 22 پاسخ عمومی آرگومان نامعتبر است، پس اطلاعات مفید لایه است: این مسیر داده است نه دست‌دهی. اگر ترافیک دیروز کار می‌کرد و امروز بدون تغییر پیکربندی متوقف شد، پیش از مشکوک شدن به شبکه به ارتقای بسته یا میان‌افزار که یک پیش‌فرض را جابه‌جا کرده مشکوک شوید.

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

فشرده‌سازی قالب‌بندی است، نه پهنای باند

با فعال بودن فشرده‌سازی، هر بسته داده سرآیندی حمل می‌کند که توضیح می‌دهد چگونه کدگذاری شده، و دو طرف باید بر سر آن سرآیند توافق کنند. سروری که هنوز comp-lzo را از یک پیکربندی نمونه قدیمی حمل می‌کند، همراه با کلاینتی که خط فشرده‌سازی ندارد، دقیقاً همین خطا را تولید می‌کند: سرور سرآیندی را انتظار دارد که کلاینت هرگز ننوشته است. آمیختن comp-lzo با compress lz4-v2 هم به همین شکل شکست می‌خورد، چون الگوریتم‌ها متفاوت‌اند هرچند هر دو فشرده‌سازی نامیده می‌شوند. این گزینه یک قرارداد قالب‌بندی است نه ویژگی پهنای باند در پیوندهای مدرن.

رفتار نسخه‌ها تله‌ای اضافه می‌کند. سری 2.5 شروع به صدور هشدارهای منسوخ‌شدن برای گزینه‌های فشرده‌سازی کرد، و 2.6 خطی بین رد بسته‌های فشرده و تنها گذاشتن داده‌ها به‌صورت فشرده‌نشده می‌کشد. بنابراین یک به‌روزرسانی میان‌افزار روتر می‌تواند توافق مؤثر را بدون ویرایش تونل توسط کسی تغییر دهد.

دو طرف را هم‌تراز کنید یا از هر دو حذفش کنید

هر دستور فشرده‌سازی را برشمارید: فایل سرور، هر گزینه ارسال‌شده، فایل‌های مخصوص کلاینت و پروفایل کلاینت. comp-lzo روی سرور به همان واژه روی کلاینت نیاز دارد، و adaptive همان پیش‌فرض قدیمی است که گزینه خالی معمولاً در بیلدهای قدیمی‌تر معنی می‌دهد. کلید رابط گرافیکی روتر با برچسب LZO یا فشرده‌سازی همان گزینه را می‌نویسد، پس آن را برای تطابق تنظیم کنید نه برای آمیختن الگوریتم‌ها. فرض نکنید نامی با ظاهر مشابه سازگار است.

اگر فشرده‌سازی نمی‌خواهید، آن را آگاهانه از دو طرف حذف کنید. allow-compression no روی سرور بسته‌های فشرده را رد می‌کند، اما تنها پس از آنکه کلاینت‌ها از ارائه آن‌ها دست کشیدند؛ اعمال آن در حالی که کلاینتی هنوز فشرده‌سازی را ارسال می‌کند، ناسازگاری را در جهت دیگر بازمی‌سازد.

ارسال و نوع دستگاه را بررسی کنید

سرور می‌تواند دستور فشرده‌سازی را از فایل اصلی یا از فایل مخصوص کلاینت ارسال کند، و کلاینت می‌تواند گزینه‌های ارسال‌شده را با pull-filter کنار بگذارد. یک کلاینت را در سطح جزئیات 4 وصل کنید، آنچه سرور اعلام کرده را در برابر آنچه کلاینت پذیرفته بخوانید، سپس تأیید کنید هیچ فیلتری آن را حذف نکرده است. اگر دو طرف اکنون توافق دارند و خطا باقی است، به نوع دستگاه نگاه کنید: dev tap در یک طرف و dev tun در طرف دیگر نمی‌توانند قاب‌ها را مبادله کنند و هسته نوشتن را به همان شکل رد می‌کند.

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

سپس با یک کلاینت و یک مقصد بررسی کنید: به نشانی تونل سرور پینگ کنید، سپس به میزبان LAN آن. اولی کانال داده را ثابت می‌کند و دومی ارسال را.