Логически, VPN должен быть быстрее, чем SSH для туннелирования, потому что:
- Он работает по протоколу UDP, а не по протоколу TCP (поэтому нет протокола TCP через TCP)
- Имеет сжатие
Однако сегодня я тестировал репликацию 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 МБ / с по сравнению с ~ 2 МБ / с OpenVPN.
Означает ли это, что все то, что я повторно проверил, было неверным, или я неправильно настроил мои настройки?
Обновить
Я провел несколько тестов с одним и тем же набором данных и получил следующие результаты:
- OpenVPN
- TCP:
сжатие: 15 м
без сжатия: 21 м - UDP:
сжатие: 5 м
без сжатия: 6 м
- TCP:
- SSH по
умолчанию: 1m50s
без сжатия: 1m30s
сжатия: 2m30s
Update2
Вот результаты 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
источник
Ответы:
Благодаря kasperd «S комментарий , я узнал , что SSH не страдает от TCP-над-TCP , поскольку он перемещает только пакетные данные. Я написал об этом в блоге , но самым интересным является
netstatвывод, доказывающий, что SSH действительно не сохраняет данные уровня 3,4:после туннелирования, до подключения
после туннелирования и подключения
Поэтому я собираюсь использовать SSH-туннелирование, так как кажется, что мой OpenVPN не настроен неправильно или что-то в этом роде, просто не является подходящим инструментом для работы.
источник
Это зависит от того, чего вы пытаетесь достичь и каковы ваши приоритеты. VPN соединяет вас с сетью, а SSH - с машиной. VPN немного безопаснее с инкапсуляцией, чего не делает SSH.
Кроме того, VPN позволяет легко проходить через него весь трафик, в отличие от SSH, где вам придется форсировать приложения.
Собираетесь ли вы использовать AD вообще? Потому что VPN позволит вам сделать это гораздо проще.
Я предпочитаю SSH для быстрых потребностей и VPN для критически важных приложений, где я должен сэкономить дополнительное время.
В зависимости от ситуации я использовал SSH в VPN на случай, если VPN был скомпрометирован. Таким образом, кто-то должен был пройти через SSH-туннелирование.
источник