Как я решил проблему с постоянными обрывами RDP-соединения после внедрения MFA-аутентификации

Я работаю сетевым администратором в финтех-компании. И в этой статье я расскажу о том, как решил проблему с постоянными обрывами RDP-соединения в сети компании после внедрения в рабочие процессы MFA-аутентификации. Стоит отметить, что в процессе решения я не нашел каких-либо полезных для этого материалов в Интернете, что и побудило меня написать статью.

Подразумевается, что читатель знаком с такими понятиями и технологиями, как VPN, MFA, RDP, а также с утилитой Wireshark и сетевым оборудованием Mikrotik. В противном случае рекомендую ознакомиться с информацией по ссылкам.

Введение

После внедрения в рабочие процессы компании MFA-аутентификации появилась проблема - RDP-соединение обрывалось каждые 10-15 минут. Это сильно мешало работе сотрудников, в основном при работе с сервером 1С. К сожалению, точную причину проблемы в итоге мне выявить не удалось, но сама проблема все же была решена.

Анализ проблемы

Для детального изучения проблемы я решил использовать инструмент для захвата и анализа сетевых протоколов Wireshark. Подключившись к серверу с помощью RDP с использованием VPN, я начал захват и анализ сетевых пакетов на сетевом интерфейсе VPN с целью выявления возможного нестандартного поведения потока передачи данных.

1. Общий обзор сессии:

На скриншоте виден захват пакетов, относящихся к сессии RDP. Основные IP‑адреса, участвующие в обмене — 172.16.10.148 (клиент) и 192.168.201.100 (сервер). Присутствуют пакеты, относящиеся к различным протоколам: RDPUDP2, TCP, TLSv1.2, и ARP, что указывает на установку защищенного RDP‑соединения с использованием UDP и шифрования.

2. Повторные передачи и дублирующие подтверждения:

Повторная передача (Retransmission) указывает на то, что исходный пакет не был доставлен получателю, что часто связано с потерей пакетов в сети или значительной задержкой.

Дублирующее подтверждение (Dup ACK) также указывает, что получатель не получил ожидаемый сегмент данных и отправил подтверждение для другого сегмента, полученного ранее.

На скриншоте можно видеть несколько случаев повторной передачи и дублирующих подтверждений. Например, имела место попытка повторной передачи пакета № 9134, а подтверждение о получении пакета № 9133 было продублировано.

3. Роль пакетов с протоколом TLS:

Протокол TLSv1.2 (пакеты № 9143–9152) показывает передачу зашифрованных данных в сессии RDP. Проблемы с передачей TLS‑пакетов могут также свидетельствовать о неполадках в сети, влияющих на зашифрованные данные.

4. Анализ флага TCP Reset:

Наиболее важным индикатором обрыва соединения является пакет № 9174, который содержит TCP Reset (RST) флаг. Он сигнализирует о том, что соединение было принудительно разорвано одной из сторон. В данном случае, вероятно, инициатором является клиент.

Принудительное завершение соединения часто происходит в случае, если хост не получает ожидаемого ответа в течение фиксированного времени или сталкивается с критической ошибкой.

Выводы

Обрыв соединения произошел из-за серии неудачных попыток передачи данных и дублирующих подтверждений, что привело к принудительному завершению клиентом TCP-сессии с помощью флага RST.

На основе проведенного анализа пакетов можно предположить, что проблема была связана с задержками или потерями пакетов на сетевом уровне. А это, вероятно, было вызвано некорректной настройкой сетевого оборудования и резко возросшей нагрузкой, связанной с внедрением MFA.

Поскольку сбои сильно мешали работе сотрудников, было принято решение провести приоритезацию трафика. Этот метод гарантировал бы, что RDP-трафик будет обрабатываться с более высоким приоритетом, что минимизирует влияние потенциальных сетевых задержек и потерь пакетов на стабильность соединения.

 Решение проблемы:

 Проблема была решена путем настройки правил для маркировки проходящего RDP-трафика по порту 3389 с помощью службы Mangle, настройки которой находятся по пути IP->Firewall в утилите Winbox

 1.1. Маркировка соединений:

На вкладке General выберите:

·         Chain - forward

·         Protocol - TCP

·         Dst. Port - 3389

На вкладке Action выберите:

·         Action - mark connection

·         New Connection Mark - допустимое имя метки (например, rdp_conn)

 1.2 Маркировка пакетов

В той же вкладке Mangle нажмите Add (+) и проделайте аналогичные действия:

·         Chain - forward

·         Connection Mark - ранее созданная метка соединения

·         Action - mark packet

·         New Packet Mark - допустимое имя метки (например, rdp_packet)

 Нажмите OK для сохранения правила.

1.3. Чтобы выполнить те же действия в терминале, используйте следующие команды:

/ip firewall mangle

add chain=forward protocol=tcp dst-port=3389 action=mark-connection new-connection-mark=rdp_conn

add chain=forward connection-mark=rdp_conn action=mark-packet new-packet-mark=rdp_packet

 2.       Приоритезация RDP-трафика.

Нажмите кнопку Add (+) в правом верхнем углу, чтобы создать новую очередь и в открывшемся окне задать значения следующих параметров:

• Name - название очереди (queue1RDP)

• Parent - global (очередь будет применяться ко всему трафику)

• Priority - 1 (наивысший приоритет)

• Packet Mark - ранее созданная метка пакета (rdp_packet)

• Max Limit - 2M

• Остальные параметры оставить по умолчанию, если нет специфических требований

Нажмите OK для сохранения очереди.

Убедитесь, что новая очередь появилась в списке очередей, активна и настроена с максимальным лимитом 2 Мбит/с. Теперь трафик, маркированный как rdp_packet, будет обрабатываться с высоким приоритетом и с ограничением на пропускную способность до 2 Мбит/с.

 Чтобы выполнить те же действия в терминале, используйте следующие команды:

/queue tree
add name=rdp_priority parent=global priority=1 packet-mark=rdp_packet

Результат

После внесения описанных изменений сбои сразу же прекратились. Несмотря на то, что причина проблемы так и осталась невыясненной, предложенное решение показало свою эффективность на практике, улучшив стабильность работы RDP-соединений.