Я работаю сетевым администратором в финтех-компании. И в этой статье я расскажу о том, как решил проблему с постоянными обрывами 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_packet2. Приоритезация 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-соединений.
