Комментарии 10
MFA делали на базе Endpoint VPN, однако MFA затронул соединение RDP в тоннеле VPN. Сам MFA был сделать для поднятия безопасности самого vpn соединения.
Решение проблемы - магическое, без понимания причин и следствия.
Задушив Rdp трафик, вы ничего не сделали со всем остальным трафиком, а значит потери пакетов из-за превышения емкости канала связи вас ещё догонят.
Приоритет в очередях работает совсем не так, как вам вероятно показалось. У вас нет других, конкурирующих с этой очередей, а значит приоритет - просто ничего не значащая цифра.
Изучите то, что называется QoS, прежде, чем делать непонятно что. В вашем случае, вам надо изучать нагрузку на интернет канал в целом, вероятно там у вас возрос трафик и пошёл отброс пакетов как попало. После внедрения полноценного QoS на сети (хотя-бы на Edge роутере), вы кардинально порешаете многие сетевые проблемы в компании. Но тема эта не простая, для упрощения написано уже масса скриптов, решающих задачу генерации сотен правил.
уточните пожалуйста, на каком софте делали MFA для RDP?
Заголовок: как я решил проблему с постоянными обрывами...
Статья: никак. Но вот вам скриншоты...
Классической причиной такого поведения (дисконнекты RDP через одно и то же время) в сетях с использованием NAT на маршрутизаторах от Mikrotik является слишком короткий UDP Connection Timeout в параметрах Connection Tracking по умолчанию.
У RDP есть встроенный механизм UDP Transport Acceleration, работающий начиная с RDP 8. Через некоторое непродолжительное время после установки соединения по 3389/tcp клиент инициирует обмен по UDP. Поскольку этот обмен не очень интенсивный, виртуальное соединение в Conntrack успевает усохнуть и начинаются проблемы.
Решение обычно тривиальное и сводится к увеличению UDP Connection Timeout до 30 секунд.
Не план руете отказаться от UDP и понять, чем забит канал?
Как я решил проблему с постоянными обрывами RDP-соединения после внедрения MFA-аутентификации