OpenVPN: Làm thế nào để giảm thiểu các vấn đề MTU đường dẫn trên cơ sở mỗi khách hàng?

Chúng tôi có hàng tá thiết bị nhúng được cài đặt tại khách hàng, tất cả gọi về nhà với dịch vụ OpenVPN của chúng tôi. Điều đó nói chung hoạt động tốt, nhưng một số khách hàng của chúng tôi có vấn đề MTU nghiêm trọng. Ảnh hưởng của chúng tôi đối với khách hàng để sửa mạng của họ bị hạn chế, vì vậy chúng tôi cần OpenVPN để giải quyết. Tóm lại, câu hỏi của tôi là:

Làm cách nào tôi có thể giảm thiểu MTU đường dẫn thấp của một số khách hàng trên cơ sở mỗi khách hàng, nghĩa là không sử dụng cài đặt toàn cầu trong trường hợp xấu nhất cho tất cả khách hàng

Lưu ý rằng trường hợp xấu nhất của chúng tôi khá tệ: đường dẫn MTU 576, loại bỏ tất cả các mảnh vỡ, không phải là mảnh vỡ, không tôn trọng DF-bit. Bạn thấy tại sao tôi không muốn giải quyết vấn đề này trên toàn cầu.

Trang chủ OpenVPN cung cấp một số tùy chọn liên quan đến MTU, đáng chú ý nhất --link-mtu, --tun-mtu, --fragment and --mssfix. Nhưng nó cũng nói

--link-mtu [...] Tốt nhất không nên đặt tham số này trừ khi bạn biết bạn đang làm gì.

--tun-mtu [...] Tốt nhất là sử dụng các tùy chọn --fragment và / hoặc --mssfix để xử lý các vấn đề kích thước MTU.

Vì vậy, tôi bắt đầu thử nghiệm --fragmentvà --mssfixsớm phải nhận ra rằng ít nhất cái trước phải được đặt không chỉ phía máy khách, mà cả phía máy chủ . Sau đó tôi đã xem xét cấu hình trên mỗi máy khách phía máy chủ thông qua --client-config-dirnhưng nó nói

Các tùy chọn sau là hợp pháp trong ngữ cảnh dành riêng cho khách hàng: --push, --push-reset, --iroute, --ifconfig-push và --config.

Không đề cập đến các tùy chọn MTU!

Vì vậy, đây là câu hỏi cụ thể hơn của tôi:

Tại sao chính xác là link-mtuvà tun-mtunản lòng? Các vấn đề tiềm năng với các tùy chọn này là gì? Lưu ý rằng tôi khá thoải mái với munging tiêu đề IP cấp thấp.
Lựa chọn nào trong số các tùy chọn link-mtu tun-mtu fragment mssfixphải được nhân đôi ở phía máy chủ để hoạt động?
Những tùy chọn link-mtu tun-mtu fragment mssfixcó thể được sử dụng trong client-config-dir?
Trong trường hợp cả bốn tùy chọn phải được nhân đôi phía máy chủ và không thể được sử dụng bên trong client-config-dir: Có cách nào khác để chống lại MTU đường dẫn thấp cho mỗi máy khách không?

Ghi chú:

Một phần câu hỏi của tôi đã được hỏi 5 năm trước đây , nhưng chúng chưa thực sự được trả lời sau đó, do đó tôi dám sao chép chúng.
Máy chủ OpenVPN hiện là 2.2.1 trên Ubuntu 12.04. Chúng tôi đang chuẩn bị nâng cấp lên 2.3.2 trên Ubuntu 14.04
Các máy khách OpenVPN là 2.2.1 trên Debian 7.6
Tôi rất vui khi tự mình xác định đường dẫn của khách hàng - MTU
Hiện tại chúng tôi không thể kiểm tra nhiều phía máy chủ. Nhưng chúng tôi đang xây dựng một giường thử nghiệm hoàn toàn riêng biệt, nên sẵn sàng sớm.

Tôi biết ơn vì bất kỳ lời khuyên hữu ích.

ip openvpn mtu ip-fragmentation

— Nils Toedtmann
nguồn

576? Kính gửi gawd. Tôi chưa thấy một MTU nào thấp kể từ những ngày quay số. Đó có phải là đi qua một liên kết nối tiếp cổ đại?

— Michael Hampton

Bạn có thể chạy hai máy chủ OpenVPN không? Có lẽ bạn có thể chạy cả hai máy chủ trên cùng một địa chỉ IP công cộng và sử dụng chuyển tiếp cổng (hoặc chính sách định tuyến) để hướng máy khách đến một máy chủ OpenVPN khác tùy thuộc vào việc chúng có trên mạng có vấn đề hay không (như được xác định bởi danh sách máy khách Các địa chỉ IP).

— kasperd

@MichaelHampton Tôi cũng thắc mắc. Đó là> 600kbit / s và RTT ~ 30ms, không giống như nối tiếp cổ xưa đối với tôi. Cho rằng họ có các cài đặt ngu ngốc khác (ví dụ: không phản hồi với DF với 'phân mảnh cần thiết'), tôi đoán đây chỉ là một cài đặt khác. Chúng tôi nói với họ, nhưng chưa nghe thấy gì.

— Nils Toedtmann

@kasperd ý tưởng thú vị. Tôi có thể chạy nhiều phiên bản máy chủ OpenVPN. Sẽ phải có khoảng 3 hoặc 4, cho các phạm vi MTU khác nhau. NAT cho mỗi máy khách phía máy chủ sẽ không hoạt động (tôi không thể dự đoán địa chỉ IP của máy khách công cộng động), nhưng tôi sẽ phải thay đổi cấu hình máy khách cho các cài đặt MTU (chính xác?), Vì vậy tôi chỉ cần cấu hình thẳng các cổng khác nhau vào khách hàng - Nhưng nó sẽ là một cơn ác mộng bảo trì mà tôi muốn tránh!

— Nils Toedtmann

@NilsToedtmann Bạn sẽ sử dụng tiêu chí nào để phát hiện khách hàng nào bị ảnh hưởng? Một cách tiếp cận khác có thể là chạy tập lệnh trên máy chủ sau khi máy khách được kết nối. Tập lệnh có thể cố gắng ping địa chỉ IP của máy khách với các kích cỡ gói khác nhau để tìm ra cái nào hoạt động và cái nào không. Sau đó, nó có thể chèniptables các quy tắc để giảm MSS trên tất cả các gói SYN đến hoặc từ địa chỉ IP của máy khách đó.

— kasperd

Tôi đã giải quyết vấn đề ở phía máy khách bằng cách thêm tùy chọn mssfix 1300vào tệp cấu hình.

Từ trang người đàn ông openvpn:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

Ý tưởng ban đầu cho giải pháp của tôi đến từ Personalvpn.org

— Oz123
nguồn

Vì vậy, chỉ mssfixcó thể được đặt phía khách hàng? Vâng, đó là một cái gì đó ít nhất. Nó không giúp ích gì với các gói UDP (đó là lý do tại sao tôi quan tâm đến các tùy chọn khác, nhưng ít nhất cũng fragmentcần phải đặt phía máy chủ)

— Nils Toedtmann 22/12/14

mssfix có thể được thêm vào máy chủ cũng như máy khách. Tuy nhiên, giá trị nhỏ hơn sẽ được sử dụng trong đàm phán

— Ahmed

Do thiếu câu trả lời, tôi hiện đang đăng một giải pháp không mấy thanh lịch, nhưng đơn giản: Chạy một phiên bản OpenVPN khác trên TCP cho "khách hàng xấu"

proto tcp

và hạ thấp MSS TCP trên máy khách, vd

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Một lợi thế của giải pháp này là mỗi khách hàng có thể thiết lập MSS riêng của mình.

Điều này được thừa nhận là TCP-over-TCP, nhưng đó sẽ hoạt động đủ tốt trong nhiều tình huống .

Lưu ý rằng tôi vẫn rất quan tâm đến các giải pháp không yêu cầu proto tcpvà tôi sẽ đánh dấu chúng là câu trả lời hợp lệ nếu chúng ít nhiều đáp ứng các yêu cầu được phác thảo của tôi.

— Nils Toedtmann
nguồn