Windows L2TP โหลดได้เพียงบางเว็บไซต์: ล้างบิต DF บน pfSense

แล็ปท็อปเชื่อมต่อได้ อินทราเน็ตโหลดได้ แต่เว็บไซต์สาธารณะบางแห่งค้าง การพิสูจน์ตัวตนและการกำหนดเส้นทางทำงานชัดเจน จึงเหลือขนาดแพ็กเก็ตเป็นคำอธิบาย ในอุโมงค์ L2TP/IPsec ค่า MTU ที่ใช้ได้นั้นเล็กกว่าที่อะแดปเตอร์ยังประกาศอยู่ และไคลเอนต์ยังคงส่งแพ็กเก็ตขนาดเต็มโดยเปิดบิต «ห้ามแบ่ง» ไว้ เกตเวย์ pfSense สั่งให้ล้างบิตนั้นได้ และนั่นคือวิธีที่เร็วที่สุดในการยืนยันการวินิจฉัยก่อนจะแก้ให้ถูกต้อง

เริ่มจากหน้าที่ล้มเหลว

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

ทดสอบด้วย ping ที่ตั้งบิตและควบคุมขนาดเพย์โหลด เพย์โหลดที่ใหญ่ที่สุดที่ผ่านไปได้จะบอก MTU จริงของเส้นทาง และค่าที่อะแดปเตอร์ประกาศจะบอกว่าสองค่านี้ห่างกันแค่ไหน

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

บิต DF ทำอะไรตอนขาออก

การห่อหุ้มคือเหตุที่ตัวเลขต่างกัน IPsec เพิ่ม ESP ส่วน L2TP เพิ่มส่วนหัวอีกชั้น อุโมงค์จึงบรรทุกเพย์โหลดได้น้อยกว่าลิงก์จริง Windows ยังรายงาน 1500 ไบต์บนอะแดปเตอร์และตั้ง «ห้ามแบ่ง» ให้สิ่งที่ส่งออกไป เมื่อแพ็กเก็ตแบบนั้นใส่ไม่ได้ คำตอบที่ถูกต้องจากเกตเวย์คือข้อความ ICMP ที่ขอให้ผู้ส่งลดขนาดลง นี่คือเหตุที่อุโมงค์ซึ่งผ่าน ping เล็ก ๆ ยังล้มเหลวในการดาวน์โหลดไฟล์ได้

ข้อความนั้นมักไม่มาถึงเลย ฮอปใดฮอปหนึ่งอาจกรอง ICMP หรือไม่มีอะไรสร้างมันขึ้นมา และผู้ส่งก็ส่งขนาดเดิมซ้ำจนกว่าการถ่ายโอนจะยอมแพ้

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

ตัวเลือกของ pfSense และสิ่งที่มันไม่ได้ทำ

ตัวเลือกอยู่บนหน้า System, Advanced, Firewall และ NAT โดยมีป้ายว่า «ล้างบิต DF ที่ไม่ถูกต้องแทนการทิ้งแพ็กเก็ต» แทนที่จะทิ้งแพ็กเก็ตใหญ่เกินที่พาธงไว้ ตัวกรองจะถอดธงออกและปล่อยให้แพ็กเก็ตถูกแบ่งต่อไปตามทาง แพ็กเก็ตนับว่าไม่ถูกต้องเมื่อผ่านอินเทอร์เฟซขาออกในชิ้นเดียวไม่ได้

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

ใช้กับทราฟฟิกที่ส่งต่อเท่านั้น ไม่ใช่ทราฟฟิกที่ไฟร์วอลล์สร้างเอง หน้าเดียวกันยังมี «ปิดการขัดเกลาของไฟร์วอลล์» ซึ่งปิดการปรับให้เป็นมาตรฐานทั้งหมด และนั่นเป็นการเปลี่ยนแปลงที่กว้างกว่าที่ปัญหานี้ต้องการมาก

การแก้ที่แคบกว่าซึ่งคง TCP ไว้โดยไม่แบ่ง

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

สิ่งนั้นปล่อย UDP ให้การค้นพบหรือให้ตัวเลือก DF เมื่อเว็บไซต์ที่ล้มเหลวเป็นหน้าเว็บธรรมดา การจำกัดคือการเปลี่ยนแปลงที่ควรเลือก

ไคลเอนต์รายงาน MTU ของอะแดปเตอร์ตัวเองได้ผ่าน netsh interface ipv4 show subinterfaces เปรียบเทียบตัวเลขนั้นกับค่าที่เซิร์ฟเวอร์คิดว่าเจรจาไว้ เพราะสองค่าไม่เหมือนกันเสมอ ค่านั้นคือค่าที่ระบบปฏิบัติการใช้จริง ไม่ว่าการเจรจาจะรายงานอะไร

ยืนยันด้วยการดักจับ แล้วรีเซ็ตสถานะ

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

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