SSH đường hầm nhanh hơn OpenVPN, phải không?


21

Về mặt logic, VPN phải nhanh hơn SSH để tạo đường hầm, bởi vì:

  • Nó chạy trên UDP và không phải TCP (vì vậy không có TCP trên TCP)
  • Nó có nén

Tuy nhiên, hôm nay tôi đã thử nghiệm nhân rộng Redis qua cả hai phương pháp.
Tôi đã chạy thử nghiệm trên máy ảo AWS VM của Ireland, kết nối với máy ảo AWS US-East.
Vì trường hợp thử nghiệm của tôi là sao chép Redis, đây chính xác là những gì tôi đã thử nghiệm - tôi đã chạy một máy chủ Redis trống và sau khi tải xong, tôi đã thực hiện slaveofmáy chủ khác và đo thời gian giữa Connecting to MASTERMASTER <-> SLAVE sync: Finished with success. Ở giữa, tôi đã sử dụng

while 1; do redis-cli -p 7777 info | grep master_sync_left_bytes;sleep 1; done

Để có được một ước tính thô của tốc độ.
SSH giành chiến thắng sau một cú sút xa: ~ 11MB / s so với OpenVPN ~ 2MB / s.
Điều đó có nghĩa là tất cả những gì tôi đã đánh dấu lại là sai, hay tôi đã định cấu hình sai thiết lập của mình?

Cập nhật

Tôi đã thực hiện một số thử nghiệm với cùng một bộ dữ liệu và nhận được các kết quả sau:

  • OpenVPN
    • TCP:
      nén: 15m
      không nén: 21m
    • UDP:
      nén: 5m
      không nén: 6m
  • SSH
    mặc định: 1m50s
    không nén: 1m30s
    nén: 2m30s

Cập nhật2

Dưới đây là kết quả iperf, với các thử nghiệm hai chiều (ngoại trừ SSH, nơi không có đường dẫn trả lại nào khả dụng)

| method           | result (Mb/s)|
|------------------+--------------|
| ssh              | 91.1 / N.A   |
| vpn blowfish udp | 43 / 11      |
| vpn blowfish tcp | 13 / 12      |
| vpn AES udp      | 36 / 4       |
| vpn AES tcp      | 12 / 5       |

Thông số kỹ thuật

Tôi đang chạy CentOS 6.3 (máy chủ), CentOS 6.5 (máy khách).
Phiên bản OpenVPN là 2.3.2 (giống như trong Ubuntu 14.10, vì vậy không có phiên bản bị mốc nào ở đó)
Đường hầm SSH của tôi trông như sau:

ssh -f XXXX@XXXX -i XXXX -L 12345:127.0.0.1:12345 -N

Tập tin cấu hình của tôi trông như:
máy chủ

port 1194
proto udp
dev tun0
topology subnet
log /var/log/openvpn.log

ca XXXX
cert XXXX
key XXXX
dh XXXX
crl-verify XXXX

cipher AES-256-CBC

server XXXX 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
comp-lzo
status /var/log/openvpn-status.log
verb 3
tun-mtu 1500
fragment 1300

persist-key
persist-tun

khách hàng

client

remote XXXX 1194

proto udp
dev tun
log /var/log/openvpn.log
comp-lzo

cipher AES-256-CBC
ns-cert-type server

# the full paths to your server keys and certs
ca XXXX
cert XXXX
key XXXX

tun-mtu 1500 # Device MTU
fragment 1300 # Internal fragmentation

persist-key
persist-tun
nobind

3
SSH cũng hỗ trợ nén, do đó, không nhất thiết phải có gì đó khác biệt giữa OpenVPN và SSH. Bạn đã thử vô hiệu hóa nén ở cả hai bên? Khi bạn thực hiện chuyển qua OpenVPN, hãy chạy hàng đầu hoặc một cái gì đó trên máy khách / máy chủ của bạn. Có bất kỳ dấu hiệu rõ ràng nào cho thấy bạn đang tăng tối đa CPU / Bộ nhớ / vv với kết nối VPN không?
Zoredache

2
Có vẻ như không có khả năng cho một hệ thống lưu trữ AWS, nhưng có một khả năng nhỏ là UDP đang bị giới hạn tốc độ hoặc một cái gì đó. Bạn đã thử làm OpenVPN qua TCP chưa?
Zoredache

4
@Nitz Đường hầm TCP trong ssh không sử dụng bất kỳ TCP nào qua TCP. Trong thực tế, máy khách ssh thường được chạy với các đặc quyền không đủ để làm điều đó. Và không, ssh không loại bỏ bất kỳ tiêu đề TCP nào khỏi các gói, bởi vì nó thậm chí không bao giờ chạm vào gói TCP. ssh chỉ là một ứng dụng sử dụng ngăn xếp TCP trong kernel, giống như bất kỳ ứng dụng nào khác. Dữ liệu truyền qua một kết nối TCP từ một số chương trình đến máy khách ssh. Máy khách ssh mã hóa dữ liệu và gửi nó thông qua kết nối TCP đến máy chủ. Máy chủ giải mã nó sẽ gửi nó thông qua kết nối TCP thứ ba đến một chương trình ở đầu kia.
kasperd

2
Chắc chắn có thể có thêm một chút chi phí với OpenVPN vì nó có thêm tiêu đề IP / TCp. Nhưng điều đó không làm cho sự khác biệt chậm hơn 4-10 lần. Nếu sự khác biệt là trong phạm vi chậm hơn 5-10%, tôi có thể bị buộc phải đổ lỗi cho điều đó. Lý do bạn có thể vẫn muốn điều tra là vì đây có thể là triệu chứng của một số vấn đề tiềm ẩn có thể ảnh hưởng đến những thứ khác theo cách ít rõ ràng hơn.
Zoredache

2
@Nitz Nếu tôi hiểu đúng về bạn, bạn đang nói rằng các gói không được mã hóa vào giao diện ảo là 1424 byte, nhưng các gói được mã hóa gửi trên giao diện vật lý chỉ là 160 byte. Điều đó sẽ chỉ ra sự phân mảnh khá lớn xảy ra ở lớp VPN hoặc lớp UDP / IP bên dưới nó. Điều đó chắc chắn có thể giải thích vấn đề hiệu suất. Các gói trên giao diện ảo phải là thứ gì đó theo thứ tự 1300-1400 byte. Các gói trên giao diện vật lý phải là thứ gì đó theo thứ tự 1400-1500 byte.
kasperd

Câu trả lời:


7

Nhờ nhận xét của kasperd , tôi đã biết rằng SSH không bị TCP quá tải vì nó chỉ di chuyển dữ liệu gói. Tôi đã viết một bài đăng trên blog về nó, nhưng điều thú vị nhất là đầu ra, chứng minh rằng SSH thực sự không bảo tồn dữ liệu Lớp 3,4: netstat

sau khi đào hầm, trước khi kết nối

backslasher@client$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 127.0.0.1:20000             0.0.0.0:*                   LISTEN      20879/ssh
tcp        0      0 10.105.16.225:53142         <SERVER IP>:22              ESTABLISHED 20879/ssh
...

backslasher@server$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 0.0.0.0:6379                0.0.0.0:*                   LISTEN      54328/redis-server
tcp        0      0 <SERVER IP>:22              <CLIENT IP>:53142           ESTABLISHED 53692/sshd
...

sau khi đào hầm và kết nối

backslasher@client$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 127.0.0.1:20000             0.0.0.0:*                   LISTEN      20879/ssh
tcp        0      0 127.0.0.1:20000             127.0.0.1:53142             ESTABLISHED 20879/ssh
tcp        0      0 127.0.0.1:53142             127.0.0.1:20000             ESTABLISHED 21692/redis-cli
...

backslasher@server$ netstat -nap | grep -P '(ssh|redis)'
...
tcp        0      0 0.0.0.0:6379                0.0.0.0:*                   LISTEN      54328/redis-server
tcp        0      0 127.0.0.1:6379              127.0.0.1:42680             ESTABLISHED 54328/redis-server
tcp        0      0 127.0.0.1:42680             127.0.0.1:6379              ESTABLISHED 54333/sshd
tcp        0      0 <SERVER IP>:22              <CLIENT IP>:53142           ESTABLISHED 52889/sshd
...

Vì vậy, tôi sẽ sử dụng đường hầm SSH, vì có vẻ như OpenVPN của tôi không được định cấu hình sai hoặc bất cứ điều gì, chỉ là công cụ không phù hợp cho công việc.


3

Nó phụ thuộc vào những gì bạn đang cố gắng để đạt được và những ưu tiên của bạn là gì. VPN kết nối bạn với mạng và SSH với máy. VPN an toàn hơn một chút với việc đóng gói, điều mà SSH không làm được.

Ngoài ra, VPN cho phép tất cả lưu lượng truy cập dễ dàng đi qua nó, so với SSH, nơi bạn sẽ phải buộc các ứng dụng.

Bạn sẽ sử dụng AD ở tất cả? Bởi vì VPN sẽ cho phép bạn làm điều đó dễ dàng hơn nhiều.

Tôi thích SSH cho các nhu cầu nhanh chóng và VPN cho các ứng dụng quan trọng, nơi tôi nên dành thêm thời gian.

Tùy thuộc vào tình huống, tôi đã sử dụng SSH trong VPN trong trường hợp VPN bị xâm phạm. Bằng cách này, ai đó đang thăm dò sẽ phải vượt qua đường hầm SSH.


2
Tôi đang chạy redis qua đường hầm, vì vậy một cổng duy nhất đủ cho tôi. Tôi đã rất ngạc nhiên bởi thực tế rằng VPN không phải lúc nào cũng là giải pháp tốt nhất để tạo lưu lượng truy cập mạng
Nitz
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.