hAP AC LAN<->WAN постепенное замедление

Без очередей. Я думал настроить очереди, чтобы посмотреть, изменит ли это ситуацию. На 100% уверен, что это не связано с интернет-провайдером, так как устройство в другом порту на предоставленном провайдером шлюзе получает полную полосу (в то время как замедление происходит на hAP AC).

Похоже, я воспроизвел эту проблему на совершенно другой машине без OpenVPN. Судя по всему, когда устройство использует около ~1-5 Мбит/с UDP, это постепенно замедляет hAP AC. Как только я останавливаю трафик, скорость восстанавливается, и после повторного запуска UDP трафика она снова начинает медленно падать. Эта проблема ОЧЕНЬ раздражает, мне бы не хотелось тратить деньги на решение, если есть какой-то способ это исправить.

Я проводил очень схожие тесты, но, возможно, повторю их, чтобы исключить все переменные. У провайдера используется Mikrotik RB2011 в качестве шлюза, и они проводили тесты во время замедления, достигая полной пропускной способности. У меня есть другая сеть (через тот же NAT на hAP AC), и она также испытывает замедление. Когда у меня было замедление, ПК на другом порту шлюза (не hAP AC) стабильно показывал полную скорость. Провайдер здесь не злонамерен, они очень отзывчивы. Я точно знаю, какое приложение вызывает замедление: geth (узел/клиент сети Ethereum), в частности, протокол обнаружения geth через UDP. Редактирование: похоже, TCP тоже влияет, UDP усугубляет ситуацию. Если я инкапсулирую трафик geth через OpenVPN UDP, замедление все равно происходит. Если трафик инкапсулирован в TCP, замедления нет. Проблема не в отслеживании соединений, так как с OpenVPN UDP отслеживается только одно соединение. Проблема не в фаст-трекинге или перегрузке ЦП, я отключил фаст-трек, уничтожил таблицу отслеживания соединений и все равно получил то же замедление. Единственное, что мне нужно сделать, чтобы остановить замедление, - это отключить переадресацию портов на узел geth (и подождать, пока сессии не завершатся или перезапустить geth). Фактическая статистика UDP-пакетов ужасна — трафик не наводняет узел. Для того чтобы hAP AC упал на колени, требуется примерно 100 кбит/с трафика обнаружения geth. Я собираюсь потратиться на RB4011 (как только он появится в наличии) и забыть об этом (надеюсь, с другой архитектурой и с гораздо большим ЦП). Я могу позволить себе ограниченное время простоя при тестировании, прежде чем другие пользователи начнут жаловаться. Редактирование: я также использую iperf3 для тестирования пропускной способности (другая сторона поддерживает 40+ Гбит/с). Честно говоря, вещи от Ookla (speedtest.net) — это мусор, они полностью зависят от производительности браузера, а трафик ведет себя глупо (нагрузка — это паттерн ABCDEF… ASCII, который можно легко обмануть с помощью LZO).