Назад | Перейти на главную страницу

Туннелирование SSH быстрее, чем OpenVPN, не так ли?

По логике, VPN должен быть быстрее SSH для туннелирования, потому что:

Однако сегодня я протестировал репликацию Redis по обоим методам.
Я провел тест на виртуальной машине AWS в Ирландии, подключившись к виртуальной машине AWS на востоке США.
Поскольку мой тестовый пример - репликация 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 МБ / с по сравнению с OpenVPN ~ 2 МБ / с.
Означает ли это, что все, что я перепроверил, было неправильным, или я сильно неправильно сконфигурировал свою установку?

Обновить

Я провел несколько тестов с одним и тем же набором данных и получил следующие результаты:

Обновление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

Благодаря каспердс комментарий, Я узнал, что SSH не страдает от TCP-over-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 не настроен неправильно или что-то в этом роде, просто не подходит для работы.

Это зависит от того, чего вы пытаетесь достичь и каковы ваши приоритеты. VPN подключает вас к сети, а SSH - к машине. VPN немного более безопасен с инкапсуляцией, чего не делает SSH.

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

Собираетесь ли вы вообще использовать AD? Потому что VPN позволит вам сделать это намного проще.

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

В зависимости от ситуации я использовал SSH в VPN на случай взлома VPN. Таким образом, зондирующий должен пройти через SSH-туннель.