ทำไมหน้า OpenConnect ถึงค้างจนกว่าคุณจะลด MTU ของอุโมงค์

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

แยกปัญหาขนาดออกจากปัญหานโยบาย

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

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

วัดเพดานด้วยโพรบ do-not-fragment

วัดเพดานแทนการเดา ส่งโพรบที่ปฏิเสธการแบ่งส่วนและลดเพย์โหลดลงทีละขั้นจนมีคำตอบกลับมา เริ่มจากคำสั่งเช่น ping -M do -s 1472 host คำตอบที่บ่นว่าต้องแบ่งส่วนทั้งที่ตั้ง DF ไว้หมายความว่าค่ายังสูงเกินไป ทำซ้ำที่ 1462 จากนั้น 1452 และหยุดที่ขนาดแรกที่ตอบกลับ บันทึกตัวเลขพร้อมกับโฮสต์ที่คุณทดสอบ เพราะ คำตอบเป็นของเส้นทางนั้น ไม่ใช่ของโปรโตคอลโดยทั่วไป.

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

นำค่าไปใช้กับอุปกรณ์อุโมงค์

นำผลลัพธ์ไปใช้กับอินเทอร์เฟซที่ไคลเอนต์สร้างขึ้น ไม่ใช่กับอะแดปเตอร์ Wi-Fi บนไคลเอนต์ Linux นั่นคือ ip link set dev tun0 mtu 1300 ตามด้วย ip link show tun0 เพื่อยืนยันว่ารับค่าแล้ว ใช้ชื่ออุปกรณ์ที่ไคลเอนต์รายงาน เพราะมันแตกต่างกันตามการใช้งานและตามวิธีสร้างอุโมงค์

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

ใช้คำขอ MTU ของไคลเอนต์เองก่อน

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

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

ตรวจสอบด้วยคำขอที่ล้มเหลว แล้วทำให้คงทน

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

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

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