pfSense pada Virtio: TCP tersekat sehingga offload dimatikan

Seorang klien melaporkan bahawa terowong bersambung, ping menjawab, halaman log masuk dimuatkan, dan kemudian pemindahan membeku pada titik yang sama pada setiap percubaan. Corak itu sudah banyak berkata: kebolehcapaian berfungsi dan daya pemprosesan berterusan tidak. Sebelum membuka firewall, ketahui sama ada VPN terlibat sama sekali dalam kegagalan ini. Salurkan TCP besar melalui gateway yang sama tanpa terowong dalam laluan; jika ia juga membeku, OpenVPN tidak pernah terlibat.

Tetamu pfSense dengan kad rangkaian virtio mempunyai sebab yang sangat baik untuk gagal dalam bentuk itu.

Paket kecil lepas, TCP besar tergantung

Jabat tangan, balasan DNS dan gema ICMP kecil dan biasanya lepas. Pemindahan berterusan memaksa tetamu menyegmen, dan di situlah laluan offload yang rosak muncul. Kerosakan tidak semestinya simetri: trafik keluar boleh bersih sementara trafik masuk hilang, atau sebaliknya, jadi pengguna boleh log masuk dan kemudian tersekat pada respons besar pertama. Kerana klien yang sama berfungsi melalui gateway lain, komponen terbaharu dipersalahkan.

Jadi uji gateway tanpa terowong. Muat turun dari LAN ke WAN yang cukup besar untuk berjalan beberapa saat sudah memadai, dan ia mesti dilakukan sebelum sebarang perubahan tetapan supaya perbandingan selepas itu bermakna.

Apa yang sebenarnya dijanjikan offload

virtio adalah paravirtual: hos dan tetamu berkongsi kerja, hos mengumumkan keupayaan checksum dan penyegmenan dan mengharapkan tetamu menyelesaikan apa yang dimulakannya. Jika tindanan tetamu tidak berbuat demikian, bingkai keluar dengan checksum tidak lengkap atau digugurkan oleh hos. E1000 yang diemulasikan menawarkan model lebih ringkas dan lebih perlahan yang membuat masalah hilang tanpa satu pun perubahan pada pfSense. Rundingan keupayaan berlaku bagi setiap peranti, yang menjelaskan mengapa satu tetamu berjalan berbulan-bulan sementara kembarnya yang dibina semula gagal pada hari pertama.

Set yang dirundingkan bergantung pada versi hipervisor dan model kad rangkaian yang dipilih, bukan hanya pada konfigurasi yang anda import.

Satu kotak semak mengekalkan virtio

Dalam antara muka pfSense, laluan Sistem kemudian Lanjutan kemudian Rangkaian mengandungi kotak semak bernama Lumpuhkan offload checksum perkakasan. Menandakannya membuat tetamu mengira checksum dalam perisian, yang sepadan dengan apa yang dijangka oleh tindanan FreeBSD di belakang pfSense daripada peranti paravirtual. Dua pilihan berkaitan pada halaman yang sama merangkumi offload penyegmenan TCP perkakasan dan offload penerimaan besar perkakasan. Gunakan kedua-duanya apabila jabat tangan berjaya tetapi pemindahan besar tidak.

Biarkan kad rangkaian sebagai virtio semasa membuat perubahan. Bertukar kepada E1000 membakar CPU pada setiap paket sepanjang hayat VM dan menyembunyikan masalah konfigurasi daripada sesiapa yang mewarisi hos, yang merupakan pertukaran lebih buruk daripada laluan data yang sedikit lebih perlahan tetapi boleh diramal.

Ukur kos yang baru anda terima

Checksum perisian memindahkan kerja ke dalam tetamu, jadi ukur daya pemprosesan selepas itu daripada menganggapnya percuma. Pada VM kecil hukumannya nyata, tetapi ia kelihatan dan stabil, tidak seperti kehilangan senyap. Bandingkan pembilang ralat antara muka dan log kernel tetamu sebelum dan selepas. Hipervisor yang menapis jambatan ialah kerosakan berasingan dengan bukti berbeza, dan tiada bendera offload akan menyembuhkannya.

Tukar satu perkara setiap ujian dan catat laluan menu, kotak yang anda tandakan dan nombor yang anda ukur. Sesiapa yang menghadapi tetamu bina semula seterusnya akan mahu ketiga-tiganya.

Firewall lain berasaskan BSD menawarkan kawalan setara dalam tetapan antara muka mereka sendiri, jadi penaakulan itu tetap terpakai walaupun laluan menunya tidak.