pfSense บน Virtio: TCP หยุดค้างจนกว่าจะปิด offload

ลูกค้ารายงานว่า tunnel เชื่อมต่อได้ ping ตอบ หน้าเข้าสู่ระบบโหลดได้ แต่แล้วการถ่ายโอนก็ค้างที่จุดเดิมในการลองทุกครั้ง รูปแบบนี้บอกไว้มากแล้ว คือการเข้าถึงปลายทางใช้งานได้ แต่ปริมาณงานต่อเนื่องใช้งานไม่ได้ ก่อนจะเปิด firewall ให้ตรวจก่อนว่า VPN เกี่ยวข้องกับความล้มเหลวนี้หรือไม่ ผลัก TCP ขนาดใหญ่ผ่าน gateway เดียวกันโดยไม่มี tunnel อยู่ในเส้นทาง ถ้าค้างเช่นกันก็แปลว่า OpenVPN ไม่เคยเกี่ยวข้อง

guest pfSense ที่ใช้การ์ดเครือข่าย virtio มีเหตุผลดีมากที่จะล้มเหลวในรูปแบบนั้นพอดี

แพ็กเก็ตเล็กผ่านได้ แต่ TCP ปริมาณมากค้าง

การจับมือ คำตอบ DNS และ echo ICMP นั้นเล็กและมักผ่านได้ การถ่ายโอนต่อเนื่องบังคับให้ guest แบ่งกลุ่มข้อมูล และตรงนั้นเองที่เส้นทาง offload ที่เสียหายปรากฏขึ้น ความผิดพลาดไม่จำเป็นต้องสมมาตร ฝั่งขาออกอาจสะอาดขณะที่ฝั่งขาเข้าหาย หรือกลับกัน ผู้ใช้จึงเข้าสู่ระบบได้แล้วค้างที่คำตอบใหญ่ครั้งแรก เพราะไคลเอนต์เดียวกันทำงานได้ผ่าน gateway อีกตัว ชิ้นส่วนใหม่ที่สุดจึงถูกตำหนิ

ดังนั้นให้ทดสอบ gateway โดยไม่มี tunnel การดาวน์โหลดจาก LAN ไป WAN ที่ใหญ่พอจะทำงานหลายวินาทีก็เพียงพอ และต้องทำก่อนเปลี่ยนการตั้งค่าใด ๆ เพื่อให้การเปรียบเทียบภายหลังมีความหมาย

สิ่งที่ offload สัญญาไว้จริง ๆ

virtio เป็น paravirtual กล่าวคือ host และ guest แบ่งงานกัน host ประกาศความสามารถด้าน checksum และการแบ่งกลุ่มข้อมูล และคาดว่า guest จะทำงานที่เริ่มไว้ให้เสร็จ ถ้าสแตกของ guest ไม่ทำเช่นนั้น เฟรมจะออกไปพร้อม checksum ที่ไม่สมบูรณ์หรือถูก host ทิ้ง E1000 ที่จำลองขึ้นเสนอแบบจำลองที่ง่ายและช้ากว่า ซึ่งปัญหาจะหายไปโดยไม่ต้องแก้ pfSense แม้แต่บรรทัดเดียว การเจรจาความสามารถเกิดแยกตามอุปกรณ์ จึงอธิบายได้ว่าทำไม guest ตัวหนึ่งทำงานได้หลายเดือนในขณะที่คู่แฝดที่สร้างใหม่ล้มเหลวตั้งแต่วันแรก

ชุดที่เจรจากันได้ขึ้นอยู่กับเวอร์ชันของ hypervisor และรุ่นการ์ดเครือข่ายที่เลือก ไม่ใช่แค่การตั้งค่าที่คุณนำเข้า

ช่องทำเครื่องหมายเดียวรักษา virtio ไว้

ในหน้าจอ pfSense เส้นทางระบบ แล้วขั้นสูง แล้วเครือข่าย มีช่องทำเครื่องหมายชื่อ ปิดการ offload checksum ระดับฮาร์ดแวร์ เมื่อเลือกแล้ว guest จะคำนวณ checksum ในซอฟต์แวร์ ซึ่งตรงกับสิ่งที่สแตก FreeBSD เบื้องหลัง pfSense คาดหวังจากอุปกรณ์ paravirtual ตัวเลือกที่เกี่ยวข้องอีกสองรายการในหน้าเดียวกันครอบคลุม offload การแบ่งกลุ่ม TCP ระดับฮาร์ดแวร์และ offload การรับขนาดใหญ่ระดับฮาร์ดแวร์ ให้หันไปใช้สิ่งเหล่านี้เมื่อการจับมือสำเร็จแต่การถ่ายโอนขนาดใหญ่ไม่สำเร็จ

ปล่อยให้การ์ดเครือข่ายเป็น virtio ไว้ขณะทำการเปลี่ยนแปลง การเปลี่ยนไปใช้ E1000 เผา CPU ทุกแพ็กเก็ตตลอดอายุของ VM และปิดบังปัญหาการตั้งค่าไว้จากผู้ที่รับช่วง host ต่อ ซึ่งเป็นการแลกเปลี่ยนที่แย่กว่าเส้นทางข้อมูลที่ช้าลงเล็กน้อยแต่คาดเดาได้

วัดต้นทุนที่คุณเพิ่งยอมรับ

การคำนวณ checksum ในซอฟต์แวร์ย้ายงานเข้าไปใน guest ดังนั้นให้วัดปริมาณงานต่อเนื่องภายหลังแทนที่จะถือว่าไม่มีต้นทุน บน VM ขนาดเล็กการลงโทษนั้นมีจริง แต่เห็นได้และสม่ำเสมอ ต่างจากการสูญหายแบบเงียบ เปรียบเทียบตัวนับข้อผิดพลาดของอินเทอร์เฟซและบันทึกเคอร์เนลของ guest ก่อนและหลัง hypervisor ที่กรองบริดจ์เป็นความผิดพลาดแยกต่างหากด้วยหลักฐานคนละแบบ และไม่มีแฟล็ก offload ใดรักษาได้

เปลี่ยนทีละอย่างต่อการทดสอบหนึ่งครั้ง แล้วบันทึกเส้นทางเมนู ช่องที่คุณเลือก และตัวเลขที่คุณวัด ผู้ที่ต้องเจอ guest ที่สร้างใหม่คนต่อไปจะต้องการทั้งสามอย่าง

firewall อื่นที่อิง BSD มีการควบคุมเทียบเท่าภายใต้การตั้งค่าอินเทอร์เฟซของตนเอง เหตุผลจึงใช้ได้แม้เส้นทางเมนูจะไม่ตรงกัน