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