WireGuard หยุดชะงัก: ขีดจำกัด MTU หรือกฎส่งต่อที่หายไป?
ทุกอย่างที่เลยเซิร์ฟเวอร์ไปคือปัญหาการส่งต่อหรือเส้นทางขากลับ คำขอเล็กที่ทำงานได้ในขณะที่คำขอใหญ่หยุดชะงักคือลายเซ็นของขนาดแพ็กเก็ต
นิสัยคือการลด MTU ทันทีที่ WireGuard ทำงานผิดปกติ และนิสัยนั้นซ่อนข้อบกพร่องอีกอย่างไว้ เกตเวย์ที่ไม่ส่งต่อและเส้นทางที่ไม่รับแพ็กเก็ตใหญ่ให้รูปแบบที่แยกออกจากกันได้ อย่างหนึ่งล้มเหลวทั้งสองทิศทางและทุกขนาด อีกอย่างอยู่รอดกับคำขอเล็กและตายเมื่อเจอคำขอใหญ่ ระบุว่าคุณมีรูปแบบไหนก่อนจะเปลี่ยนตัวเลขใด ๆ การทดสอบมีต้นทุนต่ำและกำจัดสาเหตุที่เป็นไปได้ครึ่งหนึ่ง
สองความล้มเหลว สองรูปแบบที่ต่างกัน
ปัญหาการส่งต่อปรากฏขึ้นทันทีหลังเซิร์ฟเวอร์ การจับมือสำเร็จ ที่อยู่ของอุโมงค์ตอบสนอง และไม่มีอะไรหลังเกตเวย์ที่เข้าถึงได้แม้ด้วยคำขอเล็ก ๆ แพ็กเก็ตไปถึงเซิร์ฟเวอร์แต่ไม่ถูกส่งต่อ หรือคำตอบไม่มีเส้นทางกลับ
ปัญหาเรื่องขนาดจะปรากฏเฉพาะเมื่อเกินขีดจำกัด DNS การจับมือ TCP และการเรียก API เล็ก ๆ ทำงานได้ ในขณะที่การดาวน์โหลดไฟล์หรือคำตอบขนาดใหญ่ค้าง แพ็กเก็ตที่พอดีเดินทางจากต้นจนจบ และแพ็กเก็ตที่ไม่พอดีถูกทิ้งที่ใดที่หนึ่งโดยไม่มีรายงานที่เป็นประโยชน์
คำอธิบายเหล่านั้นชี้ไปที่คนละคนและไฟล์กำหนดค่าคนละไฟล์ จึงคุ้มค่าที่จะวัดรูปแบบมากกว่าการเดา ping เดียวไปยังเกตเวย์ไม่สามารถแยกทั้งสองออกจากกันได้
ตัดการส่งต่อออกก่อนจะลดอะไรลง
ทดสอบปลายทางที่เลยเกตเวย์ไป ไม่ใช่ตัวเกตเวย์ การ ping ไปยังที่อยู่ของอุโมงค์ของเซิร์ฟเวอร์พิสูจน์เพียงว่าอินเทอร์เฟซทำงานและคุณเข้าถึงเครื่องที่สิ้นสุดอุโมงค์ได้ ทราฟฟิกสำหรับเครือข่ายที่กว้างกว่าขึ้นอยู่กับการเปิดใช้งานการส่งต่อ IP บนเครื่องนั้นและไฟร์วอลล์ที่อนุญาตโฟลว์ที่ถูกส่งต่อ ทั้งสองอย่างต้องเป็นจริง และหากอย่างใดอย่างหนึ่งเป็นเท็จจะเกิดความเงียบแบบเดียวกัน
การกำหนดเส้นทางขากลับสำคัญพอ ๆ กัน หากเครือข่ายปลายทางไม่รู้ว่าจะไปถึงที่อยู่ของอุโมงค์ของไคลเอนต์ได้อย่างไร คำขอจะมาถึงและคำตอบจะหายไป และไคลเอนต์รายงานการหมดเวลาซึ่งดูเหมือนกับการส่งต่อที่ถูกทิ้งทุกประการ
ที่ใดการออกแบบใช้การแปลที่อยู่ กฎการแปลก็เป็นส่วนหนึ่งของเส้นทางขากลับนั้น การลบมันออกระหว่างตามหาปัญหา MTU จะเปลี่ยนการออกแบบที่ทำงานอยู่ให้กลายเป็นพัง จึงควรอ่านกฎที่มีอยู่ก่อนแก้ไข
วัดว่าการขาดเริ่มที่ไหน
อ่านสถานะการส่งต่อและกฎการกรองก่อน นี่คือการตรวจสอบแบบอ่านอย่างเดียวและตอบคำถามราคาถูกว่า
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9จากนั้นทดสอบขนาดด้วยบิต don’t-fragment จากไคลเอนต์ไปยังโฮสต์ที่เลยเกตเวย์ไป
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9หากการทดสอบแรกทำงานและการทดสอบที่สองล้มเหลวด้วยข้อผิดพลาดการแบ่งส่วน เส้นทางกำลังบอกขนาดที่ใช้งานได้ของคุณ หากทั้งสองไม่ทำงาน คุณกำลังดูการส่งต่อหรือการกำหนดเส้นทาง และ MTU ไม่ใช่ตัวแปรที่ต้องเปลี่ยน
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
ซ่อมชั้นที่คุณพิสูจน์แล้ว
เมื่อการส่งต่อเป็นข้อบกพร่อง การแก้ไขคือกฎการส่งต่อหรือเส้นทาง ที่เขียนให้แคบที่สุดเท่าการออกแบบอนุญาต เมื่อขนาดเป็นข้อบกพร่อง การแก้ไขคือ MTU ที่คำนึงถึงการห่อหุ้มบนเส้นทางเฉพาะนี้ ใช้กับอินเทอร์เฟซที่ต้องการ ไม่ใช่กับอะแดปเตอร์ทุกตัวในกองเรือ
ไม่ว่าจะทางใด หลังจากนั้นให้ทำภารกิจเดิมซ้ำกับปลายทางเดิม หากการถ่ายโอนขนาดใหญ่เดิมเสร็จสมบูรณ์ตอนนี้ การเปลี่ยนแปลงได้จัดการกับชั้นที่ล้มเหลว หากมีเพียงการทดสอบเล็กที่ดีขึ้น คุณรักษาอาการและขีดจำกัดที่แท้จริงยังอยู่
เขียนบันทึกว่าคุณสังเกตรูปแบบไหนก่อนการเปลี่ยนแปลง บรรทัดเดียวที่บันทึกไว้ข้างการแก้ไขคือสิ่งที่ป้องกันไม่ให้คนถัดไปลด MTU ที่ไม่เคยเป็นปัญหา