ใครเป็นคนเลือก MTU ของ WireGuard: wg-quick เคอร์เนล หรือคุณ

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

มีผู้สมัครสามราย และสับสนได้ง่าย

สามที่ที่ค่าอาจมาจาก

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

ถ้าไม่แน่ใจว่ากรณีใดใช้ ให้อ่าน MTU ก่อน แล้วจึงหาว่าใครเป็นคนเริ่มอินเทอร์เฟซ

ตัดสินจากว่าใครเป็นคนรันอินเทอร์เฟซ

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

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

การคำนวณเริ่มต้นทำอะไร

wg-quick ค้นหาเส้นทางไปยังปลายทางของเพียร์ เอา MTU ของอินเทอร์เฟซขาออกนั้น แล้วหักค่าใช้จ่ายในการห่อหุ้มออก ด้วยเฮดเดอร์ภายนอก IPv4 จะอยู่ที่ราว 60 ไบต์ ส่วน IPv6 ราว 80 ผลลัพธ์ถูกจำกัดเพดานไว้ เพื่อให้เส้นทาง 1500 ไบต์ได้ค่า 1420 แทนค่าที่ใช้ได้กับตระกูลที่อยู่เดียวเท่านั้น นี่เป็นค่าเริ่มต้นที่สมเหตุสมผล ไม่ใช่การวัดเส้นทางของคุณ

มันไม่สามารถรู้เรื่องอุโมงค์ที่เพิ่มมาทีหลัง ลิงก์มือถือ หรือเส้นทาง ICMP ที่ถูกกรอง

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

เมื่อเส้นทางเปลี่ยนไปใต้เท้าคุณ

แล็ปท็อปที่ย้ายจาก Ethernet ไป Wi-Fi แล้วไปฮอตสปอตของโทรศัพท์จะคง MTU ของอินเทอร์เฟซที่เริ่มต้นไว้ เส้นทางภายนอกอาจเล็กลงแล้ว และไม่มีอะไรเจรจากันใหม่ อุโมงค์ซ้อนกันทำให้แย่ลง เพราะแต่ละชั้นหักค่าใช้จ่ายของตัวเองจากงบประมาณเดียวกัน ค่าที่ใช้ได้ในออฟฟิศไม่ใช่ค่าที่ใช้ได้ที่สนามบิน

แฮนด์เชคครั้งล่าสุดพิสูจน์ว่าคีย์ทำงานได้ แต่มันไม่ได้พิสูจน์อะไรเลยว่าแพ็กเก็ตใหญ่จะผ่านได้

ทดสอบทีละตัวเลข

ใช้แอปพลิเคชันและปลายทางเดิม เปลี่ยนค่าหนึ่งค่าแล้ววัด ping -M do -s 1372 ทดสอบแพ็กเก็ต 1400 ไบต์โดยตั้งบิต DF ไว้ และนั่นคือรูปแบบการทดสอบที่คุณต้องการ ถ้าคำขอเล็กผ่านได้แต่คำขอใหญ่ติดขัด คุณมีปัญหาเรื่องขนาด ไม่ใช่เรื่องเส้นทาง

เปลี่ยนเฉพาะ MTU ปรับหลายตัวเลือกของแพ็กเก็ตพร้อมกันจะไม่บอกคุณว่าตัวไหนสำคัญ

และอย่าคาดหวังว่าการเปลี่ยน MTU จะแก้เส้นทางขากลับที่หายไป กฎการส่งต่อ หรือ DNS ที่ล้มเหลว สิ่งเหล่านี้ก็ทำให้เกิดอาการไม่มีทราฟฟิกเช่นกัน และมีการทดสอบของตัวเอง คู่มือ wg-quick อธิบายการเลือกอัตโนมัติไว้