На Ubuntu 18.04 поднят сервер OpenVPN. Клиенты виндовые (Win 10/8/7/2019, в т.ч. терминальный сервер).
Пользователи подключаются через туннель к терминальному серверу.
Проблема: периодически у всех отваливается подключение к терминальному серверу на 1-5 минут.
Анализ показал, что проблема связана с OpenVPN, т.к. через внешнее соединение подключение не отваливается.
В логах OpenVPN сервера в момент разрыва наблюдается следующее:
Wed Jul  1 18:58:18 2020 91.79.181.222:57887 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jul  1 18:58:18 2020 91.79.181.222:57887 TLS Error: TLS handshake failed
Wed Jul  1 18:58:18 2020 91.79.181.222:57887 SIGUSR1[soft,tls-error] received, client-instance restarting

Но, похоже, это не причина, а следствие. Прошу помочь, в каком направлении копать.
Конфиг сервера:
port 1194
proto udp
dev tun
ca server/ca.crt
cert server/mirror.crt
key server/mirror.key
crl-verify crl.pem
dh server/dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/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 3
explicit-exit-notify 1

Конфиг клиента:
client
dev tun
proto udp
remote xxx.xxx.ru 1194 #Где xxx имя домена
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 3

Сколько клиентов?

киипаливе поменьше сделать. Протокол udp не гарантирует доставку, поэтому при потере олного пакета могут быть сбои, может поменять на tcp ?

(1) ~70

(2) Но сбои должны быть между сервером и клиентом, со стороны которого потери, это ведь не должно рушить весь туннель для всех. Кроме того, через TCP ведь будет гораздо медленнее.
А keepalive насколько меньше рекомендуете сделать?

(3) нагрузку CPU мониторил в моменты отвала?

(4) спасибо, проверю.

(4) но вообще было бы странно для линуксового сервера с Intel Xeon E-2236 3.4 ГГц, где больше особо ничего не крутится.

(0) периодически - постоянно через равные промежутки времени у всех одновременно?

Можно ещё посоветовать уменьшить макс. размер пакета. У меня 1300, экспериментально подбирал.

Tcp автоматически умеет подстраиваться под максимальный размер окна (но, подозреваю, не во всех реализациях). Udp точно не умеет.

(7) нет, не равные. Как правило, когда начинают превью фоток в 1С просматривать, и когда этих фоток в заказе много. Так что, похоже, действительно имеет место быть перегрузка. Помониторю.

(8) про MTU тоже думал, но разработчики OpenVPN заверяют, что последние версии их детища подстраиваются автоматически. Причём ничего не сказано о том, что UDP не умеет.

Отработали всю "удалёнку" на WireGuard'е. Соединение стабильное.

(10) Думать-то думали, а проверяли как-то? Уж очень похоже.

Что-то похожее у меня было, в конфиге стоит ms-fix 1250. Но, говонопровайдер у меня редкий.

Уже лет 7 работает стабильно (надо, кстати, обновиться).

(11) как долго используется? Сколько клиентов?

(12) у нас серверы в дата-центре, соответственно, провайдер - они же. Попробую у них выяснить - может, на их стороне MTU зарезан. Спасибо за идею!

(13) 5-7 клиентов. Но в качестве сервера Селерон двуядерный. И пару удаленных подсетей (где к качестве серверов тоже селероны)
Работает давно, очень хорошо и единственное что мне не нравится - отсутствие клиентов для Андроида.

msfix ставил таким низким в виду косячного провайдера. Косяков у клиентов со всякими USB свистками и т.п.

msfix 1250 - уведомляет участников TCP соединений что пакеты большего размера ходить не будут... и они их друг-другу не шлют. Шлют больше пакетов, меньшего размера. (man openvpn и translate.google.com в помощь)

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

У меня эта опция, только на сервере. Так что можешь себе поставить, рестартануть сервер и поглядеть что получится (время для экспериментов выбери сам)

(14) Как это нет клиентов под Андроид? А это что? https://play.google.com/store/apps/details?id=com.wireguard.android&hl=ru

(14) вопрос "как долго используется и сколько клиентов" адресовался Asmody. Или вы с ним одно лицо?)

(4) итак, в момент отвала загрузка CPU не превышала 12%
Теперь буду копать в сторону MTU.

Выполнил тест MTU на сервере OpenVPN, на терминалке и на клиентской машине. Все тесты показали максимальный размер пакета 1500.
Какие ещё есть идеи?

(19) Да весь гугл забит идеями с таким симптомом.
Это только на месте можно решить, внимательно наблюдая за всем что происходит, во всех возможных логах.
Попробуй все таки WG поставить. С ним вообще никаких проблем нет, поднимается с пол пинка, да и настроек почти нет, что не может не радовать.
Можно же и параллельно поставить и постепенно переводить клиентов.

(20) попробую для начала отказаться от OpenVPN между серверами, объединив их приватной сетью уровня L3 средствами ЦОД. Дальше уже буду думать - чинить OpenVPN или ставить WG.
Пока что увеличил детализацию логов на сервере OpenVPN, и обнаружил множество таких строк во время разрыва (XXX - зацензуренные мной имена и IP клиентов):
RWRThu Jul  2 17:26:06 2020 us=295201 XXX/XXX.XX.XX.X:54599 PID_ERR large diff [158] [SSL-0] [000000000000000000000000000000000000000000000000000000000000____] 0:12113 0:11955 t=1593699966[0] r=[0,64,15,158,1] sl=[5,64,64,528]
Thu Jul  2 17:26:06 2020 us=295257 XXX/XXX.XX.XX.X:54599 AEAD Decrypt error: bad packet ID (may be a replay): [ #11955 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

(21) Уже лучше, гугление по "PID_ERR large diff" выдает значительно меньше ссылок.

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

(23) Вроде нет. Вот что было до момента разрыва:

Thu Jul  2 18:42:27 2020 us=978535 XXX.XXX.XXX.XXX:59322 [XXX] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:59322
Thu Jul  2 18:42:27 2020 us=978589 XXX/XXX.XXX.XXX.XXX:59322 MULTI_sva: pool returned IPv4=10.8.0.242, IPv6=(Not enabled)
Thu Jul  2 18:42:27 2020 us=978656 XXX/XXX.XXX.XXX.XXX:59322 MULTI: Learn: 10.8.0.242 -> XXX/XXX.XXX.XXX.XXX:59322
Thu Jul  2 18:42:27 2020 us=978674 XXX/XXX.XXX.XXX.XXX:59322 MULTI: primary virtual IP for XXX/XXX.XXX.XXX.XXX:59322: 10.8.0.242
Thu Jul  2 18:42:29 2020 us=477809 XXX/XXX.XXX.XXX.XXX:59322 PUSH: Received control message: 'PUSH_REQUEST'
Thu Jul  2 18:42:29 2020 us=477909 XXX/XXX.XXX.XXX.XXX:59322 SENT CONTROL [XXX]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.242 10.8.0.241,peer-id 23,cipher AES-256-GCM' (status=1)
Thu Jul  2 18:42:29 2020 us=477930 XXX/XXX.XXX.XXX.XXX:59322 Data Channel: using negotiated cipher 'AES-256-GCM'
Thu Jul  2 18:42:29 2020 us=477959 XXX/XXX.XXX.XXX.XXX:59322 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]
Thu Jul  2 18:42:29 2020 us=478090 XXX/XXX.XXX.XXX.XXX:59322 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Jul  2 18:42:29 2020 us=478110 XXX/XXX.XXX.XXX.XXX:59322 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Jul  2 18:42:38 2020 us=218299 YYY/YYY.YYY.YY.YYY:10153 [YYY] Inactivity timeout (--ping-restart), restarting
Thu Jul  2 18:42:38 2020 us=218387 YYY/YYY.YYY.YY.YYY:10153 SIGUSR1[soft,ping-restart] received, client-instance restarting
Thu Jul  2 18:43:58 2020 us=3997 ZZZ/ZZ.Z.ZZZ.ZZ:60930 [ZZZ] Inactivity timeout (--ping-restart), restarting
Thu Jul  2 18:43:58 2020 us=4084 ZZZ/ZZ.Z.ZZZ.ZZ:60930 SIGUSR1[soft,ping-restart] received, client-instance restarting
Thu Jul  2 18:46:37 2020 us=155089 AAA/AA.AA.AAA.AAA:49873 [AAA] Inactivity timeout (--ping-restart), restarting
Thu Jul  2 18:46:37 2020 us=155182 AAA/AA.AA.AAA.AAA:49873 SIGUSR1[soft,ping-restart] received, client-instance restarting
Thu Jul  2 18:46:41 2020 us=178282 BBB/BBB.BB.BB.B:57766 PID_ERR replay-window backtrack occurred [3] [SSL-0] [0___1111222244444445555666688889999>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 0:2836 0:2833 t=1593704801[0] r=[-4,64,15,3,1] sl=[44,64,64,528]
Thu Jul  2 18:47:11 2020 us=611784 CCC/C.C.CCC.CC:3949 PID_ERR replay-window backtrack occurred [2] [SSL-0] [00_0000000000000000000000000000000000000000000000000000000000000] 0:50406 0:50404 t=1593704831[0] r=[-1,64,15,2,1] sl=[26,64,64,528]

(23) как клиент может вырубать сервер? У OpenVPN может быть такая дыра?

(23) Блокировка или потеря пакета UDP, перейдите на TCP это решит проблему

+(26) Ну и переход на wireguard в этом случае не поможет, имхо, т.к. там тоже UDP транспортом работает.

(27) как минимум проверить WG стоит, мне пока сильно нравится оно

(26) а не создаст ли это других проблем? UDP ведь быстрее, чем TCP.

(29) Я бы сказал не быстрее а толще. UDP толще TCP.

(29) Тут вопрос в другом, хватает ли пропускного канала для обслуживания клиентов или нет, не всегда нужна очень быстрая скорость, важно стабильность особенно если это RDP

Да еще вам никто не запрещает использовать одновременно UDP или TCP, часть клиентов там часть там

(30) ну это уже кому как нравится) Суть в том, что для UDP не требуется подтверждения доставки пакета, что ускоряет передачу данных. Дальше уже вопрос в надёжности маршрута.

(31) пропускная способность канала - 100 Мбит/с со стороны сервера. Со стороны клиентов - у кого как. Сейчас все на удалёнке, работают на дому.

(32) просто предчувствую недовольные возгласы "Адинэээс тормозиииит! Почему так меееедленноооо?" со стороны тех, у кого будет через TCP.

(33) Скорость падает не в разы а где то на 20%, у нас используется UDP и TCP одновременно, на TCP сидит половина из 280 клиентов из за того что некоторые домашние провайдеры выборочно блокируют UDP и у них рвется связь в промежутке от 5 до 20 мин, на TCP такой проблемы не наблюдается

(23) А как может сервер не отвечать 1-5 минут? Почему он отваливается?
А дыры могут быть везде, зачастую на ровном месте. И это было предположение, а не факт.

(34) у нас проблема в том, что связь рвётся сразу у всех, поэтому, боюсь, перевод половины клиентов на TCP решит проблему только наполовину. Запрошу инфу у дата-центра - может, действительно, проблема на стороне их оборудования.

(35) перестаёт отвечать именно терминальный сервер (также сервер 1С, SQL, etc.), который не является сервером OpenVPN. Сервер OpenVPN при этом не падает и отвечает на пинги.

Итак, проблема решилась отказом от OpenVPN между серверами в пользу L3 VLAN. Пользователи по-прежнему подключаются к терминалке через OpenVPN. За сегодня ни одного сбоя зафиксировано не было.
Всем спасибо за участие!