OpenVPN и DCO

[vitalik6243]

Заметил такую ситуацию что на наших кинетиках стоит пакет OpenVPN 2.6
Но почему то не добавлен пакет DCO который значительно разгружает процессор при использовании DCO + повышает эффективность работы OpenVPN за счет более высокой скорости передачи данных.
Было бы не плохо увидеть такой пакет в будущих прошивках.
Да и вроде как есть что-то типо готового решения: kmod-ovpn-dco(судя по всему было когда то реализовано на OpenWRT, но могу ошибаться.)

[vitalik6243]

17 минут назад, Leshiyart сказал:

Тут есть повод посмотреть на эту ситуацию разработчикам.
Так же можно попробовать повесить пинг чек на такое соединение через cli
судя по всему udp не выигрывает в скорости, принципиально надо udp?

Да, некоторые провайдера почему то не пропускают tcp сессию по OpenVPN поэтому используется 2.
Да в целом то не критично можно пользоваться и без dco без dco Keenetic адекватно понимает разрывы и правильно работает с keepalive 15 30
Но при включении enable-dco такое ощущение что параметр сервера keepalive 15 30 начинает игнорироваться, в логах сервера остается только то что сессия клиента закрыта, новых попыток авторизации от Keenetic не поступает, так что я склоняюсь в текущий момент к тому что проблема с использованием dco именно со стороны Keenetic роутера, т.к. к примеру другой сервер подключен так же по OpenVPN 2.6.13 + dcov2 отрабатывает перезагрузки сервера openvpn адекватно.
Вроде как в Keenetic используется схожая конфигурация.
Я в текущий момент tcp сессии оставил с dco для разгрузки процессора роутера. Т.к. загрузка процессора реально ниже при использовании dco даже на mips 7621
А udp оставил без dco, вдруг все таки удастся обнаружить проблему и исправить ее в дальнейшем.
По поводу pingcheck через cli понятное дело что будет работать без проблем если пинговать шлюз внутри openvpn тунеля, ip сервера закрыт по icmp запросам, а вот шлюз можно, и да такое будет работать т.к. логично что при рестарте соединения провайдера, Keenetic корректно разрывает сессию openvpn + dco UDP.
Но вот не понятно почему он не хочет ее разрываться без физического фактора как передергивание линка провайдера или перезапуск самого соединения OpenVPN.

Изменено 24 февраля пользователем vitalik6243

[vitalik6243]

[I] Feb 24 21:31:14 kernel: tun0: ovpn_peer_ping: sending ping to peer 0
[I] Feb 24 21:31:14 kernel: tun0: ovpn_decrypt_one: ping received from peer with id 0
[E] Feb 24 21:32:21 OpenVPN0: read UDPv4 [ECONNREFUSED]: Connection refused (fd=4,code=111) 
[E] Feb 24 21:32:39 OpenVPN0: Core::Syslog: last message repeated 5 times.
[I] Feb 24 21:32:42 kernel: tun0: ovpn_peer_expire: peer 0 expired
[I] Feb 24 21:32:42 kernel: tun0: deleting peer with id 0, reason 2
[I] Feb 24 21:32:42 OpenVPN0: [VPN] Inactivity timeout (--ping-restart), restarting 
[W] Feb 24 21:32:42 OpenVPN0: DCO kernel error 
[I] Feb 24 21:32:42 OpenVPN0: dco_del_peer: netlink reports object not found, ovpn-dco unloaded? 
[E] Feb 24 21:32:42 OpenVPN0: dco_del_peer: netlink reports error (-4): Try again 
[E] Feb 24 21:32:46 OpenVPN0: Core::Syslog: last message repeated 141931 times.
[I] Feb 24 21:32:46 kernel: tun0: no peer to send data to
[E] Feb 24 21:32:46 OpenVPN0: dco_del_peer: netlink reports error (-4): Try again 
[E] Feb 24 21:32:46 OpenVPN0: Core::Syslog: last message repeated 16385 times.
[I] Feb 24 21:32:46 kernel: tun0: no peer to send data to
[E] Feb 24 21:32:46 OpenVPN0: dco_del_peer: netlink reports error (-4): Try again 
[E] Feb 24 21:32:48 OpenVPN0: Core::Syslog: last message repeated 48533 times.
[I] Feb 24 21:32:48 kernel: tun0: no peer to send data to
[E] Feb 24 21:32:48 OpenVPN0: dco_del_peer: netlink reports error (-4): Try again 
[E] Feb 24 21:32:48 OpenVPN0: Core::Syslog: last message repeated 16406 times.
[I] Feb 24 21:32:48 kernel: tun0: no peer to send data to
[E] Feb 24 21:32:48 OpenVPN0: dco_del_peer: netlink reports error (-4): Try again 
[E] Feb 24 21:32:53 OpenVPN0: Core::Syslog: last message repeated 143436 times.
[I] Feb 24 21:32:53 kernel: tun0: no peer to send data to

Вот список ошибок при потери соединения с сервером по UDP протоколу, при этом соединение остается зеленое якобы активное и не разрывается.

[Le ecureuil]

Спасибо за репорты, посмотрим.