آیا آفلود سخت‌افزاری NAT قواعد مسیریابی VPN شما را می‌شکند؟

روشن کردن شتاب سخت‌افزاری NAT می‌تواند راه‌اندازی VPN را سریع‌تر کند و همچنین می‌تواند باعث شود یک سیاست مسیریابی بدون هیچ خطایی اعمال‌شدن بر برخی بسته‌ها را متوقف کند. اینکه کدام‌یک رخ دهد به این بستگی دارد که مسیر سریع از چه چیزی می‌گذرد، و این میان firmware، نسخه هسته و نوع شتاب‌دهی مورد استفاده متفاوت است. منوی تنظیمات به‌ندرت به شما می‌گوید کدام‌یک را همین حالا فعال کرده‌اید.

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

سه شتاب‌دهی متفاوت با هم اشتباه گرفته می‌شوند

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

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

شمارنده‌ای که از حرکت می‌ایستد چیز زیادی اثبات نمی‌کند

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

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

سه شرط تعیین می‌کند که آیا آفلود سیاست را می‌شکند

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

مستندات فروشنده را برای ترکیبی که اجرا می‌کنید بخوانید، نه برای مدل مسیریاب به‌طور کلی. نسخه‌های firmware این پاسخ‌ها را بی‌صدا تغییر می‌دهند.

سیاست را بیازمایید، نه گذردهی را

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

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

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

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