MSS clamping trên cổng VPN: nó sửa gì và không sửa gì
Clamping ghi lại MSS trong bắt tay TCP để các phân đoạn vừa với đường hầm. Nó không bao giờ sửa UDP hay kiểm tra path-MTU hỏng. Ba kiểm tra, theo thứ tự.
Các yêu cầu nhỏ hoạt động, các lượt tải lớn bị treo, và ai đó đề xuất MSS clamping. Đề xuất đó đúng đủ thường xuyên để đáng thử theo đúng thứ tự, và sai đủ thường xuyên để mất cả buổi chiều nếu áp dụng mù quáng. Ba kiểm tra dưới đây tách một vấn đề kích thước TCP thực sự khỏi vấn đề UDP, khỏi việc phát hiện path-MTU bị hỏng, và khỏi một clamp không bao giờ nhìn thấy cuộc bắt tay mà nó phải ghi lại.
Bắt đầu từ hình dạng của lỗi
Lỗi kích thước có một chữ ký: kết nối được thiết lập, xác thực và các phản hồi nhỏ thành công, rồi một lượt truyền dừng vô hạn ngay khi cần một phân đoạn kích thước đầy đủ. Những trang tải được văn bản nhưng không bao giờ hoàn tất hình ảnh là cùng lỗi đó ở quy mô nhỏ hơn. Nếu không có gì kết nối được, vấn đề nằm sớm hơn trên đường đi và clamping sẽ không giúp gì. Một clamp không thể sửa cuộc bắt tay chưa từng đến.
Chữ ký tồn tại vì cuộc bắt tay là nơi thỏa thuận kích thước phân đoạn. Mỗi bên quảng bá kích thước phân đoạn tối đa như một tùy chọn TCP, và bên gửi tôn trọng quảng bá của đối tác. Nếu đường đi không chở được phân đoạn lớn như vậy, lỗi xuất hiện muộn hơn, khi bên gửi cuối cùng thử một cái.
Giữ tầng vận chuyển trong tầm mắt khi đọc triệu chứng đó. Clamping là ghi lại một tùy chọn TCP, nên một cuộc gọi thoại hay video bị treo dưới cùng đường hầm không phải vấn đề MSS và sẽ không khá hơn nhờ nó. Ghi lại tầng vận chuyển trước khi chạm vào tùy chọn TCP.
Định giá đường đi, rồi so sánh với đường hầm
Hai con số quan trọng và chúng thường bị nhầm lẫn. path-MTU là gói lớn nhất mà đường đi chở được mà không phân mảnh, và MSS được quảng bá cho IPv4 là giá trị đó trừ 40 byte tiêu đề IP và TCP, hoặc trừ 60 cho IPv6. Đóng gói đường hầm tiêu thụ một phần ngân sách trước khi gói bên trong bắt đầu.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20Ping với bit do-not-fragment cho biết gói có kích thước tải trọng đó có sống sót hay không; điều chỉnh kích thước cho đến khi nó thất bại và bạn đã tìm ra giới hạn đường đi bằng thực nghiệm. Đầu ra của tracepath báo cáo MTU được phát hiện dọc tuyến, nhanh hơn khi nó hoạt động và kém tin cậy hơn khi một chặng trung gian lọc các đầu dò.
Bây giờ trừ đi chi phí của đường hầm. Một tiêu đề IP ngoài, một tiêu đề UDP và một tiêu đề riêng cho đường hầm đều lấy từ cùng 1500 byte, nên MTU bên trong khả dụng trên một nền Ethernet điển hình thấp hơn mức liên kết vật lý gợi ý. Nếu MTU bên trong tính toán thấp hơn mức các đối tác quảng bá, bạn đã tìm ra ứng viên clamp thực sự chứ không phải phỏng đoán. Nếu giá trị tính toán đã cao hơn quảng bá của đối tác, hãy dừng ở đây và tìm nơi khác.
Đặt clamp ở nơi cuộc bắt tay đi qua
Clamp hoạt động bằng cách ghi lại tùy chọn MSS trong các gói SYN và SYN-ACK khi chúng đi qua cổng. Nếu quy tắc nằm trên một giao diện mà không hướng nào đi qua, quá trình thương lượng kết thúc không đổi và triệu chứng vẫn còn, vì thế vị trí quyết định kết quả nhiều hơn giá trị.
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
Hướng là nửa còn lại. Clamp một hướng sửa được nửa số luồng và để phần còn lại thất bại theo cách trông có vẻ ngắt quãng, nên hãy áp dụng cho cả hai hướng của lưu lượng được chuyển tiếp. Dạng Linux cổ điển cho giao diện đường hầm là một quy tắc mangle khớp với gói SYN:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuHãy để ý --clamp-mss-to-pmtu thực sự làm gì: nó lấy giá trị từ MTU của tuyến, mà không phải lúc nào cũng là ngân sách tải trọng thực của đường hầm. Trên một đường hầm dựa trên tuyến nơi tuyến bên trong và đường đi bên ngoài khác nhau, một giá trị rõ ràng được tính trong lần kiểm tra trước dễ dự đoán hơn giá trị tự động.
Xác minh bằng kết nối mới, và giữ phản hồi còn sống
Một kết nối đã thiết lập giữ MSS đã thương lượng, nên kiểm tra trên cùng phiên không chứng minh được gì. Mở một kết nối mới sau thay đổi và đọc giá trị đã thương lượng trực tiếp thay vì suy ra từ một lượt truyền tình cờ hoàn tất.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSLệnh đầu tiên báo cáo MSS của socket cùng trạng thái tắc nghẽn, đây là xác nhận nhanh nhất rằng clamp đã có hiệu lực. Lệnh thứ hai xác nhận rằng quy tắc bạn nghĩ đã thêm chính là quy tắc tồn tại, trong bảng nơi nó được đặt.
Sau đó bảo vệ cơ chế mà bạn không sửa. Phát hiện path-MTU phụ thuộc vào việc các thông điệp ICMP fragmentation-needed đến được bên gửi, nên một tường lửa loại bỏ chúng sẽ tiếp tục phá các lượt truyền lớn ngay cả khi đã có clamp đúng. Cho phép những thông điệp đó cho đường đi của đường hầm, hoặc chấp nhận rằng clamping đang bù đắp cho một chính sách bạn đã chọn.
Cuối cùng, hãy chống lại cám dỗ coi clamp như một núm chỉnh. Nó giới hạn kích thước phân đoạn, điều này tốn thông lượng trên những đường đi chưa từng cần đến. Áp dụng sau ba kiểm tra thì đó là sửa chữa có mục tiêu; áp dụng trước tiên thì đó là thay đổi che giấu lỗi gốc và thêm một biến thứ hai vào mọi lần kiểm tra sau. Sự đánh đổi đó đáng làm một cách có chủ đích, không phải mặc định.
Ghi lại path-MTU bạn đã đo, chi phí đường hầm bạn đã trừ, quy tắc bạn đã thêm và MSS bạn thấy sau đó. Bốn con số biến sự cố tiếp theo thành một lần tra cứu thay vì một cuộc điều tra.