วิธีเลือกค่า MTU ให้เหมาะกับ VPN

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

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

MTU คืออะไร ในภาษาง่าย ๆ

MTU ย่อมาจาก maximum transmission unit คือแพ็กเก็ตที่ใหญ่ที่สุด วัดเป็นไบต์ ที่ลิงก์เครือข่ายหนึ่งส่งผ่านได้ในก้อนเดียว ค่าคลาสสิกบน Ethernet และ Wi-Fi ในบ้านส่วนใหญ่คือ 1500 ไบต์ แพ็กเก็ตที่ขนาดอยู่ในขีดจำกัดจะผ่านไป แพ็กเก็ตที่ใหญ่เกินต้องถูกแบ่งเป็นชิ้นย่อย หรือไม่ก็ถูกทิ้ง

ทุกแพ็กเก็ตมีส่วนหัว คือส่วนหัว IP ตามด้วยส่วนหัว TCP หรือ UDP แล้วจึงถึงข้อมูลของคุณ พื้นที่เหลือสำหรับข้อมูลจึงน้อยกว่า MTU เมื่อมี VPN แพ็กเก็ตเดิมของคุณจะถูกห่อไว้ในแพ็กเก็ตใหม่ ตัวห่อเพิ่มส่วนหัวของตัวเองและภาระจากการเข้ารหัส ดังนั้นแพ็กเก็ตด้านในต้องเล็กกว่า 1500 เพื่อให้แพ็กเก็ตด้านนอกยังอยู่ใน 1500

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

แนวคิดการแบ่งชิ้นของ Internet Protocol อธิบายไว้ในข้อกำหนด IP และวิธีมาตรฐานในการหาขนาดสูงสุดที่ใช้ได้ตลอดเส้นทางอธิบายไว้ใน Path MTU Discovery

ทำไมค่าผิดจึงเกิดอาการแปลก ๆ

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

เพราะแพ็กเก็ตเล็กยังผ่านได้ อาการจึงดูสุ่ม

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

รูปแบบนี้ต่างจากVPN ที่เชื่อมต่อแล้วแต่ไม่มีอินเทอร์เน็ตเลย ซึ่งไม่มีอะไรโหลด ส่วนกรณี MTU บางอย่างโหลดได้และบางอย่างไม่ได้

ส่วนหัวเพิ่มมาจากไหน

ปริมาณส่วนหัวที่เพิ่มขึ้นแน่นอนเท่าไรขึ้นกับเทคโนโลยี VPN ว่าใช้ IPv4 หรือ IPv6 เป็นฐาน และวิ่งบน UDP หรือ TCP โดยทั่วไป อุโมงค์เพิ่มราว 40 ถึง 100 ไบต์ต่อแพ็กเก็ต ส่วนหัว IPv6 ใหญ่กว่า IPv4 ตามที่ระบุไว้ในข้อกำหนด IPv6 อุโมงค์บน IPv6 จึงมักเหลือที่ว่างน้อยกว่า

ลิงก์	ขีดจำกัดด้านนอกโดยทั่วไป	ที่ว่างโดยประมาณหลังหักส่วนหัวอุโมงค์
Ethernet หรือ Wi-Fi	1500	ราว 1400 ถึง 1460
อินเทอร์เน็ตบ้านแบบ PPPoE	1492	ราว 1390 ถึง 1450
เครือข่ายมือถือ	มักอยู่ที่ 1400 ถึง 1500	ราว 1300 ถึง 1420
เครือข่ายโรงแรมหรือออฟฟิศที่มีการห่อเพิ่ม	แตกต่างกัน	ต้องวัดเอง

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

ขั้นที่ 1 วัดแพ็กเก็ตใหญ่สุดที่เครือข่ายของคุณรับได้

การทดสอบใช้ ping พร้อมแฟลก "ห้ามแบ่งชิ้น" คุณส่งแพ็กเก็ตขนาดเพิ่มขึ้นเรื่อย ๆ เมื่อแพ็กเก็ตใหญ่เกิน คำตอบจะบอกว่าต้องแบ่งชิ้น ข้อมูล (payload) ที่ใหญ่ที่สุดที่ผ่าน บวก 28 ไบต์ของส่วนหัว (20 สำหรับ IP และ 8 สำหรับ ICMP) คือ path MTU ของคุณ

ทดสอบตอนไม่มี VPN ก่อน เลือกที่อยู่สาธารณะที่ตอบ ping อย่างเสถียร

Windows (Command Prompt)

ping -f -l 1472 ADDRESS

macOS

ping -D -s 1472 -c 4 ADDRESS

Linux

ping -M do -s 1472 -c 4 ADDRESS

หากได้คำตอบปกติ แปลว่า 1472 ผ่าน และ 1472 + 28 = 1500 คือ MTU หากเจอข้อความอย่าง "Packet needs to be fragmented but DF set" (Windows) หรือ "message too long" (macOS และ Linux) ให้ลดขนาดแล้วลองใหม่

ใช้วิธีค้นหาง่าย ๆ เริ่มที่ 1472 ลดทีละ 10 จนผ่าน แล้วเพิ่มทีละ 1 เพื่อหาขอบที่แน่นอน

ตัวอย่างบนสาย PPPoE คุณอาจเห็น

• 1472 ไม่ผ่าน
• 1462 ไม่ผ่าน
• 1464 ผ่าน

จากนั้นลอง 1465 และ 1466 จนพบค่าสูงสุดที่ผ่าน สมมติ 1464 คือค่าสุดท้ายที่สำเร็จ path MTU ของคุณคือ 1464 + 28 = 1492

ขั้นที่ 2 วัดตอนเชื่อมต่อ VPN

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

สมมติตอนไม่มี VPN payload ใหญ่สุดคือ 1472 (MTU 1500) และตอนมี VPN ใหญ่สุดคือ 1392

• path MTU ผ่านอุโมงค์ 1392 + 28 = 1420
• ส่วนหัวที่อุโมงค์กินไป 1500 - 1420 = 80 ไบต์

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

ขั้นที่ 3 เลือกค่าที่ปลอดภัย

เอาตัวเลขที่วัดได้แล้วหักส่วนเผื่อเล็กน้อย

• วัดได้ตอนมี VPN 1420
• ส่วนเผื่อ 10 ถึง 20 ไบต์ สำหรับความต่างระหว่างเครือข่าย
• MTU ที่เลือก 1400

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

ช่วงอนุรักษ์นิยมที่พบบ่อยสำหรับอุโมงค์คือ 1380 ถึง 1420 หากอยู่บนเครือข่ายมือถือหรือการเชื่อมต่อที่ห่อสองชั้น บางครั้งต้องใช้ค่าต่ำลง เช่น 1300 ถึง 1350 อย่าเลือกค่าต่ำกว่า 1280 สำหรับทราฟฟิก IPv6 เพราะเป็นขนาดลิงก์ขั้นต่ำที่ IPv6 คาดหวัง

ขั้นที่ 4 ใช้ค่านั้นอย่างระมัดระวัง (เมื่อจำเป็นจริง ๆ เท่านั้น)

ผู้อ่านส่วนใหญ่ควรหยุดแค่การวัด แอปจำนวนมากเลือกค่าที่ดีให้เองอัตโนมัติ และ MTU ที่ตั้งเองผิดอาจก่อปัญหาใหม่

หากแอป VPN ของคุณมีตัวเลือก MTU มักอยู่ในส่วนขั้นสูงหรือส่วนการเชื่อมต่อ ให้คงค่าเริ่มต้นไว้เว้นแต่มีอาการ หากจะเปลี่ยน ให้ทำตามกฎเหล่านี้

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

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

การเปลี่ยน MTU ของอะแดปเตอร์เครือข่ายทั้งเครื่องเป็นการทำงานขั้นสูงกว่า บน Windows ทำผ่าน netsh interface ipv4 set subinterface ด้วยสิทธิ์ผู้ดูแลระบบ และบน Linux ผ่าน ip link set dev NAME mtu VALUE การเปลี่ยนเหล่านี้กระทบทราฟฟิกทั้งหมดของอะแดปเตอร์นั้น และบางอย่างหายไปหลังรีสตาร์ต ทำเมื่อเข้าใจวิธีย้อนกลับแล้วเท่านั้น

ขั้นที่ 5 ตรวจสอบผล

หลังเลือกค่า ให้ยืนยันว่าแก้ปัญหาเดิมได้

1. เชื่อมต่อ VPN ใหม่
2. เปิดเว็บที่เคยค้าง หรือเริ่มอัปโหลดใหม่
3. รัน ping ขนาดใหญ่สุดอีกครั้ง โดย payload เท่ากับ MTU ที่เลือกลบ 28 ควรผ่าน
4. ลอง payload ที่ใหญ่กว่า 10 ไบต์ ควรไม่ผ่าน เพื่อยืนยันว่าคุณอยู่ใกล้ขีดจำกัด
5. ทดสอบบนเครือข่ายที่สอง เช่นเน็ตมือถือ เพื่อดูว่าค่านั้นยังใช้ได้

สถานการณ์ตัวอย่าง

ผู้ใช้ที่บ้านบน PPPoE ไลน์ไฟเบอร์ของลินาใช้ PPPoE ดังนั้น path MTU ปกติคือ 1492 เมื่อเปิด VPN payload ใหญ่สุดที่ผ่านคือ 1372 เส้นทางอุโมงค์จึงเท่ากับ 1372 + 28 = 1400 เว็บธนาคารค้างที่ขั้นล็อกอินสุดท้าย เธอเลือก 1380 เชื่อมต่อใหม่ แล้วเว็บทำงานจบ ค่านี้ต่ำกว่าที่วัดได้เพียง 20 ไบต์ และไม่เสียอะไรที่เธอรู้สึกได้

นักเดินทางบน Wi-Fi โรงแรม แล็ปท็อปของโกฟีใช้ได้ดีที่บ้าน แต่ที่โรงแรมแพ็กเก็ตใหญ่สุดที่ผ่านโดยไม่มี VPN คือ 1450 เพราะเครือข่ายโรงแรมห่อทราฟฟิกเอง เมื่อมี VPN เขาวัดได้ 1370 ได้ path MTU 1398 ค่าเริ่มต้น 1420 จะสูงไปในที่นี้ ซึ่งอธิบายว่าทำไมการอัปโหลดค้าง เขาลดค่าสำหรับทริปนั้น แล้วคืนค่าเริ่มต้นเมื่อกลับบ้าน

คนทำงานระยะไกลบนฮอตสปอตมือถือ มายด์แชร์เน็ตมือถือจากโทรศัพท์ แพ็กเก็ตใหญ่สุดที่ผ่านโดยไม่มี VPN คือ 1400 เมื่อมี VPN คือ 1320 เส้นทางจึงเป็น 1348 ค่าใกล้ 1330 ใช้ได้ และเธอจดไว้ว่าเครือข่ายมือถือมักต้องการค่าต่ำกว่าสายประจำที่

ข้อผิดพลาดและข้อจำกัด

• ลืมส่วนหัว 28 ไบต์ payload ที่ทดสอบไม่ใช่ MTU ให้บวก 28 สำหรับ IPv4 กับ ICMP
• ทดสอบที่อยู่เดียว ปลายทางต่างกันอาจใช้เส้นทางต่างกัน ให้ยืนยันด้วยที่อยู่ที่สอง
• เลือกเลขที่วัดได้เป๊ะ ๆ ควรเผื่อ 10 ถึง 20 ไบต์
• ตั้ง MTU ต่ำเกินไป "เพื่อความปลอดภัย" ค่า 1000 มักใช้ได้แต่สิ้นเปลืองและทำให้การถ่ายโอนใหญ่ช้าลง
• ไม่คำนึงว่า ping อาจถูกบล็อก บางเครือข่ายทิ้ง ICMP หากทุกการทดสอบล้มเหลวแม้ขนาดเล็กจิ๋ว แปลว่าปลายทางหรือเครือข่ายไม่ตอบ ping เลย ให้ใช้ที่อยู่อื่น
• มอง MTU เป็นสาเหตุของทุกอาการช้า หากหน้าเว็บโหลดครบแต่ช้า ให้อ่านทำไม VPN ช้าแทน
• ใช้การแก้ไขเดียวกับทุกเครือข่าย ค่าที่ปรับให้ Wi-Fi โรงแรมอาจผิดที่บ้าน

การปรับการตั้งค่าของโพรโทคอลเพื่อปริมาณงานเป็นอีกหัวข้อหนึ่ง ดูการปรับแต่งประสิทธิภาพ OpenVPN และมันอาจมีผลร่วมกับ MTU จึงควรเปลี่ยนทีละอย่าง

สรุป

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

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