การ offload NAT ด้วยฮาร์ดแวร์ทำให้กฎการกำหนดเส้นทาง VPN ของคุณเสียหรือไม่?

การเปิดการเร่งความเร็ว NAT ด้วยฮาร์ดแวร์อาจทำให้การตั้งค่า VPN เร็วขึ้น และยังอาจทำให้ นโยบายการกำหนดเส้นทางหยุดมีผลกับบางแพ็กเก็ตโดยไม่มีข้อผิดพลาดใด ๆ สิ่งใดจะเกิดขึ้นขึ้นอยู่กับว่าเส้นทางเร็วข้ามอะไร และสิ่งนั้นแตกต่างกันระหว่างเฟิร์มแวร์ เวอร์ชันเคอร์เนล และชนิดของการเร่งความเร็วที่ใช้ เมนูการตั้งค่าแทบไม่บอกว่าคุณเพิ่งเปิดอะไร

ข้อกล่าวอ้างสองข้อสมควรถูกแยกจากกันก่อนจะโทษตัวเร่งความเร็ว คือ กฎหยุดถูกบังคับใช้ และตัวนับหยุดถูกอัปเดต สิ่งเหล่านี้ไม่ใช่การสังเกตเดียวกัน

การเร่งความเร็วสามแบบที่ต่างกันถูกรวมเข้าด้วยกัน

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

Linux flowtables เป็นกรณีที่มีเอกสารและคุ้มค่าที่จะอ่านที่สุด เนื่องจากโฟลว์ที่สร้างไว้แล้วสามารถมอบให้เส้นทางเร็วได้ การบัญชีและการจัดการสถานะของมันจึงแตกต่างจากการส่งต่อแบบคลาสสิก และนั่นคือเหตุผลที่ตัวนับเริ่มดูแปลก

ตัวนับที่หยุดนิ่งพิสูจน์ได้น้อย

ตัวนับของกฎนับแพ็กเก็ตที่ผ่านกฎ และโฟลว์ที่ถูก offload อาจไม่ผ่านกฎนั้นอีกเลยหลังจากแพ็กเก็ตแรก สิ่งนี้สร้างตัวนับที่หยุดนิ่งในขณะที่ทราฟฟิกยังดำเนินอยู่ และดูเหมือนการข้ามผ่านพอดีหากคุณเชื่อตัวเลข การเฝ้าดูตัวนับยังมีประโยชน์เป็นเบาะแสว่าโฟลว์ออกจากเส้นทางที่นับแล้ว ส่วนที่เหลือของการวินิจฉัยต้องมาจากตำแหน่งที่แพ็กเก็ตไปจริง ๆ

การอนุมานตรงกันข้ามก็ล้มเหลวไม่แพ้กัน การดาวน์โหลดที่เร็วไม่ได้แสดงว่ากฎยกเว้นและการจัดการความล้มเหลวยังมีผล เพราะมันทดสอบโฟลว์เดียวไม่ใช่นโยบาย

เงื่อนไขสามข้อตัดสินว่าการ offload ทำให้นโยบายเสียหรือไม่

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

อ่านเอกสารของผู้ขายสำหรับการรวมกันที่คุณใช้งาน ไม่ใช่สำหรับรุ่นเราเตอร์โดยทั่วไป เวอร์ชันเฟิร์มแวร์เปลี่ยนคำตอบเหล่านี้อย่างเงียบ ๆ

ทดสอบนโยบาย ไม่ใช่ปริมาณงาน

วัดสิ่งที่นโยบายควรรับประกันก่อนวัดว่ามันไปได้เร็วแค่ไหน คำสั่งด้านล่างแสดงว่ามี 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 ยืนยันปลายทางส่วนตัวที่ควรเข้าถึงได้ รันชุดเดียวกันโดยปิดการเร่งความเร็วแล้วเปิดใหม่ และเปรียบเทียบผลลัพธ์ไม่ใช่เวลา

บันทึกการตั้งค่าก่อนหน้าไว้เพื่อให้การทดลองย้อนกลับได้ คำแนะนำทั่วไปให้ปิดการ offload ทุกที่ถือเป็นวิธีเลี่ยง ไม่ใช่ข้อค้นพบ