|
OpenVPN периодически падает TLS key negotiation failed | ☑ | ||
---|---|---|---|---|
0
Predator
01.07.20
✎
19:37
|
На 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 |
|||
1
Asmody
01.07.20
✎
19:49
|
Сколько клиентов?
|
|||
2
Партизан
01.07.20
✎
20:00
|
киипаливе поменьше сделать. Протокол udp не гарантирует доставку, поэтому при потере олного пакета могут быть сбои, может поменять на tcp ?
|
|||
3
Predator
01.07.20
✎
20:05
|
(1) ~70
(2) Но сбои должны быть между сервером и клиентом, со стороны которого потери, это ведь не должно рушить весь туннель для всех. Кроме того, через TCP ведь будет гораздо медленнее. А keepalive насколько меньше рекомендуете сделать? |
|||
4
Asmody
01.07.20
✎
20:11
|
(3) нагрузку CPU мониторил в моменты отвала?
|
|||
5
Predator
01.07.20
✎
20:45
|
(4) спасибо, проверю.
|
|||
6
Predator
01.07.20
✎
20:47
|
(4) но вообще было бы странно для линуксового сервера с Intel Xeon E-2236 3.4 ГГц, где больше особо ничего не крутится.
|
|||
7
Garikk
01.07.20
✎
21:39
|
(0) периодически - постоянно через равные промежутки времени у всех одновременно?
|
|||
8
stopa85
01.07.20
✎
21:47
|
Можно ещё посоветовать уменьшить макс. размер пакета. У меня 1300, экспериментально подбирал.
|
|||
9
stopa85
01.07.20
✎
21:49
|
Tcp автоматически умеет подстраиваться под максимальный размер окна (но, подозреваю, не во всех реализациях). Udp точно не умеет.
|
|||
10
Predator
01.07.20
✎
22:41
|
(7) нет, не равные. Как правило, когда начинают превью фоток в 1С просматривать, и когда этих фоток в заказе много. Так что, похоже, действительно имеет место быть перегрузка. Помониторю.
(8) про MTU тоже думал, но разработчики OpenVPN заверяют, что последние версии их детища подстраиваются автоматически. Причём ничего не сказано о том, что UDP не умеет. |
|||
11
Asmody
02.07.20
✎
01:22
|
Отработали всю "удалёнку" на WireGuard'е. Соединение стабильное.
|
|||
12
stopa85
02.07.20
✎
08:23
|
(10) Думать-то думали, а проверяли как-то? Уж очень похоже.
Что-то похожее у меня было, в конфиге стоит ms-fix 1250. Но, говонопровайдер у меня редкий. Уже лет 7 работает стабильно (надо, кстати, обновиться). |
|||
13
Predator
02.07.20
✎
13:16
|
(11) как долго используется? Сколько клиентов?
(12) у нас серверы в дата-центре, соответственно, провайдер - они же. Попробую у них выяснить - может, на их стороне MTU зарезан. Спасибо за идею! |
|||
14
stopa85
02.07.20
✎
14:59
|
(13) 5-7 клиентов. Но в качестве сервера Селерон двуядерный. И пару удаленных подсетей (где к качестве серверов тоже селероны)
Работает давно, очень хорошо и единственное что мне не нравится - отсутствие клиентов для Андроида. msfix ставил таким низким в виду косячного провайдера. Косяков у клиентов со всякими USB свистками и т.п. msfix 1250 - уведомляет участников TCP соединений что пакеты большего размера ходить не будут... и они их друг-другу не шлют. Шлют больше пакетов, меньшего размера. (man openvpn и translate.google.com в помощь) Я не могу объяснить точнее потому что уже не владею терминологией и могу напутать. |
|||
15
stopa85
02.07.20
✎
15:01
|
У меня эта опция, только на сервере. Так что можешь себе поставить, рестартануть сервер и поглядеть что получится (время для экспериментов выбери сам)
|
|||
16
Djelf
02.07.20
✎
15:03
|
(14) Как это нет клиентов под Андроид? А это что? https://play.google.com/store/apps/details?id=com.wireguard.android&hl=ru
|
|||
17
Predator
02.07.20
✎
15:11
|
(14) вопрос "как долго используется и сколько клиентов" адресовался Asmody. Или вы с ним одно лицо?)
|
|||
18
Predator
02.07.20
✎
15:57
|
(4) итак, в момент отвала загрузка CPU не превышала 12%
Теперь буду копать в сторону MTU. |
|||
19
Predator
02.07.20
✎
16:43
|
Выполнил тест MTU на сервере OpenVPN, на терминалке и на клиентской машине. Все тесты показали максимальный размер пакета 1500.
Какие ещё есть идеи? |
|||
20
Djelf
02.07.20
✎
17:20
|
(19) Да весь гугл забит идеями с таким симптомом.
Это только на месте можно решить, внимательно наблюдая за всем что происходит, во всех возможных логах. Попробуй все таки WG поставить. С ним вообще никаких проблем нет, поднимается с пол пинка, да и настроек почти нет, что не может не радовать. Можно же и параллельно поставить и постепенно переводить клиентов. |
|||
21
Predator
02.07.20
✎
17:46
|
(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 |
|||
22
Djelf
02.07.20
✎
17:53
|
(21) Уже лучше, гугление по "PID_ERR large diff" выдает значительно меньше ссылок.
|
|||
23
Djelf
02.07.20
✎
17:57
|
Какой то из клиентов, имхо, вырубает сервер. Посмотри в логе, не было ли запроса подключения с одной и той же точки до момента разрыва.
|
|||
24
Predator
02.07.20
✎
19:05
|
(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] |
|||
25
Predator
02.07.20
✎
19:06
|
(23) как клиент может вырубать сервер? У OpenVPN может быть такая дыра?
|
|||
26
zaki
03.07.20
✎
15:33
|
(23) Блокировка или потеря пакета UDP, перейдите на TCP это решит проблему
|
|||
27
arsik
гуру
03.07.20
✎
15:42
|
+(26) Ну и переход на wireguard в этом случае не поможет, имхо, т.к. там тоже UDP транспортом работает.
|
|||
28
Garykom
гуру
03.07.20
✎
16:01
|
(27) как минимум проверить WG стоит, мне пока сильно нравится оно
|
|||
29
Predator
03.07.20
✎
16:58
|
(26) а не создаст ли это других проблем? UDP ведь быстрее, чем TCP.
|
|||
30
arsik
гуру
03.07.20
✎
17:00
|
(29) Я бы сказал не быстрее а толще. UDP толще TCP.
|
|||
31
zaki
03.07.20
✎
17:30
|
(29) Тут вопрос в другом, хватает ли пропускного канала для обслуживания клиентов или нет, не всегда нужна очень быстрая скорость, важно стабильность особенно если это RDP
|
|||
32
zaki
03.07.20
✎
17:31
|
Да еще вам никто не запрещает использовать одновременно UDP или TCP, часть клиентов там часть там
|
|||
33
Predator
03.07.20
✎
18:06
|
(30) ну это уже кому как нравится) Суть в том, что для UDP не требуется подтверждения доставки пакета, что ускоряет передачу данных. Дальше уже вопрос в надёжности маршрута.
(31) пропускная способность канала - 100 Мбит/с со стороны сервера. Со стороны клиентов - у кого как. Сейчас все на удалёнке, работают на дому. (32) просто предчувствую недовольные возгласы "Адинэээс тормозиииит! Почему так меееедленноооо?" со стороны тех, у кого будет через TCP. |
|||
34
zaki
03.07.20
✎
18:14
|
(33) Скорость падает не в разы а где то на 20%, у нас используется UDP и TCP одновременно, на TCP сидит половина из 280 клиентов из за того что некоторые домашние провайдеры выборочно блокируют UDP и у них рвется связь в промежутке от 5 до 20 мин, на TCP такой проблемы не наблюдается
|
|||
35
Djelf
03.07.20
✎
18:22
|
(23) А как может сервер не отвечать 1-5 минут? Почему он отваливается?
А дыры могут быть везде, зачастую на ровном месте. И это было предположение, а не факт. |
|||
36
Predator
03.07.20
✎
18:32
|
(34) у нас проблема в том, что связь рвётся сразу у всех, поэтому, боюсь, перевод половины клиентов на TCP решит проблему только наполовину. Запрошу инфу у дата-центра - может, действительно, проблема на стороне их оборудования.
(35) перестаёт отвечать именно терминальный сервер (также сервер 1С, SQL, etc.), который не является сервером OpenVPN. Сервер OpenVPN при этом не падает и отвечает на пинги. |
|||
37
Predator
07.07.20
✎
20:58
|
Итак, проблема решилась отказом от OpenVPN между серверами в пользу L3 VLAN. Пользователи по-прежнему подключаются к терминалке через OpenVPN. За сегодня ни одного сбоя зафиксировано не было.
Всем спасибо за участие! |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |