При переносе баз 1С на новые серверы системные администраторы часто сталкиваются со странными сетевыми аномалиями. Проанализируем типичную, но очень запутанную ситуацию: сервер 1С перенесен с Windows Server 2012 на Windows Server 2016. Большинство клиентов из локальной сети и через интернет подключаются успешно. Однако несколько внешних организаций полностью теряют доступ по WEB — при попытке входа возникает ошибка HTTP при подключении к серверу, превышено время ожидания. Не работает ни браузер, ни тонкий клиент, а пинг до сервера пропадает.
Самое интересное в этой ситуации заключается в "магии" сторонних программ: если на проблемном клиентском компьютере запустить утилиту удаленного доступа (например, AnyDesk), клиент 1С внезапно начинает работать и подключаться к базе! Разберем по шагам, куда копать в такой ситуации и как поэтапно диагностировать эту головоломку.
Прежде чем погружаться в дебри маршрутизации, выясним причину на базовом уровне: проблема в связи до сервера или в самой публикации 1С? Рассмотрим порядок проверки.
Документ по умолчанию, если он был отключен.Если тестовая страница не открывается, значит проблема 100% на уровне сети, маршрутизации или фаервола, а не в настройках самой базы 1С или конфигурационного файла default.vrd.
Если кажется, что клиент "ломится не туда", необходимо сделать трассировку маршрута командой tracert до внешнего IP-адреса сервера. Если трассировка обрывается на последнем участке (между шлюзом провайдера и вашим сервером 1С), это означает, что пакеты доходят до вашей инфраструктуры, но сервер либо их отбрасывает, либо не может отправить ответ обратно.
Воспользуемся мощным инструментом диагностики — анализатором трафика. Установим на сервер 1С программу Wireshark. Проведем следующий тест:
icmp (для отслеживания пингов) или tcp.port == 80 (для веб-трафика).Посмотрим на результаты захвата. Если запрос (пакет TCP SYN) приходит на интерфейс, вы его увидите. Это означает, что маршрут "туда" исправен. Далее посмотрите, отправляет ли сервер ответ (TCP SYN-ACK или эхо-ответ ICMP). Если сервер принимает пинг, но не отвечает — проблема в маршрутизации обратного пути на самом сервере. Если же пакеты вообще не появляются в Wireshark, проблема находится на стороне провайдера или шлюза.
Рассмотрим специфику самой операционной системы. Переход на Windows Server 2016 привносит новые функции оптимизации сети, которые включены по умолчанию. Одна из них — RSC (Receive Segment Coalescing). Эта технология объединяет несколько полученных TCP-сегментов в один большой пакет перед передачей его сетевому стеку операционной системы.
При использовании определенных коммутаторов (например, оборудования Eltex) или специфических настроек провайдера функция RSC может ломать обработку пакетов. Симптомы как раз соответствуют нашей проблеме: постоянные таймауты HTTP, обрывы соединений и игнорирование пакетов с конкретных внешних IP-адресов.
Отключим эту функцию для проверки. Откройте PowerShell от имени администратора и выполните следующие команды:
# Проверяем статус RSC на сетевых адаптерах
Get-NetAdapterRsc
# Отключаем RSC для нужного интерфейса (замените имя на свое)
Disable-NetAdapterRsc -Name "Ethernet"
Также рекомендуется временно отключить TCP Offload (IPv4 Checksum Offload, Large Send Offload) в дополнительных свойствах самой сетевой карты через диспетчер устройств.
Проанализируем ситуацию, когда установка соединения (мелкие пакеты) проходит, а передача данных (большие пакеты с веб-страницами 1С) — нет. Это классический признак проблемы с размером пакета (MTU).
Если на пути между тремя проблемными организациями и вашим сервером оборудование провайдера использует инкапсуляцию (VPN, PPPoE), размер полезной нагрузки (MTU) уменьшается. По стандарту, если пакет слишком велик, маршрутизатор должен отправить обратно ICMP-сообщение Fragmentation Needed. Но часто провайдеры или администраторы из соображений безопасности блокируют все ICMP-пакеты. Возникает эффект "черной дыры": пакет просто уничтожается, а клиент 1С ждет ответа до бесконечности, выдавая ошибку таймаута.
Чтобы проверить эту гипотезу, попробуйте принудительно уменьшить размер MTU на клиентском компьютере проблемной организации (например, до значения 1300). Если после этого клиент 1С успешно запустится — вы нашли причину. Потребуется грамотная настройка Firewall на сервере с разрешением служебных ICMP-сообщений.
Поскольку сервер "переехал" на новую машину, у него гарантированно изменился аппаратный MAC-адрес сетевой карты. В инфраструктуре без центрального роутера, когда от провайдера приходит оптика в медиа-конвертер и сразу в коммутатор (неуправляемый хаб или настроенный VLAN), IP-адрес сервера привязывается к оборудованию провайдера напрямую.
У провайдера в кэше ARP могли остаться старые записи для маршрутов от этих трех конкретных организаций (если они тоже используют этого же провайдера, либо настроены через Policy-Based Routing). Провайдер исправно доставляет пакеты до вашего коммутатора, но отправляет их на старый MAC-адрес (которого уже нет в сети). В результате пакеты растворяются в воздухе на последнем участке трассировки.
Решение: свяжитесь со службой технической поддержки провайдера и попросите сбросить ARP-таблицу (очистить кэш MAC-адресов) для вашего IP-адреса.
Часто системные администраторы говорят: "На сервере отключена вся возможная защита". Но в Windows Server 2016 простое отключение брандмауэра через графическую панель не всегда полностью снимает блокировки на уровне ядра (WFP - Windows Filtering Platform).
Проверьте, какой профиль сети присвоен вашему сетевому интерфейсу. Если сеть определилась как Публичная (Public) или Неопознанная (Unidentified), скрытые алгоритмы защиты могут тихо сбрасывать входящие соединения от IP-адресов, которые считаются недоверенными. Измените профиль сети на Частный (Private) с помощью PowerShell:
# Получаем индекс сетевого интерфейса
Get-NetConnectionProfile
# Меняем профиль сети на Private
Set-NetConnectionProfile -InterfaceIndex <Индекс_сети> -NetworkCategory Private
Выясним причину главного феномена: почему при запуске сессии AnyDesk к клиентской машине клиент 1С начинает работать? Этому есть логическое техническое обоснование.
Любые современные программы для удаленного управления (AnyDesk, TeamViewer) используют продвинутые механизмы обхода NAT и нестабильных сетей. Когда вы запускаете AnyDesk, происходит следующее:
Именно поэтому "оживление" 1С через AnyDesk является не мистикой, а явным индикатором того, что прямой канал связи между клиентом и сервером блокируется (по MTU, из-за фильтрации портов или кэша ARP), а инкапсулированный трафик проходит свободно. Воспользуйтесь описанными выше шагами, проанализируйте трафик через Wireshark, и вы обязательно найдете точку, на которой пакеты теряются!