Здравствуйте!
Прошу помочь разобраться с проблемой работы 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. Прошу помочь определить причину
Хотелось бы получить рекомендации разработчиков по следующим вопросам:
Известны ли проблемы OpenVPN-клиента на KN-1012 в KeeneticOS 5.2, при которых соединение успешно устанавливается, но входящий трафик остаётся нулевым?
Может ли причиной быть взаимодействие OpenVPN с политиками доступа, статическими маршрутами или одновременно работающим WireGuard?
Есть ли дополнительные диагностические команды KeeneticOS для проверки обработки входящих пакетов OpenVPN и состояния виртуального интерфейса?
Может ли наблюдаемое поведение быть связано с особенностями CGNAT или фильтрацией трафика на пути между провайдером Ufanet и VPS Timeweb?
Какие диагностические данные необходимо предоставить, чтобы определить, теряются ли пакеты до получения роутером или уже внутри OpenVPN-клиента?
Существует ли известное исправление или рекомендуемая версия KeeneticOS для этой ситуации?
Полный сброс роутера к заводским настройкам крайне нежелателен, поскольку на нём настроено много устройств, политик доступа, маршрутов и VPN-подключений.
Могу предоставить диагностический файл Keenetic, системные журналы и PCAP-захваты сетевых пакетов.
Прошу помочь определить причину неисправности и восстановить работу OpenVPN.
Заранее благодарю за помощь!
