Tình huống: Kết nối 'Ma'Đã bao giờ bạn gặp tình trạng VPN báo 'đã kết nối' nhưng lại không thể thực hiện bất kỳ tác vụ nào chưa? Đó là một trải nghiệm cực kỳ khó chịu. Lệnh ping đến máy chủ phản hồi ngay lập tức. Các truy vấn DNS nhỏ được giải quyết không chút trở ngại. Nhưng ngay khi bạn cố gắng tải một tệp PDF 5MB hoặc truy cập một trang web nặng như Salesforce, trình duyệt cứ xoay vòng vô tận cho đến khi kết nối bị timeout. Đây không phải là sự cố mất mạng hoàn toàn; đây là một điểm nghẽn.
Hành vi này là dấu hiệu điển hình của việc không khớp MTU (Maximum Transmission Unit). Ở đâu đó giữa máy tính của bạn và máy chủ, một đường hầm (tunnel)—có thể là IPsec, GRE, hoặc VXLAN—có dung lượng nhỏ hơn khung Ethernet 1500-byte tiêu chuẩn. Khi một gói tin lớn đi qua đường truyền hẹp đó, router cần phải chia nhỏ nó ra. Tuy nhiên, lưu lượng TCP hiện đại sử dụng bit 'Don't Fragment' (DF) để duy trì hiệu suất. Nếu một gói tin quá lớn và không thể phân mảnh, router sẽ đơn giản là loại bỏ nó và gửi lại một lỗi ICMP.
Nhận diện lỗi: Frag needed and DF setNếu bạn đang theo dõi lưu lượng bằng Wireshark hoặc kiểm tra log của router trong khi xảy ra lỗi, bạn sẽ thấy cảnh báo này:
Frag needed and DF set (mtu = 1450)
Giá trị MTU trong thông báo lỗi cho bạn biết chính xác giới hạn tối đa của chặng tiếp theo. Vì hầu hết lưu lượng web hiện nay coi việc phân mảnh là kẻ thù của hiệu suất, các gói tin sẽ không tự động thu nhỏ lại—chúng biến mất hoàn toàn. Máy tính của bạn sẽ tiếp tục chờ đợi dữ liệu mà router đã vứt bỏ từ lâu.
Tìm điểm nghẽn bằng lệnh PingBạn có thể xác định chính xác điểm gây lỗi bằng bài kiểm tra ping thủ công. Chúng ta thực hiện việc này bằng cách ép buộc một kích thước gói tin cụ thể và cấm phân mảnh. Hãy bắt đầu từ giá trị cao và giảm dần.
Trên Linux:
# Kiểm tra gói tin 1500 byte (1472 payload + 28 headers)
ping -M do -s 1472 8.8.8.8
Trên Windows:
ping -f -l 1472 8.8.8.8
Nếu bạn thấy thông báo 'Packet needs to be fragmented but DF set', hãy giảm kích thước xuống 10 hoặc 20 byte (ví dụ: 1460, 1440, 1400) cho đến khi nhận được phản hồi. Khi bạn tìm thấy con số lý tưởng hoạt động được, hãy cộng thêm 28 vào đó. Kết quả chính là Path MTU của bạn.
Giải pháp: Ba cách để thu hẹp khoảng cách### Cách 1: MSS Clamping (Khắc phục từ phía Router)MSS Clamping là giải pháp thanh lịch nhất nếu bạn quản lý gateway. Nó can thiệp vào quá trình bắt tay TCP ban đầu và 'đánh lừa' cả hai đầu đồng ý với kích thước phân đoạn nhỏ hơn ngay từ đầu. Điều này ngăn chặn việc các gói tin lớn được gửi đi ngay từ đầu.
Trên firewall Linux sử dụng iptables, hãy dùng quy tắc này để tự động căn chỉnh MSS với kết quả khám phá đường truyền của bạn:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Đối với quản trị viên Cisco, hãy áp dụng trực tiếp vào interface tunnel để giới hạn các phân đoạn ở mức 1360 byte (một lựa chọn an toàn cho hầu hết các VPN):
interface Tunnel0
ip tcp adjust-mss 1360
Cách 2: Điều chỉnh MTU của interface cục bộKhi bạn không có quyền kiểm soát phần cứng mạng, bạn phải thay đổi cách máy tính của mình giao tiếp với đường truyền. Việc hạ thấp MTU trên NIC (card mạng) đảm bảo mọi gói tin rời khỏi hệ thống đều vừa vặn với đường truyền.
Trên Linux:
# Xác định interface của bạn và thiết lập MTU về 1400
sudo ip link set dev eth0 mtu 1400
Trên Windows (PowerShell):
# Thiết lập MTU vĩnh viễn cho adapter 'Ethernet' của bạn
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
Cách 3: Ngừng chặn ICMPCơ chế Path MTU Discovery (PMTUD) dựa vào các thông báo ICMP Type 3 Code 4. Nhiều đội ngũ bảo mật thắt chặt firewall quá mức bằng cách chặn mọi lưu lượng ICMP. Nếu bạn chặn các thông báo 'Destination Unreachable' này, bên gửi sẽ không bao giờ biết rằng nó cần thu nhỏ gói tin. Hãy đảm bảo chính sách bảo mật biên của bạn cho phép mã ICMP cụ thể này để mạng có thể tự chữa lành.
Xác minh kết quảSau khi áp dụng bản vá, hãy quay lại bài kiểm tra ping. Nếu bạn đã hạ MTU xuống 1400, một lệnh ping với payload 1372 (1372 + 28 = 1400) bây giờ sẽ chạy thông suốt. Quan trọng hơn, hãy thử một tác vụ nặng về dữ liệu. Việc truyền tệp qua scp hoặc xuất database lớn vốn từng bị treo ở 0% giờ đây sẽ tận dụng được băng thông bình thường.
Bài học rút raCác vấn đề về MTU hầu như luôn xuất phát từ 'overhead của việc đóng gói' (encapsulation overhead). Trong khi Ethernet tiêu chuẩn cung cấp cho bạn 1500 byte, mỗi lớp đường hầm sẽ chiếm dụng một phần dung lượng đó:
- IPsec: Tiêu tốn khoảng 50-70 byte để mã hóa.- VXLAN: Thêm 50 byte overhead.- GRE: Chiếm 24 byte.- PPPoE: Sử dụng 8 byte (phổ biến trong kết nối gia đình DSL/Fiber).Khi thiết kế một VPC mới hoặc liên kết site-to-site, tôi thường sử dụng các công cụ như Subnet Calculator để lập sơ đồ phân cấp mạng sớm. Việc hình dung các khối CIDR và các chồng lấp đường hầm tiềm năng giúp ngăn chặn các vấn đề kết nối 'ma' này trước khi gói tin đầu tiên được gửi đi. Nếu gói tin nhỏ hoạt động nhưng gói tin lớn thất bại, hãy kiểm tra MTU đầu tiên.