server

Спасибо, про задержку перед заполнением ipset понял. Фрагмент CLI я привёл, чтобы показать правило внутри Policy0. Хотел уточнить: у меня SYN уже уходит через PPPoE0, а следующие пакеты того же TCP-потока — через Wireguard6 с адресом МТС после NAT. То есть меняется выходной интерфейс уже начатого соединения, ответов на WireGuard для этих пакетов нет. Именно эта смена пути тоже является ожидаемым поведением? В приложении задержки составляют 20–30 секунд, иногда больше минуты. Какая длительность задержки предусмотрена для подготовки ipset? И подскажите, пожалуйста, какую конкретно настройку проверить в веб-интерфейсе для Policy0, чтобы весь TCP-поток к адресам из группы проходил через PPPoE0. Могу подготовить self-test и пример одного соединения с временными метками пакетов, если это поможет.

Да, речь о пользовательской политике vpn (Policy0), к которой привязан Apple TV. Основной выход — Wireguard6, резервный — провайдер МТС через PPPoE0. Для группы доменов VK и okcdn.ru нужен выход через PPPoE0. На Netcraze Ultra NC-1812 уже установлена 5.2 Beta0 (5.02.B.0.0-0). Правило настроено именно внутри Policy0: ip policy Policy0 description vpn permit global Wireguard6 permit global PPPoE0 dns-proxy route object-group domain-name-list-1 PPPoE0 auto reject В этой конфигурации SYN уходит через PPPoE0, а последующие пакеты того же TCP-потока появляются на Wireguard6 с исходным адресом МТС после NAT. Это наблюдалось у 12 соединений; ответов на WireGuard для них нет. При статических /32 через PPPoE0 в той же Policy0 задержки исчезают. DNS телевизора — роутер, адреса назначений есть в выученном списке FQDN-группы. Подскажите, корректно ли настроено FQDN-правило для такой схемы? Должно ли оно удерживать весь TCP-поток на PPPoE0? Если для проверки нужны self-test или дополнительные данные, уточните, что собрать и при каких настройках.

Спасибо за пояснение. Понимаю, что DNS-маршруты и статические /32 — разные механизмы, поэтому успешная работа со статическими маршрутами сама по себе ещё не доказывает ошибку DNS-маршрутизации. Хотел бы уточнить именно наблюдение из одновременного захвата на LAN, PPPoE0 и Wireguard6: SYN уходит через PPPoE0, а последующие пакеты того же TCP-потока появляются на Wireguard6 с исходным адресом МТС после NAT. Ответов на WireGuard для этих потоков нет. Такое наблюдалось у 12 соединений; 289 пакетов сопоставлены с LAN по seq/ack/flags/длине TCP payload, совпадающих копий на PPPoE0 в пределах ±100 мс не найдено. DNS телевизора — роутер, домены включены в FQDN-группу, PPPoE0 в момент проверки работает. Конкретную внутреннюю причину я пока не установил. Можете пояснить, относится ли «ожидаемое поведение» только к различию механизмов или также к описанной смене выходного интерфейса одного TCP-потока с сохранением исходного адреса МТС? И как правильно настроить эту схему штатным FQDN-правилом: основной выход устройства через WireGuard, а группа VK — через PPPoE0, без обслуживания списка /32? Если нужны дополнительные проверки или self-test, подскажите, какие данные собрать и в каком состоянии настроек.

Netcraze Ultra NC-1812, NDMS 5.2 Beta 0 (5.02.B.0.0-0): обход WireGuard через FQDN в пользовательской политике У меня воспроизводится похожее поведение. Проверки проводились 8–9 октября 2026 года. Ниже — наблюдения из захватов пакетов, CLI и контрольных запусков приложения. Схема: провайдер МТС, PPPoE0, 1 Гбит/с; один активный WireGuard-клиент Wireguard6, сервер в Германии. Apple TV подключён по Ethernet и назначен политике vpn / Policy0. Основной выход этой политики — Wireguard6, резервный — PPPoE0. Требуется направлять VK Видео через PPPoE0, сохраняя VPN для остальных назначений. IPv6 отключён. В захвате DNS-запросы телевизора поступают на роутер. MTU PPPoE — 1492, WireGuard — 1280; при сравнении вариантов эти значения не менялись. Домены VK и okcdn.ru уже присутствуют в FQDN-группе, адреса назначений есть в выученном списке этой группы. Сокращённый фрагмент конфигурации, без правил других сервисов и без временных статических маршрутов: object-group fqdn domain-name-list-1 description VK_MTS include vk.com include vk.ru include vk.me include userapi.com include vkuser.net include vkuseraudio.net include vkuseraudio.ru include vkuserphoto.ru include vkvideo.ru include vk-cdn.net include vk-portal.net include cdn-vk.ru include remote-mobile-config.studilka.ru include okcdn.ru ! ip policy Policy0 description vpn permit global Wireguard6 permit global PPPoE0 dns-proxy route object-group domain-name-list-1 PPPoE0 auto reject ! Ожидается: соединение к адресу из этой группы целиком проходит через PPPoE0. Наблюдается: первый запуск некоторых серий VK Видео задерживается на 20–30 секунд, иногда больше минуты; повторный запуск может быть быстрым. При временном переводе телевизора целиком на прямой МТС серии запускались сразу. Проведён одновременный захват на LAN, PPPoE0 и Wireguard6: 1. У 12 затронутых TCP-соединений исходный SYN проходит через PPPoE0. 2. Затем 289 исходящих пакетов тех же соединений появляются на Wireguard6 с исходным IPv4-адресом PPPoE0. На WireGuard ответов для этих потоков в записи нет. 3. Все эти 289 пакетов сопоставлены с LAN телевизора по seq/ack/flags/длине TCP payload. Совпадающих копий на PPPoE0 в пределах ±100 мс не найдено. 4. CLI показывает NAT на адрес МТС, но у части зависших потоков остаётся метка основной VPN-политики 0x0ffffaaa вместо метки маршрута VK 0x0ffffaab. Это значения в моей конфигурации, не универсальные значения для других устройств. Контрольные проверки: — Выключение одновременно software PPE и hardware PPE задержку не устранило: первая и четвёртая серии ожидали около 20 секунд. После проверки оба ускорителя включены обратно. — Восемь пробных статических IPv4 /32 через PPPoE0 в той же Policy0 исправили путь только для покрытых адресов. В этой записи 41 соединение к шести использованным адресам с такими маршрутами не попало в WG, но 10 соединений к другим адресам VK дали ещё 201 пакет на WG. Задержки в приложении сохранились. — После добавления /32 для всех 136 текущих IPv4-адресов FQDN-группы VK все пять контрольных серий стартовали без задержек; ошибочных потоков VK с адресом МТС на WireGuard в этой записи не осталось. — Во время теста группа выучила ещё шесть адресов. Итоговый временный обход — 142 отдельных /32 в Policy0 через PPPoE0, auto reject. Целые подсети не добавлялись; исходное FQDN-правило сохранено. — Финальный пользовательский контроль с выключенным захватом и обоими включёнными PPE: семь серий без задержек. Основной VPN для остального трафика сохранён. Таким образом, наблюдаемый сбой связан с различием пути пакетов одного TCP-потока при FQDN-правиле и при обычном статическом маршруте в той же политике. Внутреннюю причину, например конкретный дефект обработки CONNMARK, пока не утверждаю. Подскажите, пожалуйста, известна ли такая проблема для 5.2 Beta 0 на NC-1812 и какие дополнительные данные нужны для её проверки? Хотелось бы обойтись штатным доменным правилом без постоянного обслуживания списка IP. Self-test, CLI-выводы и исходные захваты за время проверки сохранены; диагностические материалы можно подготовить отдельно по правилам форума.