MTU อาจเป็นตัวการหนึ่งที่ทำให้เปิดเว็บด้วย HTTPS ไม่ได้หรือทำให้ SSH มีปัญหา

เมื่อไม่นานมานี้พบปัญหาแปลก ๆ จึงอยากนำมาเล่าให้ฟัง เผื่อว่าจะมีใครที่ประสบปัญหาแบบเดียวกัน กล่าวคือ

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

14 3.606058 192.168.2.40 172.19.11.201 TCP 50299 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460
15 3.632964 172.19.11.201 192.168.2.40 TCP https > 50299 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
16 3.633040 192.168.2.40 172.19.11.201 TCP 50299 > https [ACK] Seq=1 Ack=1 Win=17520 Len=0
17 3.634069 192.168.2.40 172.19.11.201 TLSv1 Client Hello
18 3.656962 172.19.11.201 192.168.2.40 TCP https > 50299 [ACK] Seq=1 Ack=156 Win=6432 Len=0
19 3.657954 172.19.11.201 192.168.2.40 TLSv1 Server Hello, Change Cipher Spec, Encrypted Handshake Message
20 3.658415 192.168.2.40 172.19.11.201 TLSv1 Change Cipher Spec, Encrypted Handshake Message
21 3.716979 172.19.11.201 192.168.2.40 TCP https > 50299 [ACK] Seq=139 Ack=215 Win=6432 Len=0
23 3.831394 192.168.2.40 172.19.11.201 TLSv1 Application Data
24 3.853861 172.19.11.201 192.168.2.40 TCP https > 50299 [ACK] Seq=139 Ack=988 Win=7730 Len=0
25 3.854788 172.19.11.201 192.168.2.40 TLSv1 Application Data
26 3.892225 192.168.2.40 172.19.11.201 TLSv1 Application Data
27 3.946367 172.19.11.201 192.168.2.40 TCP https > 50299 [ACK] Seq=400 Ack=1681 Win=9276 Len=0
28 3.967382 172.19.11.201 192.168.2.40 TLSv1 Application Data
29 4.165452 192.168.2.40 172.19.11.201 TCP 50299 > https [ACK] Seq=1681 Ack=677 Win=16844 Len=0
30 4.177008 172.19.11.201 192.168.2.40 TLSv1 [TCP Retransmission] Application Data
31 4.177030 192.168.2.40 172.19.11.201 TCP [TCP Dup ACK 29#1] 50299 > https [ACK] Seq=1681 Ack=677 Win=16844 Len=0 SLE=400 SRE=677

นั่นคือ จะพบว่าเกิด TCP Retransmission ทุกครั้งที่เปิดใช้งานเว็บด้วย HTTPS จากวิทยาเขตหาดใหญ่ไปยังอุปกรณ์ตัวนั้น

2. เมื่อ SSH ไปยังอุปกรณ์ดังกล่าว พบว่าพอใช้งานไประยะหนึ่ง (ไม่แน่ไม่นอน) จะพบว่าเกิดอาการค้าง เหมือนไม่มีการตอบสนองใด ๆ จากอุปกรณ์ แต่เมื่อตรวจสอบดูจะพบว่า Connection ก็ยังเชื่อมต่ออยู่ หากตรวจสอบด้วยการ Dump แพ็คเกตดูจะได้ข้อมูลในลักษณะนี้

63 21.900739 192.168.2.40 172.19.11.201 SSHv2 Encrypted request packet len=52
64 21.931257 172.19.11.201 192.168.2.40 TCP ssh > 50493 [ACK] Seq=1742 Ack=812 Win=7504 Len=0
65 21.931259 172.19.11.201 192.168.2.40 SSHv2 Encrypted response packet len=52
67 22.129320 192.168.2.40 172.19.11.201 TCP 50493 > ssh [ACK] Seq=812 Ack=1794 Win=16332 Len=0
68 22.157274 172.19.11.201 192.168.2.40 SSHv2 [TCP Retransmission] Encrypted response packet len=52
69 22.157322 192.168.2.40 172.19.11.201 TCP [TCP Dup ACK 67#1] 50493 > ssh [ACK] Seq=812 Ack=1794 Win=16332 Len=0 SLE=1742 SRE=1794
83 26.425253 192.168.2.40 172.19.11.201 SSHv2 Encrypted request packet len=84
84 26.486504 172.19.11.201 192.168.2.40 TCP ssh > 50493 [ACK] Seq=1794 Ack=896 Win=7504 Len=0
85 26.663530 172.19.11.201 192.168.2.40 SSHv2 Encrypted response packet len=120

นั่นคือ จะพบว่าเกิด TCP Retransmission เช่นกัน

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

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

สิ่งที่จะช่วยทำให้เข้าใจปัญหาให้ชัดเจนขึ้น คือ การหาข้อมูลเกี่ยวกับปัญหาที่เกิดกับ SSL/SSH และ MTU (Maximum Transmission Unit) จนได้ข้อมูลดังนี้

บางครั้งผู้ใช้งานอาจพบปัญหาในการเข้าเว็บที่มีการเข้ารหัส เช่น เว็บในการทำธุรกรรมกับทางธนาคาร หรือ ไม่สามารถใช้งานแอพพลิเคชันบางแอพพลิเคชัน เช่น IPSec หรือ VPN อาจมีสาเหตุมาจาก Packet Fragmentation

Packet Fragmentation จะเกิดขึ้นเมื่อแพ็คเกตข้อมูลที่ส่งออกไปมีขนาดใหญ่เกินไป และเราเตอร์ที่อยู่ในเส้นทางที่แพ็คเกตผ่านไป จำเป็นต้องแบ่งแพ็คเกตให้มีขนาดเล็กลงเพื่อที่จะสามารถส่งแพ็คเกตไปถึงปลายทางได้

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

โปรโตคอลเข้ารหัสโดยทั่วไปจะไม่ทำ Fragmentation ด้วยเหตุผลเรื่องของความปลอดภัยของการเข้ารหัสข้อมูล ดังนั้นเมื่ออุปกรณ์ส่งข้อมูลโดยใช้ SSL หรือ SSH ก็จะทำการเซ็ตบิต DF - Do not fragment เป็น 1 เพื่อไม่ให้มีการทำ Fragmentation

ด้วยเหตุนี้อุปกรณ์ที่วิทยาเขตภูเก็ตซึ่งถูกติดต่อด้วย HTTPS และ SSH จะทำการเซ็ตบิต DF เป็น 1 ให้กับแพ็คเกตข้อมูลที่ส่งกลับมา เมื่อแพ็คเกตเดินทางมาถึงเราเตอร์วิทยาเขตภูเก็ตซึ่งมีการเซ็ตค่า MTU เป็น 1420 ก็จะไม่สามารถส่งต่อไปได้ เราเตอร์จะทิ้งแพ็คเกตและส่ง ICMP กลับมาที่อุปกรณ์เพื่อบอกให้อุปกรณ์ปรับค่า MTU และส่งข้อมูลกลับมาใหม่

สิ่งที่ยืนยันความเข้าใจนี้คือ เราเตอร์วิทยาเขตภูเก็ตมีการส่ง ICMP Type=3 Code=4 กลับมาที่อุปกรณ์ เพื่อบอกให้ทราบแพ็คเกตข้อมูลที่ส่งมานั้นจำเป็นต้องทำ Fragmentation แต่บิต DF ถูกเซ็ตเอาไว้ ดังผลลัพธ์ที่ได้จากการ Debug ICMP บนเราเตอร์ในขณะที่ทดสอบเปิดเว็บด้วย HTTPS ไปยังอุปกรณ์

*0.1736590860 capricorn IP/8/debug_icmp:
ICMP Send: need fragment-DF set(Type=3, Code=4), Src = 172.19.0.1, Dst = 172.19.11.201; Original IP header: Pro = 6, Src = 172.19.11.201, Dst = 192.168.0.29, First 8 bytes = 00168933 B920D480

*0.1736592540 capricorn IP/8/debug_icmp:
ICMP Send: need fragment-DF set(Type=3, Code=4), Src = 172.19.0.1, Dst = 172.19.11.201; Original IP header: Pro = 6, Src = 172.19.11.201, Dst = 192.168.0.29, First 8 bytes = 00168933 B920D480

จากปัญหาที่พบในครั้งนี้ ทำให้ตระหนักว่า MTU ก็เป็นปัจจัยสำคัญที่มีผลต่อการใช้งานโดยเฉพาะการใช้งานบางแอพพลิเคชันที่จะต้องมีการ Encapsulate แล้วทำให้ขนาดของข้อมูลเพิ่มขึ้น

เอกสารอ้างอิง

http://support.iprimus.com.au/index2.php?option=com_content&task=view&id=352&pop=1&page=0&Itemid=214
http://markmaunder.com/2009/routers-treat-https-and-http-traffic-differently/
http://www.netheaven.com/pmtu.html