Ошибка соединения по VPN

[ВладОвен]

Привет.
Помогите разобраться проблеме.
Контроллер СПК110 исправно работал в openVPN-сервером версии 2.6.8, но не хочет работать с сервером версии 2.6.12.

Я настроил сервер. Другие клиенты (Виндовс) к нему подключены. Связь норм.
Среди настроек сервера есть такие:

ncp-ciphers AES-256-GCM:CHACHA20-POLY1305
tls-auth /etc/openvpn/openvpn_certs/ta.key 0
auth-nocache

А у СПК110 я вписал:


cipher AES-256-GCM

Я проверил синтаксис старого файла (для 2.6.8) и нового (для 2.6.12) и разница только в количестве строк в секциях CA и CERT.
Синтаксис, конфиги - вроди теже....
Только порт у меня нестандартный - №2025.
Сам СПК110 пишет, что "Конфигурация корректная".

СПК110 не подключается. Устройство tap не появляется среди интерфейсов (ifconfig).
В логах сервера я вижу:



2025-03-10 11:39:19 Authenticate/Decrypt packet error: packet HMAC authentication failed
2025-03-10 11:39:19 TLS Error: incoming packet authentication failed from [AF_INET]aa.bb.cc.dd:1194

Что я делаю не так?

[Евгений Кислов]

Добрый день.

Контроллер СПК110 исправно работал в openVPN-сервером версии 2.6.8, но не хочет работать с сервером версии 2.6.12.

Какая версия OpenSSL в 2.6.12?
Наши контроллеры поддерживают не выше 1.1.1j.

[ВладОвен]

Здравствуйте, Евгений.

В новом сервере openVPN 2.6.12 и OpenSSL 3.3.3. (не работает)
В старом сервере openVPN 2.6.8 и OpenSSL 3.1.2. (работает)

А в СПК110 openVPN 2.5.2 и OpenSSL 1.1.1j.

Что можно сделать?
Можно ли обновить OpenSSL в СПК110?

[Евгений Кислов]

Что можно сделать?

Возможно, на стороне сервера путем каких-то настроек можно разрешить подключение клиентов с устаревшей OpenSSL.


Можно ли обновить OpenSSL в СПК110?

Силами пользователя - нет.
Возможно, обновление OpenSSL произойдет в одной из будущих прошивок (маловероятно, что в этом году).

[ВладОвен]

Все же не совсем так.
Я разобрался.

СПК110 с openVPN 2.5.2 и OpenSSL 1.1.1j работает хорошо с сервером openVPN 2.6.12 и OpenSSL 3.3.3.

Я думал, что из-за длины DiffieHellman. В версии openSSL 3.3.3 требуется 2048бит (1024бит уже считается устаревшим). Но дело не в этом. При длине в 2048 бит работает тоже нормально.

Проблема в параметре на сервере:


tls-auth /etc/openvpn/openvpn_certs/ta.key 0

Вот этот вот "0" на конце - это направление, которое может быть 0 или 1.
Значение 0 указывает, что ключ используется на стороне сервера, а значение 1 — на стороне клиента.
Он помогает различать, с какой стороны (клиентской или серверной) используется ключ для защиты соединения.
Этот параметр важен для правильной настройки и работы функции аутентификации TLS, поскольку сервер и клиент должны знать, как правильно интерпретировать ключ.

И это работает только тогда (!), когда мы кладем файлы ключей .pem (4 шт.) рядом с конфигурационным файлом .ovpn
А если мы вписываем данные ключей прямо в конфигурационный файл (вроде, это называется inline), то это направление нельзя использовать. И СПК110 может принимать данные ключей только в таком формате!
Тогда параметр на сервере должен быть таким:


tls-auth /etc/openvpn/openvpn_certs/ta.key

Без задания направления.
Т.е. проверка направления не проводится.

[ВладОвен]

Для всех других клиентов этой ВПН-сети, которые умеют читать файлы ключей .pem, лежащие рядом с конфигурационным файлом .ovpn,
нужно тоже отключить проверку направления.
Было:

tls-auth ta.key 1
Стало:

tls-auth ta.key

Полет нормальный. :cool:

[Евгений Кислов]

Спасибо за предоставленную информацию.

[capzap]

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