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

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

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

Введение

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

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

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

544fc8532400118b91a7279f5b57fb60.png

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

234e83ee53e5f708c27444d4a8fbbe33.pngd660c66095a8da7a12283361db737d0b.png4d80955d5c8d4a67f6092812e83484b1.png

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

Для правил Mangle необходимо выбрать вид маркируемого трафика: forward (проходящий), input (входящий) или output (исходящий).

Для правил Mangle необходимо выбрать вид маркируемого трафика: forward (проходящий), input (входящий) или output (исходящий).

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

·         Chain — forward

·         Protocol — TCP

·         Dst. Port — 3389

mark-connection – маркировка пакетов на всем соединении, которое соответствует правилу, mark-packet – маркировка пакетов, которые соответствует правилу

mark-connection — маркировка пакетов на всем соединении, которое соответствует правилу, mark-packet — маркировка пакетов, которые соответствует правилу

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

·         Action — mark connection

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

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

db036ce45af99e31cec7d1dcd3bff4e7.png235a48e648fb9730119ab281e29e9be5.png

В той же вкладке 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-трафика.

ebaee7c093c5b333f23f74629f7becb0.png919691b0a7c6db06fd33fe864b7951a1.png

Нажмите кнопку 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-соединений.

© Habrahabr.ru