Сервер OpenVPN 2.4.7 x86_64 установлен на Ubuntu 20.04.4
server.conf:
port 1194
proto udp
dev tun
ca server/ca.crt
cert server/srv.crt
key server/srv.key
crl-verify crl.pem
dh server/dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
tls-auth server/ta.key 0
key-direction 0
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 4
explicit-exit-notify 1

Клиент OpenVPN 2.5.6-I601 amd64 установлен на Windows Server 2019 x64 Standard
srv.ovpn:
client
dev tun
proto udp
remote srv.com.ru 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
key-direction 1
verb 4

Клиент работает как служба OpenVPNService, запускается с системной учётной записью, исполняемый файл: "C:\Program Files\OpenVPN\bin\openvpnserv2.exe".
До недавнего времени виндовый клиент стоял версии 2.4.8, после обновления до 2.5.6, туннель стал периодически отваливаться. В логах клиента вот что при этом:
2022-04-04 11:02:38 us=312000 TCP/UDP: Closing socket
2022-04-04 11:02:38 us=312000 C:\Windows\system32\route.exe DELETE 10.8.0.0 MASK 255.255.255.0 10.8.0.9
2022-04-04 11:02:38 us=328000 Route deletion via IPAPI succeeded [adaptive]
2022-04-04 11:02:38 us=328000 Closing TUN/TAP interface
2022-04-04 11:02:39 us=328000 TAP: DHCP address released
2022-04-04 11:02:39 us=328000 SIGTERM[hard,] received, process exiting

При этом служба переходит в состояние "Остановлена", а тип запуска меняется с "Автоматически" на "Вручную". Меняю снова на "Автоматически", запускаю службу - всё работает. При этом может проработать без сбоев несколько дней, а может несколько часов. Но результат всегда один - туннель отваливается.

Может, есть у кого какие идеи?

P.S. Да, кстати, при установке клиента 2.5.6-I601 не удалось установить драйвер Tun, пришлось пользоваться Tap.

Верни клиента взад

Ну это уже как крайнее решение, если ничего не поможет. Для начала хотелось бы всё же разобраться, почему падает.

а с какой целью меняли-то? Работает - не трогай.

Во время проблем с DNS регистратора туннель так же отваливался, и затем (когда DNS становились доступны) не переподнимался, хотя должен был. Ну и в версии 2.5, по сравнению с 2.4, много улучшений, в т.ч. более быстрое соединение.

Включите аудит и посмотрите,кто меняхет службу и зачем.

(0) >не удалось установить драйвер Tun, пришлось пользоваться Tap
>server.conf:
>dev tun
>client:
>dev tun
Ээ?

>Tap
Пару лет назад, помнится, была проблема, что при использовании какой-то версии драйвера интерфейса Tap он постоянно отваливался при любых проявлениях спящего режима или гибернации, прямо беда была на ноутбуках, даже баг-репорт емнип был жирный многостраничный такой, даже не помню, чем там дело кончилось. Но у вас-то на сервере, наверное, не должно быть спящих режимов никаких. Но вы проверьте, на всякий пожарный.

Ещё после предыдущей инсталляции могут быть конфликты в TCP/IP стеке, сделайте
netsh winsock reset catalog
netsh int ipv4 reset
netsh int ipv6 reset
— и перезагрузку потом обязательно.

>в версии 2.5, по сравнению с 2.4, много улучшений, в т.ч. более быстрое соединение
Да ну, бросьте вы. Ставье обратно, что работало, тем более что сервер-то у вас всё равно 2,4.

>при установке клиента 2.5.6-I601 не удалось установить драйвер Tun
Ну или для начала разобраться, почему Tun не ставится, всё-таки Tap это более сложный и капризный сценарий.

(5) Ну и вот это, конечно, беспроигрышный вариант.

(5) А вот это был дельный совет, благодарю!
Аудит показал, что перед остановкой службы объект openvpnserv2.exe трогали два процесса: Windows Defender и C:\Program Files\Intel\SUR\QUEENCREEK\x64\esrv_svc.exe

Удалил "Intel(R) Computing Improvement Program" (откуда она там взялась - ума не приложу), добавил папку OpenVPN в исключения антивируса. Понаблюдаю теперь.

(6) Попробую, если (8) не поможет, спасибо!
Спящих режимов никаких нет.

(6) >>server.conf:
>>dev tun
>>client:
>>dev tun
>Ээ?

Это вроде не жёсткое правило, а лишь указание на приоритет. Так-то большинство клиентов работают через Tun.

(10) >Это вроде не жёсткое правило, а лишь указание на приоритет

Да вроде раньше жёсткое правило было, если мне склероз не изменяет. Вот, например, в инструкциях есть указание на то, что это как бы взаимоисключающие пункты:
"You must use either tun devices on both ends of the connection or tap devices on both ends. You cannot mix them, as they represent different underlying network layers."
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
"You cannot mix --dev tun and --dev tap on different ends of the connection. Use one or the other consistently."
https://community.openvpn.net/openvpn/wiki/305-what-is-the-difference-between-a-tun-device-and-a-tap-device
— очевидно, что один сервер не может работать сразу в двух режимах, иначе эти оговорки были бы бессмысленны.
Так что у вас там либо два инстанса ОпенВПН-сервера, либо одно из двух. Вы его сами ставили или нет?

(8) >перед остановкой службы объект openvpnserv2.exe трогали два процесса

Это служба статистики и служба защитника, они всё подряд всё время трогают, это явно не то, что вам нужно.
Да и вообще, вам какая разница, какие процессы сам файл-то трогали, вам в первую очередь нужно понять, почему меняется режим запуска службы. Кто-то ведь это делает, и явно с какой-то целью. То есть, вам нужно настраивать аудит доступа к соответствующим веткам реестра, либо средствами Виндовс, либо чем-нибудь вроде Process Monitor постоянный мониторинг вести.

(0) У службы опенвпн в зависимостях есть DHCP-Client. Может его кто то дергает.

Тоже самое началось и на старых версиях, не пойму в чем дело. В системных логах тоже самое :
Тип запуска службы "OpenVPNService" был изменен с "Автоматически" на "Вручную".

Если запускать вручную все работает. При перезагрузке ни фига...

(14) Огласите весь список служб и заданий в планировщике. Пожалуйста.

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

(11) Это гайд для версии 2.4, а я пытаюсь 2.5 использовать. В новом гайде я нигде не нашёл указаний на то, что это жёсткое правило. Тем не менее... см. (18)
Ставил сам.
(12) Да, вы правы. Собственно, и проблема не решилась.
(13) Не-а. По крайней мере в журнале по DHCP-клиенту ничего в ближайшее время перед остановкой службы.

Итак, всё же удалось мне установить драйвер Tun, благодаря этому совету: https://forums.openvpn.net/viewtopic.php?f=5&t=31527#p96564
Однако, что я обнаружил! Интерфейс Wintun не используется при установке туннеля, причём такая же ситуация на машинах с Win10, где клиент OpenVPN 2.5.6 с драйвером Wintun устанавливался без проблем. А я-то был уверен, что все уже давно через Tun подключаются. Отключение интерфейса TAP не решает проблему - OpenVPN ругается на отсутствие TAP-адаптера и наотрез отказывается устанавливать туннель. Несмотря на то, что в конфигах указано 'dev tun' (это тоже говорит не в пользу жёсткого правила).
Вот такие пироги с котятами. Попробую выяснить, как всё же его заставить использовать Tun, но что-то уже подумываю о переходе на IPsec.

Адаптер Tun всё же удалось задействовать добавлением в конфиг:
windows-driver wintun

У меня падает с любым типом адапетра..Копаю уже неделю.

У меня внезапно перестало падать. Без видимых причин. С типом адаптера тоже не связано - я Wintun тогда задействовал на другой машине, на этой пока не трогал ничего. 06.04 служба ещё раз падала, я перезапускал, с тех пор не падает больше. Я всё жду, чтобы дальше анализировать, - а оно не падает.

Ставь WireGuard и не люби мозги

(22) Это решение проблемы? Ты даже не привёл ни одного аргумента в пользу WireGuard. С таким же успехом можно было сказать: "Не пользуйся VPN".

(23) Послушай (22) дело говорит. Wintun - это драйвер от wireguard.

(24) Я в курсе, чей это драйвер. Но почему переход на WireGuard - это решение проблемы, описанной в посте, мне почему-то никто так и не объяснил. Как и не объяснил преимуществ WireGuard перед OpenVPN.

(25) Как её решить-то, если она возникает раз в несколько дней и никаких следов после себя не оставляет. Возможно, вам просто повезло натолкнуться на какие-то остаточные явления после недавних проблем с обновлениями для семейства Вин10/11, когда были массовые проблемы с ВПН. Я бы всё-таки вот сюда покопал: (12) — любопытно, кто же всё-таки режим запуска службы меняет. Это ведь может быть как Виндовс, так и ОпенВПН — и это сильно разные ситуации будут.

(23) > аргументы в пользу WireGuard

WireGuard — это очень стильно, модно и молодёжно. Если вам меньше 25, то пользоваться унылым пенсионерским ОпенВПН просто даже немного неприлично как-то.

(26) Может быть. Пока что не падает до сих пор, поэтому и анализировать нечего.
(27) А если мне 35, и хочется не молодёжно, а надёжно?

(28) Тогда наверное мне кажется вам лучше было оставаться на компромиссной ветке 2.4, её ведь специально для утомлённых жизнью предпенсионеров типа нас и поддерживают до сих пор, вот даже есть боле лимение свежий крайний релиз за нумером 2.4.12 от 17 марта сего года, так что Смотрящий сразу всё верно сказал: (1) — сразу видно, тоже человек немолодой, понимает почём фунт лиха.

Попробовал и то и другое. По факту, wireguard не замена openvpn, а альтернатива. Она поддерживается нормально в микротике в 7 версии. wireguard намного проще настраивать на смартфонах. Но, wireguard не настолько гибкий, например в нём нет l2-туннелей (tap), то есть его в бридж не объединишь с локальным сетевым интерфейсом.

persist-key Убери с конфига сервера и все заработает.