Тормозит 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 (в обе
Ну и нафик тут 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, нет
в
нет l2tp
оно есть в
и это 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 туннелей. Спорить на предмет «что лучше» в терминах «вообще» — клиника.