Keenetic Giga KN-1012 — OpenVPN подключается, но отсутствует входящий трафик (RX 0), Inactivity timeout

[Saiyler]

Здравствуйте!

Прошу помочь разобраться с проблемой работы OpenVPN-клиента на роутере Keenetic Giga KN-1012.

Ранее OpenVPN исправно работал на роутере. Я использовал собственный VPN-сервер на VPS Timeweb Cloud для выборочного доступа к зарубежным сервисам (ChatGPT, YouTube и другим).

После обновления KeeneticOS с 5.2 Beta 1 до 5.2 Beta 3 OpenVPN перестал нормально работать.

1. Описание неисправности

OpenVPN успешно устанавливает соединение с сервером:

• Проходит TLS-согласование.

• Сертификаты успешно проверяются.

• Сервер назначает клиенту VPN-адрес 10.8.0.2.

• Keenetic показывает зелёный индикатор «Подключено».

• Счётчик «Отправлено» увеличивается.

• Счётчик «Принято» постоянно остаётся 0 Б.

При этом пользовательский IP-трафик через VPN не проходит.

Пример из системного журнала Keenetic:

Initialization Sequence Completed
Data Channel: cipher AES-256-GCM, peer-id: 0
Timers: ping 10, ping-restart 120

Примерно через 120 секунд:

[server] Inactivity timeout (--ping-restart), restarting

После этого соединение устанавливается заново, и проблема повторяется.

2. Оборудование и сеть

Роутер:

• Keenetic Giga KN-1012.

• Основной провайдер: Ufanet.

• Домашняя сеть: 192.168.50.0/24.

• Адрес роутера: 192.168.50.1.

• Подключение провайдера использует CGNAT.

VPN-сервер:

• Timeweb Cloud.

• Ubuntu 24.04.5 LTS.

• OpenVPN 2.6.19.

• Виртуальный интерфейс: tun0.

• VPN-подсеть: 10.8.0.0/24.

• Адрес сервера внутри туннеля: 10.8.0.1.

• Адрес клиента: 10.8.0.2.

Основной интернет через Ufanet работает нормально.

Дополнительно на этом же Keenetic используется WireGuard от AmneziaVPN, который успешно передаёт и принимает трафик. Через него необходимые сайты открываются.

3. Проверенные версии KeeneticOS

Проверял следующие версии:

KeeneticOS	Результат
5.2 Beta 3	OpenVPN не передаёт данные
5.2 Beta 1	OpenVPN не передаёт данные
5.1.8	OpenVPN не передаёт данные

После возврата на 5.2 Beta 1 проблема сохраняется.

4. Проверенные протоколы

На сервере Timeweb тестировались:

• OpenVPN UDP/1194.

• OpenVPN UDP/443.

• OpenVPN TCP/443.

Для TCP использовался отдельный серверный экземпляр с интерфейсом tun1 и подсетью 10.9.0.0/24.

Во всех случаях VPN-соединение устанавливалось, но пользовательский трафик не проходил.

5. Проверки сервера

Для исключения проблем с сервером была выполнена полная переустановка Ubuntu и OpenVPN.

После переустановки ситуация не изменилась.

Проверено:

• IPv4 forwarding включён.

• OpenVPN-сервер запускается успешно.

• Сертификаты принимаются.

• TLS-согласование завершается успешно.

• Сервер создаёт маршрут к клиенту.

• Правила NAT присутствуют.

• В проверенных правилах iptables/nftables явной блокировки IPv4-трафика не обнаружено.

• DCO на сервере отключён (dco_enabled,0).

Пример серверного статуса:

CLIENT_LIST,client,...,10.8.0.2,...
ROUTING_TABLE,10.8.0.2,client,...
GLOBAL_STATS,dco_enabled,0

6. Результаты проверки IP-трафика

С Keenetic выполнялся Ping:

PING 10.8.0.1

5 packets transmitted
0 packets received
100% packet loss

На VPS выполнялся Ping в обратном направлении:

ping -I 10.8.0.1 -c 5 10.8.0.2

Результат аналогичный — 100% потерь.

На серверном интерфейсе tun0:

RX: 0 bytes, 0 packets

При этом исходящие ICMP-пакеты появляются в счётчиках TX.

7. Проверка сетевых пакетов

Проводился захват трафика средствами Keenetic и tcpdump на VPS.

На сервере зафиксирована отправка зашифрованных UDP-пакетов в сторону Keenetic.

Например, при отправке пяти ICMP-запросов:

Timeweb → Keenetic UDP length 108
Timeweb → Keenetic UDP length 108
Timeweb → Keenetic UDP length 108
Timeweb → Keenetic UDP length 108
Timeweb → Keenetic UDP length 108

Также сервер отправляет служебные UDP-пакеты размером 40 байт примерно каждые 10 секунд.

В ранее выполненных сопоставлениях захватов эти пакеты не наблюдались на WAN-интерфейсе Keenetic после первоначального соединения.

Точное место потери или обработки пакетов пока не установлено.

8. Проверки настроек Keenetic

Дополнительно выполнялись:

• Отключение получения маршрутов от OpenVPN-сервера.

• Проверка отдельных политик доступа в интернет.

• Проверка маршрутов.

• Изменение исходящего интернет-подключения для OpenVPN.

• Проверка OpenVPN по UDP и TCP.

• Проверка работы WireGuard на том же роутере.

Отключение параметра «Получать маршруты от удалённой стороны» проблему не устранило.

В конфигурации Keenetic присутствуют статические IPv4-маршруты и доменные списки, используемые для выборочной маршрутизации.

9. Прошу помочь определить причину

Хотелось бы получить рекомендации разработчиков по следующим вопросам:

1. Известны ли проблемы OpenVPN-клиента на KN-1012 в KeeneticOS 5.2, при которых соединение успешно устанавливается, но входящий трафик остаётся нулевым?

2. Может ли причиной быть взаимодействие OpenVPN с политиками доступа, статическими маршрутами или одновременно работающим WireGuard?

3. Есть ли дополнительные диагностические команды KeeneticOS для проверки обработки входящих пакетов OpenVPN и состояния виртуального интерфейса?

4. Может ли наблюдаемое поведение быть связано с особенностями CGNAT или фильтрацией трафика на пути между провайдером Ufanet и VPS Timeweb?

5. Какие диагностические данные необходимо предоставить, чтобы определить, теряются ли пакеты до получения роутером или уже внутри OpenVPN-клиента?

6. Существует ли известное исправление или рекомендуемая версия KeeneticOS для этой ситуации?

Полный сброс роутера к заводским настройкам крайне нежелателен, поскольку на нём настроено много устройств, политик доступа, маршрутов и VPN-подключений.

Могу предоставить диагностический файл Keenetic, системные журналы и PCAP-захваты сетевых пакетов.

Прошу помочь определить причину неисправности и восстановить работу OpenVPN.

Заранее благодарю за помощь!