pfSense روی Virtio: تا وقتی offload خاموش نشود، TCP می‌ایستد
یک pfSense مجازی‌سازی‌شده به ping پاسخ می‌دهد و سپس روی TCP حجیم متوقف می‌شود. مسیر offload جمع کنترلی virtio را خاموش کنید و هزینه را بسنجید، نه اینکه کارت شبکه را عوض کنید.
یک مشتری گزارش می‌دهد که تونل وصل می‌شود، ping پاسخ می‌دهد، صفحه ورود بارگذاری می‌شود و سپس انتقال در هر تلاش در همان نقطه می‌ایستد. این الگو از همین حالا چیز زیادی می‌گوید: دسترسی‌پذیری کار می‌کند و توان عملیاتی پایدار نه. پیش از باز کردن دیوار آتش، بفهمید آیا VPN اصلاً در این خرابی دخیل است. TCP حجیم را از همان دروازه و بدون تونل در مسیر عبور دهید؛ اگر آن هم متوقف شود، OpenVPN هرگز دخالتی نداشته است.
میهان pfSense با کارت شبکه virtio دلیل بسیار خوبی دارد که دقیقاً به همین شکل شکست بخورد.
بسته‌های کوچک عبور می‌کنند، TCP حجیم می‌ماند
دست‌دهی‌ها، پاسخ‌های DNS و پژواک‌های ICMP کوچک‌اند و معمولاً عبور می‌کنند. انتقال‌های پایدار میزبان مهمان را مجبور به بخش‌بندی می‌کنند و همان‌جاست که مسیر offload آسیب‌دیده آشکار می‌شود. خرابی لازم نیست متقارن باشد: ممکن است ترافیک خروجی پاک باشد در حالی که ورودی می‌افتد، یا برعکس، پس کاربر می‌تواند وارد شود و سپس در نخستین پاسخ بزرگ متوقف شود. چون همان مشتری از دروازه‌ای دیگر کار می‌کند، انگشت اتهام به سمت جدیدترین جزء می‌رود.
پس دروازه را بدون تونل بیازمایید. یک دانلود از شبکه محلی به شبکه گسترده که به‌اندازه چند ثانیه ادامه یابد کافی است، و باید پیش از هر تغییر تنظیمات انجام شود تا مقایسه بعدی معنایی داشته باشد.
offload در واقع چه وعده‌ای می‌دهد
virtio شبه‌مجازی است: میزبان و مهمان کار را شریک می‌شوند، میزبان توانایی‌های جمع کنترلی و بخش‌بندی را اعلام می‌کند و انتظار دارد مهمان آنچه را آغاز کرده به پایان برساند. اگر پشته مهمان این کار را نکند، قاب‌ها با جمع کنترلی ناقص بیرون می‌روند یا میزبان آن‌ها را دور می‌ریزد. یک E1000 شبیه‌سازی‌شده مدل ساده‌تر و کندتری عرضه می‌کند که در آن مشکل بدون حتی یک تغییر در pfSense ناپدید می‌شود. مذاکره توانایی‌ها برای هر دستگاه جداگانه انجام می‌شود، و همین توضیح می‌دهد چرا یک مهمان ماه‌ها کار می‌کند و همزاد بازساخته‌اش از روز اول شکست می‌خورد.
مجموعه مورد مذاکره به نسخه هایپروایزر و مدل کارت شبکه انتخاب‌شده بستگی دارد، نه فقط به پیکربندی‌ای که وارد کرده‌اید.
یک جعبه انتخاب virtio را حفظ می‌کند
در رابط pfSense، مسیر سیستم و سپس پیشرفته و سپس شبکه جعبه انتخابی با نام غیرفعال کردن offload سخت‌افزاری جمع کنترلی دارد. تنظیم آن باعث می‌شود مهمان جمع‌های کنترلی را در نرم‌افزار محاسبه کند، که با آنچه پشته FreeBSD پشت pfSense از یک دستگاه شبه‌مجازی انتظار دارد همخوان است. دو گزینه مرتبط در همان صفحه offload سخت‌افزاری بخش‌بندی TCP و offload سخت‌افزاری دریافت بزرگ را پوشش می‌دهند. وقتی دست‌دهی‌ها موفق می‌شوند اما انتقال‌های حجیم نه، به سراغ آن‌ها بروید.
کارت شبکه را هنگام اعمال تغییر virtio نگه دارید. تغییر به E1000 در تمام عمر ماشین مجازی روی هر بسته پردازنده را می‌سوزاند و مشکل پیکربندی را از هر کسی که میزبان را به ارث می‌برد پنهان می‌کند، و این معامله‌ای بدتر از مسیر داده‌ای کمی کندتر اما قابل پیش‌بینی است.
هزینه‌ای را که همین حالا پذیرفتید بسنجید
محاسبه نرم‌افزاری جمع کنترلی کار را به مهمان منتقل می‌کند، پس بعداً توان عملیاتی را بسنجید نه اینکه فرض کنید هیچ هزینه‌ای ندارد. روی یک ماشین مجازی کوچک جریمه واقعی است، اما دیدنی و پایدار است، برخلاف افت خاموش. شمارنده‌های خطای رابط و گزارش هسته مهمان را پیش و پس مقایسه کنید. هایپروایزری که پل را فیلتر می‌کند خرابی جداگانه‌ای با شواهد متفاوت است و هیچ پرچم offload درمانش نمی‌کند.
در هر آزمون یک چیز را تغییر دهید و مسیر منو، جعبه‌ای که تیک زدید و عددی که سنجیدید را بنویسید. هر کس با مهمان بازساخته بعدی روبه‌رو شود هر سه را خواهد خواست.
دیوارهای آتش دیگر بر پایه BSD کنترل معادلی را در تنظیمات رابط خودشان عرضه می‌کنند، پس استدلال سفر می‌کند حتی وقتی مسیر منو نمی‌کند.