OpenVPN mssfix: vì sao một máy khách bị kẹt khi truyền tệp lớn
mssfix viết lại kích thước phân đoạn TCP được quảng bá bên trong đường hầm. Nó không thay đổi kích thước UDP, và giá trị chỉ có nghĩa như phiên bản của bạn nói.
Một máy tính xách tay bị kẹt khi tải lên qua đường hầm trong khi mọi thiết bị khác trên cùng máy chủ vẫn hoạt động. Mẫu đó chỉ ra một đường đi, không phải cấu hình máy chủ, và đó là lối vào thông thường cho câu hỏi mssfix. Tùy chọn này có thể giúp, nhưng chỉ với các kết nối TCP mà nó thực sự viết lại. Biết phạm vi của nó giúp bạn không thay đổi một máy chủ đang hoạt động chỉ để cứu một máy khách.
Tùy chọn viết lại những gì
mssfix chỉnh sửa kích thước phân đoạn tối đa được quảng bá trong các bắt tay TCP đi qua đường hầm, để phía gửi chọn các phân đoạn vừa với ngân sách đóng gói. Nó tác động lên bắt tay, nghĩa là một kết nối được mở trước thay đổi vẫn giữ giá trị đã thương lượng.
Nó không thu nhỏ datagram UDP và không đặt MTU của đường hầm. Hai vấn đề khác nhau tạo ra cùng một triệu chứng: một bên gửi TCP bỏ qua giới hạn đường đi, và một đường đi âm thầm bỏ các gói lớn ở bất kỳ kích thước nào. mssfix xử lý cái đầu tiên và không làm gì cho cái thứ hai.
Sự khác biệt đó giải thích các thử nghiệm đáng thất vọng. Đặt giá trị nhỏ hơn trên một đường đi có lỗ đen làm thay đổi kích thước phân đoạn nhưng không thay đổi việc bỏ gói theo sau, nên truyền tải thất bại ở một điểm khác.
Phạm vi là TCP bên trong đường hầm
Chỉ lưu lượng TCP được viết lại. Một phiên QUIC, trò chơi hoặc ứng dụng gửi datagram UDP lớn sẽ giữ kích thước gói của riêng nó, và nếu đó là những truyền tải bị kẹt, cách khắc phục nằm ở MTU của đường hầm hoặc đường đi thì đúng hơn. Hãy đọc xem truyền tải thất bại dùng giao thức nào trước khi chọn một tùy chọn TCP, vì tầng sai có cách khắc phục riêng.
Hướng cũng quan trọng. Cài đặt phía máy khách ảnh hưởng đến lưu lượng mà máy khách đó gửi vào đường hầm, trong khi máy chủ bao phủ các luồng mà nó chuyển tiếp về phía máy khách. Nếu chỉ các bản tải xuống đi vào bị kẹt, giá trị phía máy khách không phải là toàn bộ câu chuyện.
Con số và từ khóa không di động được
Phiên bản cộng đồng của OpenVPN 2.6 chấp nhận một từ khóa tùy chọn sau giá trị. Với mtu, con số mô tả kích thước gói bên ngoài bao gồm các tiêu đề IP và UDP; không có nó, đối số theo một quy ước tính khác. Vì vậy một dòng được sao chép giữa các phiên bản không mô tả cùng ngân sách gói. Hãy xem trang hướng dẫn đi kèm với bản dựng bạn thực sự chạy, thay vì một hướng dẫn cho bản phát hành khác.
Cú pháp trông như sau:
mssfix 1400 mtu
Coi 1400 là ký tự giữ chỗ, không phải khuyến nghị cho đường đi của bạn. Suy ra giá trị từ đường đi đã đo và từ việc đóng gói thực tế đang dùng, và nhớ rằng máy khách trên phiên bản cũ hơn hoặc các triển khai khác có thể từ chối hoặc diễn giải từ khóa theo cách khác.
Trước tiên hãy xác nhận trên một máy khách
Đo đường đi từ máy bị lỗi trước khi thay đổi bất cứ điều gì. Tải trọng mà đường đi có thể mang mà không phân mảnh chính là con số bạn đang tìm:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1
Lần thử đầu tiên vừa với gói 1500 byte khi thêm 28 byte tiêu đề. Nếu nó thất bại với lỗi phân mảnh và cái nhỏ hơn thành công, kích thước dùng được nằm đâu đó giữa hai giá trị, và chi phí phụ của đường hầm được trừ từ trên xuống.
Sau đó lặp lại truyền tải đã bị kẹt trên một kết nối mới và so sánh. Nếu máy khách duy nhất cải thiện trong khi những máy khác không bị ảnh hưởng, bạn đã tìm ra phạm vi của vấn đề. Nếu mọi máy khách đều bị kẹt, giá trị phía máy chủ là thứ cần xem xét. Không kết quả nào trong hai kết quả đó biện minh cho việc thay đổi trên phần cứng chưa bao giờ nằm trên đường đi bị lỗi.