OpenVPN trên PPPoE: giảm link-mtu, tun-mtu hay mssfix?

Ping trả lời, DNS phân giải, và mọi trang cần một phân đoạn kích thước đầy đủ đều bị treo. Trên một đường lên tự thêm phần đóng gói của nó, đường đi âm thầm mất vài chục byte ngân sách, và một hồ sơ viết cho Ethernet sạch vẫn tiếp tục yêu cầu những gói mà đường truyền không thể chở. Kết nối không chậm; nó đang bỏ đi đúng những gói quan trọng.

Ba tùy chọn có thể khắc phục điều này, và chúng hoạt động ở các tầng khác nhau. Chọn sai thì hoặc không làm gì hoặc khiến đường hầm mong manh theo một cách mới, nên lựa chọn bắt đầu từ những gì đường đi thực sự hỗ trợ.

Ba nút vặn, ba tầng khác nhau

link-mtu là ngân sách bên ngoài: tải trọng đã mã hóa cộng với tiêu đề OpenVPN, tiêu đề UDP và tiêu đề IP bên ngoài. Nó mô tả những gì rời khỏi máy, và đó là lý do nó là con số mà đường đi vật lý giới hạn.

tun-mtu là ngân sách bên trong: giao diện mà lưu lượng của bạn nhìn thấy. Nó lớn hơn những gì đường đi có thể chở đúng bằng chi phí phụ trội của đường hầm, và OpenVPN thường tự suy ra nó thay vì buộc bạn đặt nó.

mssfix là một cơ chế hoàn toàn khác. Nó viết lại kích thước phân đoạn tối đa được công bố trong các lần bắt tay TCP, để các đối tác TCP chọn phân đoạn vừa sau khi đóng gói. Nó không thay đổi MTU của giao diện và không có tác dụng gì với UDP.

Nếu bạn đặt link-mtu một cách tường minh, OpenVPN trừ đi chi phí phụ trội của chính nó để suy ra MTU bên trong. Chi phí đó không phải là hằng số cố định; nó phụ thuộc vào mật mã và xác thực, đó là lý do một giá trị sao chép từ diễn đàn có thể sai trên một hồ sơ khác. Đặt cả link-mtu và tun-mtu trao cho máy khách hai chỉ dẫn mâu thuẫn.

Đo đường đi trước khi chọn bất kỳ con số nào

Đo từ giao diện vật lý, không phải từ bên trong đường hầm, và nhớ rằng ping báo cáo tải trọng, không phải kích thước gói. Thêm 28 byte cho các tiêu đề IPv4 và ICMP trước khi so sánh tải trọng với một khung 1500 byte, và ghi nhớ phần hiệu chỉnh đó khi một đối tác báo cáo con số khác.

Trên máy khách Linux, ping -M do -s 1472 cấm phân mảnh và thất bại nếu gói quá lớn. Giảm tải trọng cho đến khi nó đi qua, rồi thêm 28 để có MTU của đường đi. PPPoE tốn 8 byte, nên 1492 là bình thường trên DSL. DS-Lite và một số đường di động tốn 40 hoặc hơn, và câu trả lời thường thấp hơn mức tốc độ danh nghĩa của đường truyền gợi ý.

Nếu mọi kích thước ping đều thành công nhưng các lần truyền lớn vẫn treo, hãy nghi ngờ một lỗ đen thay vì một giới hạn kích thước đơn giản. Một thông báo ICMP về việc cần phân mảnh đang bị lọc ở đâu đó trên đường đi, nên bên gửi không bao giờ học được cách thu nhỏ, và chỉ những luồng cần phân đoạn lớn mới nhận ra.

Hãy giới hạn TCP trước, thu nhỏ đường hầm sau

Các lần bắt tay TCP là thứ duy nhất mà mssfix chạm tới, điều này thường khiến nó là biện pháp ít xâm lấn nhất để thử trước. Đặt nó thấp hơn ngân sách thực của đường đi một chút, gửi cùng giá trị từ máy chủ để hai đầu đồng ý, và thử lại một lần tải xuống lớn. Nếu tình trạng treo biến mất, vấn đề là kích thước phân đoạn TCP, và không cần thay đổi gì khác.

Giảm MTU bên trong khi lưu lượng bị ảnh hưởng không phải TCP. Một dịch vụ UDP, một đường hầm trong đường hầm hoặc một ứng dụng gửi datagram kích thước đầy đủ sẽ tiếp tục thất bại sau khi giới hạn MSS vì không có gì viết lại kích thước gói của nó. Hãy giảm tun-mtu cho trường hợp đó, hoặc đặt link-mtu và để máy khách suy ra giá trị bên trong, nhưng không bao giờ cả hai.

Đừng với tới tùy chọn phân mảnh cũ. Nó chia gói bên trong đường hầm, thêm chi phí phụ trội và đã bị loại bỏ vì những lý do chính đáng; OpenVPN hiện đại mong đợi đường đi được mô tả chính xác.

Tại sao các phép thử nhỏ vẫn hoạt động

Các truy vấn DNS, tiếng vọng ICMP và các lần bắt tay TCP đều thấp hơn nhiều so với kích thước thất bại. Vì thế đường hầm trông khỏe mạnh trong mọi bài kiểm tra nhanh trong khi các lần bắt tay TLS và phản hồi HTTP âm thầm thất bại. Chính sự kết hợp đó, một traceroute hoạt động và một trình duyệt treo ở phản hồi lớn đầu tiên, là dấu hiệu cần tìm. Hãy với tới một phép thử kích thước đầy đủ trước khi với tới một hồ sơ mới.

Xác minh bằng lưu lượng đã thất bại. Tải một trang lớn, gửi một datagram UDP kích thước đầy đủ nếu đó là dịch vụ bị ảnh hưởng, và lặp lại từ một máy khách thứ hai trên một đường lên khác. Ghi lại MTU đường đi đã đo và giá trị bạn đã chọn, vì nếu không người tiếp theo chạm vào hồ sơ sẽ coi con số đó là tùy tiện.

Đừng bao giờ hạ MTU bên trong xuống dưới 1280 khi IPv6 chạy trên đường hầm, vì đó là mức tối thiểu mà mọi liên kết IPv6 phải chở. MTU nhỏ hơn là một sự thật về đường đi, không phải một cài đặt hiệu năng để chỉnh theo cảm giác.