При организации удаленной работы пользователей с файловой или клиент-серверной базой 1С через терминальный сервер (RDP) системные администраторы часто сталкиваются с неприятной проблемой. В обычных условиях подключение работает стабильно, но как только на роутере MikroTik (RouterOS) активируются строгие правила безопасности фильтрации трафика (например, запрет невалидных пакетов invalid или сброс всех прочих форвардов drop all other forwards), удаленные пользователи начинают жаловаться на постоянные переподключения.
Симптомы выглядят классически: если оставить программу 1С бездействующей на 5–15 минут (например, сотрудник отошел на обед или перерыв), при первой же попытке продолжить работу интерфейс зависает, после чего запускается процесс переподключения RDP-сессии. При этом в офисе по локальной сети все работает идеально. Давайте подробно разберем физику этого процесса, выясним скрытые причины такого поведения MikroTik и настроим фаервол так, чтобы обеспечить максимальную безопасность без ущерба для стабильности работы 1С.
Когда на MikroTik включается фильтрация сетевого мусора с помощью сброса невалидных соединений (action=drop connection-state=invalid), роутер начинает строго следить за состоянием каждого пакета. За это отвечает встроенный модуль отслеживания соединений — Connection Tracking. Каждое TCP- или UDP-соединение регистрируется в специальной таблице и имеет свой жизненный цикл (таймаут).
Для стандартного установленного TCP-соединения (established) дефолтный таймаут в RouterOS составляет 1 день (tcp-established-timeout=24h). Казалось бы, RDP-сессия на порту 3389 TCP должна жить сутками даже в состоянии простоя. Однако здесь кроется важный нюанс работы протокола TCP и оптимизаций RouterOS:
tcp-unacked-timeout, который по умолчанию составляет всего 5 минут.invalid (поскольку он идет с флагами ACK/PSH, но не имеет записи в таблице трансляций) и мгновенно сбрасывает его по правилу drop invalid. Пользователь получает зависший экран и последующее переподключение.Для решения этой проблемы мы можем безопасно увеличить данный таймаут в настройках отслеживания соединений MikroTik. Давайте выполним команду в терминале роутера:
/ip firewall connection tracking set tcp-unacked-timeout=30m
Увеличение этого значения до 30 минут (или даже до 1 часа) гарантирует, что даже во время обеденного перерыва неактивное TCP-соединение RDP не будет стерто из памяти роутера.
Начиная с версии протокола RDP 8.0 (встроена во все современные ОС Windows), для передачи графики, звука и потоковых данных (например, при печати чеков на ККМ Атол или работе с принтером) используется гибридный режим. Основное управление и авторизация идут по TCP (порт 3389), а основной поток данных перенаправляется на UDP (порт 3389).
Протокол UDP не имеет состояния (stateless), поэтому таймаут хранения UDP-трансляций в Connection Tracking MikroTik по умолчанию критически мал — всего 10 секунд (udp-timeout=10s). Стоит пользователю на пару десятков секунд прекратить генерацию графических изменений в 1С, как запись о UDP-сессии удаляется. При возобновлении активности новые пакеты блокируются правилами фаервола, вызывая микрозависания интерфейса 1С и принтеров.
Рассмотрим два пути решения этой проблемы:
Вариант А (Рекомендуемый для MikroTik): Увеличить таймаут хранения UDP-сессий на роутере до разумных пределов (например, до 30 секунд):
/ip firewall connection tracking set udp-timeout=30s
Вариант Б (Альтернативный): Полностью отключить использование протокола UDP для RDP-подключений на стороне Windows-сервера или клиентских компьютеров, принудительно заставив всю сессию работать только по надежному TCP. Это делается через групповые политики или реестр Windows (путь: Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Среда подключения сеансов -> Выбор протоколов передачи данных RDP — установить "Только TCP").
Проанализируем конфигурацию правил защиты от подбора паролей (RDP Brute Force), которую предоставил автор темы. При обрыве соединения из-за таймаутов клиентский компьютер начинает агрессивно и очень быстро (каждую секунду) пытаться восстановить связь, отправляя новые пакеты с флагом SYN.
Для цепочки правил защиты от брутфорса это выглядит как типичная хакерская атака:
stage-1.stage-2.stage-5 и автоматически заносится роутером в blacklist (черный список) на неделю.Чтобы избежать подобных ложных срабатываний, обязательно нужно добавить IP-адреса надежных удаленных офисов в белый список (accept_RDP) или использовать механизм Port Knocking («стук в порты») вместо стандартного и небезопасного открытия порта 3389 наружу.
Перейдем к оптимизации правил фильтрации. Многие начинающие администраторы перегружают фаервол лишними разрешающими правилами в цепочке forward. Если вы используете технологию проброса портов (NAT -> DST-NAT), вам не нужно создавать отдельные разрешающие правила для каждого порта в цепочке forward фильтра!
Правильный, безопасный и максимально производительный фаервол MikroTik строится на базе состояний соединений (Stateful Firewall). Давайте приведем конфигурацию к профессиональному стандарту, рекомендованному инженерами MikroTik (defconf):
/ip firewall filter
# 1. Разрешаем уже установленные, связанные и доверенные соединения в цепочке INPUT (для самого роутера)
add action=accept chain=input connection-state=established,related,untracked comment="Accept established, related, untracked"
# 2. Дропаем все невалидные пакеты, которые могут нарушить работу сети
add action=drop chain=input connection-state=invalid comment="Drop invalid packets to router"
# 3. Разрешаем ICMP (пинг) для диагностики сети
add action=accept chain=input protocol=icmp comment="Allow ICMP"
# 4. Блокируем ВСЕ остальные входящие запросы к роутеру из внешней сети (WAN)
add action=drop chain=input in-interface-list=WAN comment="Drop all other traffic to router"
# 5. В цепочке FORWARD разрешаем установленные и связанные соединения (основной рабочий трафик)
add action=accept chain=forward connection-state=established,related,untracked comment="Accept established, related"
# 6. Дропаем невалидные пакеты, проходящие через роутер
add action=drop chain=forward connection-state=invalid comment="Drop invalid packets through router"
# 7. Самое главное правило для проброса портов! Разрешаем любой трафик из WAN, который прошел через DST-NAT
add action=accept chain=forward connection-state=new connection-nat-state=dstnat in-interface-list=WAN comment="Accept all DST-NATed traffic"
# 8. Блокируем весь остальной новый трафик из внешней сети (WAN), который не был явно перенаправлен через NAT
add action=drop chain=forward connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="Drop all other WAN traffic"
Разберем, почему эта конфигурация идеальна для решения нашей проблемы:
/ip firewall nat. Больше не нужно плодить десятки разрешающих правил в фильтре.Удаленные пользователи 1С часто используют проброс локальных принтеров и ККМ (например, Атол 55Ф) внутрь RDP-сессии. При печати чека или тяжелого отчета формируются крупные пакеты данных. Если у удаленного сотрудника интернет подключен по технологиям PPPoE, L2TP или через 4G-модем, размер MTU (максимальный размер пакета) в канале может быть ниже стандартных 1500 байт (например, 1460 или 1480).
Когда большой пакет данных RDP пытается пройти через туннель с меньшим MTU, он фрагментируется. Если в фаерволе включена строгая блокировка невалидных пакетов, фрагменты могут отбрасываться роутером, вызывая зависание печати чека на ККМ Атол и обрыв сеанса 1С.
Чтобы избежать этого, настроим автоматическое уменьшение максимального размера сегмента TCP (MSS) под размер MTU канала с помощью таблицы Mangle:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn comment="Clamp TCP MSS for stable RDP"
Данное правило автоматически корректирует размер пакетов на лету, предотвращая их фрагментацию и гарантируя мгновенную и стабильную печать на торговом оборудовании Атол без зависаний сессии 1С.
Мы детально разобрали, почему стандартные настройки фаервола MikroTik могут приводить к дисконнектам пользователей 1С. Для обеспечения стабильной работы выполните следующие шаги:
tcp-unacked-timeout) до 30 минут.