Тормозит OpenVPN

Имею дома гентушный сервер и канал 55/25 МБит.
На работе канал не хуже, но сильно порезанный по ресурсам, в связи с чем поставил дома опенвпн и хожу с работы в инет через него.
Но есть проблема - по впн максимальная скорость с шифрованием получается около 2-3 мегабит, без шифрования - 6-7 (в обе стороны одинаковая примерно). Проц на сервере при этом грузится почти до 100%. Да, сервер старенький (п4 прескотт на 2.8 ггц), но с чего бы без шифрования ему так нагружаться? Если сервер загружен чем-то ещё, то скорость без шифрования вообще падает до пары мегабит. Оно так и должно жрать или есть пути оптимизации? По UDP должно вроде чуть быстрее работать, но я так понял - не сильно критично, да и что-то не заработало у меня - может 443 удп фильтруется.

cipher none

tcp-nodelay
#fast-io
#режим сервера
mode server
#использовать TLS-аутентифкацию
tls-server
#прослушивание по tcp-протоколу
proto tcp-server
#proto udp
#использовать tap устройство
dev tap
#прослушиваемый порт 5555
port 443
#скрипт который будет выполнятся при поднятии впн туннеля
#up /etc/openvpn/upscript.sh
#режим демона
daemon
#TLS-ключ
tls-auth /etc/openvpn/keys/ta.key 0
#указываем файл с CA
ca /etc/openvpn/keys/ca.crt
#сертификат сервера
cert /etc/openvpn/keys/hydra.crt
#указываем ключ сертификата
key /etc/openvpn/keys/hydra.key
#файл Диффи-Хеллмана
dh /etc/openvpn/keys/dh1024.pem
#указываем IP-адрес сервера и маску виртуальной сети
ifconfig 192.168.1.1 255.255.255.0

#описываем наш vpn пул
#IP-адрес через push "ifconfig адрес маска"
ifconfig-pool 192.168.1.10 192.168.1.20
# Добавляем клиенту необходимые маршруты на локальные подсети, например:
push "route 192.168.1.0 255.255.255.0"
#разрешаем дублирование сертифкатов
#если упустить эту опцию то на каждого клиента надо
#генерировать отдельный сертификат с помощью pkitool
duplicate-cn
#включаем режим отладки
verb 9
#не перечитывать ключ при сбросе соединения
persist-key
#лог файл
log-append /var/log/openvpn.log
persist-tun

без шифрования - 6-7 (в обе

 без шифрования - 6-7 (в обе стороны одинаковая примерно).

Ну и нафик тут vpn, если с обеих сторон никсы, а шифрование не нужно - IP tunnel для начала будет так же тормозить ?

П.С Алсо, чем именно загружен проц ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

из практики — стоит все же

из практики — стоит все же использовать udp-режим, как и рекомендовано в оффдоках; нагрузки такой быть не должно.
Если нужно только туннелирование без излишних трудностей — используйте pptp/l2tp c ядерным драйвером, например accel-pppd, значительной нагрузки с отключенным шифрованием нет даже на сотнях мегабит.

в например accel-pppd, нет

в

например accel-pppd,

нет l2tp
оно есть в

net-dialup/accel-ppp
     Available versions:  (~)1.7.3 (~)1.7.3-r1[1] {debug doc postgres radius shaper snmp}
     Homepage:            http://accel-ppp.sourceforge.net/
     Description:         Point-to-Point Tunnelling Protocol Client/Server for Linux

и это 2 разных проекта

можете обсновать выбор именно pptp/l2tp ( одно или другое ? )
Зачем нужен юзерспейс демон в данном случае если речи про авторизацию не идет ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

я указал название собственно

я указал название собственно демона, ибо наличествовала в свое время какая-то путаница с названиями проектов/пакетов итд — где с «d», а где без. Лично сам использую 9999 из git, поскольку емнип в оверлеях тогда еще не было. l2tp и pptp там есть и могут использовать одну юзербазу.

Обоснование: а) ТС выбрал «клиент-серверный» подход к решению задачи. Возможно, у него есть на это причины, например динамический IP на одном или более концов. Кроме того, так меньше возни в ипстолах итд — на сервере настроил выпуск в мир туннеля а на клиенте все искаропки, а может, ему так просто больше нравится. Есть и некоторые ограничения в IP-IP туннелировании, навскидку помню вроде бы что мульти- или бродкасты нельзя.
б) настройка проста, ибо можно chap-secret использовать без радиусов итд. проект отлично документирован конь там если раз в год валялся, то хорошо; но вроде и так все понятно.
в) из моего опыта предоставления VPN «клиентам» — самый требовательный к среде передачи и ресурсам это OpenVPN; были случаи, когда были провайдерозависимые проблемы с GRE трафиком. Так что комбинация pptp/l2tp на мой взгляд более устойчива, а ее реализация в accel-ppp[d] вполне эффективна и надежна.
г) ничего не имею против IP-IP и GRE туннелей. Спорить на предмет «что лучше» в терминах «вообще» — клиника.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".