Cải thiện hiệu suất OpenVPN


10

Tôi đã cố gắng cải thiện hiệu suất OpenVPN của mình và đây là thiết lập hiện tại của tôi:

 cat /etc/openvpn/server.conf
port 443 #- port
proto tcp #- protocol
dev tun
#tun-mtu 1500
tun-mtu-extra 32 
#mssfix 1450
tun-mtu 64800
mssfix 1440
reneg-sec 0
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
plugin /etc/openvpn/openvpn-auth-pam.so /etc/pam.d/login
#plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so /etc/pam.d/login #- Comment this line if you are using FreeRADIUS
#plugin /etc/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf #- Uncomment this line if you are using FreeRADIUS
client-to-client
client-cert-not-required
username-as-common-name
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 5 30
comp-lzo
persist-key
persist-tun
status 1194.log
verb 3

KHÁCH HÀNG:

client
dev tun
proto tcp
remote 18.4.26.8 443
resolv-retry infinite
nobind
tun-mtu 64800
tun-mtu-extra 32
mssfix 1440
persist-key
persist-tun
auth-user-pass
comp-lzo
verb 3

Tôi đã thực hiện một số thay đổi đối với MTU và MSSFIX từ những gì tôi tìm thấy trên web.

Có bất kỳ thay đổi hạt nhân nào tôi có thể thực hiện? Đây là hộp CentOS 6.x. Tôi đã tìm thấy một số thứ cho BSD dựa trên nhưng không có gì hoạt động cho Linux.

Tôi biết TCP chậm hơn UDP nhưng tôi cần có khả năng trông giống như lưu lượng SSL để vượt qua tường lửa trên mạng.

Những ý tưởng khác?

PING cho một khách hàng khác trên mạng mà tôi RDP vào.

Pinging 10.8.0.6 with 32 bytes of data:
Reply from 10.8.0.6: bytes=32 time=152ms TTL=128
Reply from 10.8.0.6: bytes=32 time=565ms TTL=128
Reply from 10.8.0.6: bytes=32 time=152ms TTL=128
Reply from 10.8.0.6: bytes=32 time=782ms TTL=128

Ping statistics for 10.8.0.6:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 152ms, Maximum = 782ms, Average = 412ms

Có cách nào để cải thiện hiệu suất hoặc giảm ping không?

EDIT: Việc cài đặt phân mảnh có giúp ích gì không?


I know TCP is slower then UDP but I need to be able to look like SSL traffic to get thru a firewall on the network.Tại sao không yêu cầu quản trị viên mạng của bạn mở cổng openvpn tại nơi làm việc? Trên một lưu ý liên quan, câu hỏi này có thể vi phạm các điều khoản của Câu hỏi thường gặp Licensing, legal advice, and *circumvention of security or policy*tôi sẽ làm rõ.
prateek61

1
Không có gì bất hợp pháp về nó. Đó chỉ là cách duy nhất để truy cập hệ thống của riêng tôi từ xa. :)

2
Tôi đã nói nhiều hơn về việc bỏ qua chính sách tường lửa mọi lúc mọi nơi. Tại sao bạn không thể yêu cầu quản trị viên mở cổng? Tôi đã không thực sự nói về tính hợp pháp, nhiều hơn về việc phá vỡ chính sách bảo mật.
prateek61

Có lẽ ssh mực sẽ làm việc tốt hơn cho bạn cho tcp-over-tcp vpn
ptman

Câu trả lời:


13

Câu trả lời ngắn: vô hiệu hóa comp-lzo.

Tôi nhận ra đây là một bài viết cũ, nhưng tôi cũng đang bị hiệu suất OpenVPN kém. Tôi đã thử tất cả mọi thứ, điều chỉnh MTU, thay đổi bộ đệm snd và RCv, kẹp mss, bạn đặt tên cho nó. Tải CPU không đáng kể.

Trong một ý thích bất chợt, tôi đã vô hiệu hóa nén (loại bỏ comp-lzokhỏi máy khách và máy chủ) và hiệu suất tăng 2-4 lần.

Vì vậy, với comp-lzokích hoạt hiệu suất tối đa của tôi là khoảng 25-30 Mbit / giây và không có nó, tôi đạt 120 Mbit / s (tốc độ kết nối internet của tôi).

Máy chủ là Xeon E5-2650, máy khách là Core i5-3320M. Cả hai đều chạy OpenVPN 2.3.10, AES-256-CBC, SHA512. Intel Chromebook của tôi cũng tăng tối đa tốc độ internet của tôi. Hiệu suất tăng gấp đôi trên các máy khách Android của tôi (14 Mbit / s -> 30 Mbit / s), phù hợp với tốc độ đường hầm IKEv2.


6

TCP sẽ trở nên / nhiều / chậm hơn UDP, do vấn đề TCP-over-TCP . Về cơ bản, TCP dựa vào việc giảm / tắc nghẽn gói để xác định các tham số kết nối và các kết nối TCP-over-OpenVPN của bạn không gặp phải một trong hai kết nối đó. Nhưng bạn đã nói rằng đó không phải là một lựa chọn.

Bạn cũng có thể thử mtu-disctùy chọn tự động khám phá cài đặt MTU tối ưu cho kết nối của mình. Có một số điểm không phù hợp ở những nơi khác nhau, chẳng hạn như cài đặt MTU của OpenVPN bao gồm kích thước của tiêu đề Ethernet. [ 1 ]

tun-mtuCài đặt của bạn rất lớn, vì một gói 65KB sẽ có rất nhiều vấn đề về độ trễ thông qua internet (các gói jumbo IPv4 có kích thước khoảng 9000 byte và chủ yếu hoạt động trên các mạng cục bộ). Thay vào đó, hãy thử một cái gì đó dưới 1460, như 1300, để xem MTU có phải là vấn đề của bạn không.


2
Cảm ơn, điều đó đã giải quyết vấn đề của tôi khi nhận được một truy vấn postgresql để hoạt động trên OpenVPN. Nó hoạt động khi truy vấn trên một cột duy nhất, nhưng không phải cho toàn bộ cột. Rõ ràng đó là do MTU-Size mặc định là 1500. Đặt nó thành 1300 giúp!
Christian Benke

2

Mặc dù điều này có thể hơi muộn, bạn có thể thử những gì tôi đã làm:

loại bỏ tất cả các tùy chọn liên quan đến mss, mtu, v.v.

thực hiện quét cổng tại tổ chức của bạn và chọn cổng UDP, thường phải mở 53 cổng GRE / 123 NDP:

Thêm các dòng này vào cấu hình máy chủ của bạn (tham khảo tại đây )

#possible bandwidth increase
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Tôi không hoàn toàn hiểu các cài đặt này nhưng chúng chắc chắn đã giúp ích, một số người nói rằng nó giúp ích rất nhiều, theo kinh nghiệm của tôi, nó đã tăng thông lượng của tôi lên +/- 30%

Khởi động máy chủ trên một trong những cổng đó và bạn nên truy cập: P

Hi vọng điêu nay co ich!


9
-1 cho quá nhiều vodoo và không hiểu những gì thực sự làm. Tôi thấy thật vô trách nhiệm khi giới thiệu một cái gì đó sau đó, một cách trung thực.
Preexo

0

sndbuf và RCvbuf sửa một cài đặt ANCIENT trong linux / unix / openvpn từ ngày quay số để tối ưu hóa cho các cài đặt chậm hơn mặc dù HĐH được tối ưu hóa cho các cài đặt nhanh hơn

sndbuf / rcvbuf được đặt thành 0 sẽ chỉ sử dụng các cài đặt của HĐH

đẩy được sử dụng để đảm bảo máy khách được đặt đúng nhưng ở đó bạn cần một giá trị.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.