MTU หรือ MSS? การเปลี่ยน VPN แก้ปัญหาอะไรได้จริง

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

ตัวเลขสองตัว วัตถุสองอย่าง

MTU เป็นของลิงก์หรืออินเทอร์เฟซ คือแพ็กเก็ตที่ใหญ่ที่สุดที่ส่งต่อได้โดยไม่ต้องแบ่ง MSS เป็นของ TCP คือปริมาณเพย์โหลด TCP ที่มากที่สุดที่เซกเมนต์หนึ่งพาไปได้ และไม่นับส่วนหัว TCP กับ IP บนลิงก์อีเทอร์เน็ตทั่วไปที่ใช้ IPv4 MTU 1500 ไบต์ให้ MSS ที่คุ้นเคย 1460 ไบต์ ตัวเลขเหล่านี้บรรยายชั้นที่ต่างกันและแลกเปลี่ยนด้วยกลไกที่ต่างกัน การสับสนเป็นเรื่องง่ายเพราะทั้งคู่วัดเป็นไบต์และทั้งคู่ใกล้ 1500

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

ภาระส่วนเกินภายนอกไปลงที่ไหน

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

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

การจำกัด MSS และจุดที่มันใช้

การจำกัด MSS เขียนค่าซ้ำในเซกเมนต์ SYN ขณะที่มันผ่านจุดที่เลือก ทำให้ปลายทางทั้งสองเลือกเพย์โหลดที่เล็กลงโดยไม่รู้ว่าทำไม บน Linux มันคือเป้าหมายในตาราง mangle ที่ใช้ผ่านกฎที่ชัดเจน และต้อง โดนแพ็กเก็ต SYN ในทิศทางที่คุณต้องการ จำกัดมันไว้ที่อินเทอร์เฟซอุโมงค์และช่วงที่อยู่ เพราะกฎที่กว้างจะเปลี่ยนพฤติกรรมของการจราจรที่ไม่เคยเข้าอุโมงค์

ผลกระทบมีเฉพาะ TCP แอปพลิเคชัน UDP เซสชัน QUIC และโปรโตคอลใดก็ตามที่สร้างดาตาแกรมของตัวเองไม่ได้รับผลกระทบ

วินิจฉัยด้วยเส้นทางที่คงที่

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

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

แต่ละการเปลี่ยนแปลงไม่ได้แก้อะไร

การลด MTU ของอินเทอร์เฟซไม่เปลี่ยน MSS ของเซสชันที่สร้างไว้แล้ว การจำกัด MSS ไม่ช่วยการไหลของ UDP และไม่ซ่อมเส้นทางที่ข้อผิดพลาด ICMP ถูกกรองเพียงทิศทางเดียว การเปลี่ยนแปลงแต่ละอย่างแก้ปัญหาหนึ่งประเภทและปล่อยส่วนที่เหลือไว้เหมือนเดิม

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