Ошибка соединения по 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

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

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

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

[capzap]

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

[krollcbas]

Для начала создал соединение между двух роутеров Netcraze (в минимальной конфигурации). Добился пинга от сервера к клиенту (с этим были трудности).
Этот стенд собирал, чтобы проверить работоспособность сервера OpenVPN и уже далее рабочий файл клиентской конфигурации пытаться подгрузить в ПЛК210-4G

Файл подгружается, он корректный. Канал с сервером открывается (проходит пинг от ПЛК210 до домашнего роутера)
Однако не выходит достучаться до внешнего адреса ПЛК210 (определяю на странице диагностики)

2026-01-02_04-40-22.png
2026-01-02_04-49-16.png

[capzap]

Однако не выходит достучаться до внешнего адреса ПЛК210 (определяю на странице диагностики)]

так же можно с самого плк узнать внешний (публичный) адрес роутера командой curl ifconfig.me который раздает интернет конкретному ПЛК, это не совсем то что внешний адрес ПЛК210

Если клиент не настроен на форвардинг, пакет не пройдёт.
На клиенте (Linux) включите форвардинг sysctl net.ipv4.ip_forward=1
На клиенте настройте NAT, чтобы трафик из VPN шёл через внешний интерфейс
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # eth0 — внешний интерфейс клиента
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

Если NAT и MASQUERADE настроен то команда iptables -t nat -L -n -v покажет статистику больше нуля в соответствующей зоне