Тунелювання SSH швидше, ніж OpenVPN, це могло бути?


21

Логічно, VPN повинен бути швидшим, ніж SSH для тунелювання, оскільки:

  • Він працює на UDP, а не на TCP (тому немає TCP через TCP)
  • Він має стиснення

Однак сьогодні я перевірив реплікацію Редіса на обох методах.
Я пройшов випробування над Ірландією AWS VM, підключившись до АМ США-Схід VM.
Оскільки мій тестовий випадок - це реплікація Redis, це саме те, що я перевірив - я запустив чистий сервер Redis, і після його завершення завантаження я виконав slaveofінший сервер і виміряв час між Connecting to MASTERі MASTER <-> SLAVE sync: Finished with success. Між тим я використовував

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

Щоб отримати грубу оцінку швидкості.
SSH виграв дальнім ударом: ~ 11 Мб / с порівняно з ~ 2 Мб / с OpenVPN.
Чи означає це, що все, що я повторно підтвердив, було неправильним, або я грубо неправильно налаштував налаштування?

Оновлення

Я зробив кілька тестів з тим же набором даних і отримав такі результати:

  • OpenVPN
    • TCP:
      стиснення: 15м
      без стиснення: 21м
    • UDP:
      стиснення:
      без стиснення:
  • Налаштування SSH
    : 1m50s
    без стиснення: 1m30s
    стиснення: 2m30s

Оновлення2

Ось результати iperf з двонаправленими тестами (крім SSH, де немає зворотного шляху)

| 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       |

Технічні характеристики

Я працюю CentOS 6.3 (сервер), CentOS 6.5 (клієнт).
Версія OpenVPN становить 2.3.2 (те саме, що і в Ubuntu 14.10, тому немає цвілі версії)
Мій тунель SSH виглядає так:

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

Мій файл конфігурації виглядає так:
сервер

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

клієнт

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 також підтримує стиснення, так що необов'язково щось інше між OpenVPN і SSH. Ви намагалися відключити стиснення з обох сторін? Коли ви здійснюєте передачу через OpenVPN, запустіть зверху або щось на вашому клієнті / сервері. Чи є явні ознаки того, що ви максимізуєте свій процесор / пам'ять / тощо за допомогою VPN-з'єднання?
Зоредаче

2
Для системи, розміщеної AWS, це малоймовірно, але є невелика ймовірність того, що UDP обмежується швидкістю чи щось. Ви намагалися робити OpenVPN через TCP?
Зоредаче

4
@Nitz TCP-тунелі в ssh не використовують жодного TCP через TCP. Насправді ssh-клієнт зазвичай працює з недостатніми привілеями, щоб навіть це зробити. І ні, ssh не знімає жодних заголовків TCP з пакетів, оскільки він ніколи навіть не торкається пакета TCP. ssh - це лише додаток, що використовує стек TCP в ядрі, як і будь-який інший додаток. Дані передаються через одне TCP-з'єднання від якоїсь програми до ssh-клієнта. Ssh-клієнт шифрує дані та надсилає їх через TCP-з'єднання на сервер. Сервер розшифровує його та надсилає його через третє TCP-з'єднання до програми на іншому кінці.
kasperd

2
Впевнені, що може бути трохи більше накладних витрат з OpenVPN, оскільки він має додаткові заголовки IP / TCp. Але це не повинно змінювати в 4-10 разів повільніше. Якби різниця була в 5-10% повільніше, я могла б спокусити це. Причина, яку ви хочете все-таки дослідити, полягає в тому, що це може бути симптомом якоїсь основної проблеми, яка може впливати на інші речі менш очевидним чином.
Зоредаче

2
@Nitz Якщо я вас правильно зрозумів, ви говорите, що незашифровані пакети, що входять у віртуальний інтерфейс, становлять 1424 байти, але зашифровані пакети, що надсилаються у фізичному інтерфейсі, становлять лише 160 байт. Це вказувало б на досить екстремальну фрагментацію, що відбувається на рівні VPN або шарі UDP / IP під ним. Це, безумовно, може пояснити проблеми продуктивності. Пакети віртуального інтерфейсу повинні бути чимось порядком 1300-1400 байт. Пакети на фізичному інтерфейсі повинні бути чимось порядком 1400-1500 байт.
kasperd

Відповіді:


7

Завдяки kasperd «s коментар , я дізнався , що SSH не страждає від TCP-над-TCP , оскільки він переміщує лише пакетні дані. Я писав про це в блозі , але найцікавіше - це netstatрезультат, який підтверджує, що SSH дійсно не зберігає дані рівня 3,4:

після тунелювання, перед підключенням

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
...

після тунелювання та підключення

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
...

Тому я збираюся використовувати тунелювання SSH, оскільки, здається, що мій OpenVPN не налаштований неправильно чи що-небудь, просто не правильний інструмент для роботи.


3

Це залежить від того, чого ви намагаєтеся досягти і які ваші пріоритети. VPN підключає вас до мережі, а SSH - до машини. VPN трохи захищеніший від інкапсуляції, чого SSH не робить.

Також VPN дозволяє весь трафік легко проходити через нього, порівняно з SSH, де вам доведеться змушувати програми.

Ви взагалі збираєтесь використовувати AD? Тому що VPN дозволить вам це робити набагато більше легко.

Я віддаю перевагу SSH для швидких потреб та VPN для критичних додатків, де мені слід витратити додатковий час.

Залежно від ситуації, я використовував SSH у VPN у випадку, коли VPN був порушений. Таким чином, хтось зондуючий повинен буде пройти тунель SSH.


2
Я біжу redis над тунелем, тож мені вистачить одного порту. Мене просто вразило те, що VPN не завжди є найкращим рішенням для тунельного мережевого трафіку
Nitz,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.