Ошибка загрузки сетевой инфраструктуры 1с
Сервер 1С находится на одном сервере, пользователи подключаются с другого сервера по тонкому клиенту.
Столкнулись с проблемой: после какого-то кол-ва пользователей зашедших в базу, новых перестает пускать - просто падает платформа. Началось внезапно, ничего не меняли, ни конфигурацию, ни платформу, ни сервер. На текущей платформе проработали больше месяца нормально. Через технологический журнал на клиенте выцепил ошибку, с которой падает платформа "Обычно разрешается одно использование адреса сокета (протокол/сетевой адрес/порт)". Ошибку это возвращает платформе винда, везде пишут, что проблема в том, что не хватает динамических портов, которые можно расширить через реестр, но это не помогло.
Через netstat -ano на сервере удаленных рабочих столов, откуда подключаются пользователи видно, что заняты все порты с 1560 по 1591 тонким клиентом. Но многие клиенты сидят на рандомных портах типа 45434. Заметили, что новые пользователи не могут зайти в базу, когда все порты 1560-1591 заняты. Если убить любого тонкого клиента, который занимает порт в этом диапазоне и порт освобождается, то новый пользователь может зайти в базу.
Так же, когда все эти порты заняты, не получается запустить отладку из конфигуратора, ругается на "Для выполнения отладки необходимо включить поддержку сетевого протокола TCP/IP" - что тоже описано в инете как проблема занятых портов.
Не понятно, зачем тонкому клиенту на сервере удаленных рабочих столов занимать эти порты, ведь используются они сервером 1С для рабочих процессов. И почему когда свободных портов нет на РДП сервере, клиент не может подключиться к серверу 1С. Но часть клиентов спокойно висят на рандомных портах типа 45434. Такое ощущение, что при коннекте, клиент все таки занимает какой-то из портов в этом диапазоне, а после этого его перекидывает на любой свободный до 65535, но эти порты из диапазона 1560-1591 не успевают освободиться.
Объясните, по какому принципу клиент занимает порты и можно ли это как-то где-то настроить? То, что происходит в описанной ситуации это какой-то сбой либо некорректная настройка и достаточно в настройках службы 1С указать бОльший пул портов? Но никогда не слышал, чтобы в базах, где работает большое кол-во пользователей, увеличивали диапазон портов для рабочих процессов на сервере 1С.
В первый раз появилось на платформе 8.3.14.1854, после этого откатились на 8.3.12.1685, на которой были несколько месяцев, ситуация не изменилась.
вам хватит на 1 локальный порт 1561 всех подключить
сбрасывайте настройки в дефолт, переустанавливайте платформу.
(2) Так какие настройки? На РДП сервере стоит только тонкий клиент, какие и где там настройки можно сбросить?
6. Необходимо настроить сетевой стек для обеспечения возможности обработки большого числа подключений
Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):
Устанавливаем диапазон исходящих портов (1025; 65535)
Выполнить: netsh int ipv4 set dynamic port tcp start=1025 num=64510
Выполнить: netsh int ipv4 set dynamic port udp start=1025 num=64510
(4) Все эти настройки сделаны, это все как раз гуглится по ошибке "Обычно разрешается одно использование адреса сокета (протокол/сетевой адрес/порт)". Но легче не стало вообще. Да и 80 пользователей не так много.
Проблема в том, что тонкий клиент почему-то занимает 1560-1591 порты на рдп сервере (не на 1С сервере) и из-за этого не могут подключаться новые клиенты. Так как если через netstat выбрать клиента, который занял 1560 порт, завершить его, то другой пользователь сможет зайти.
Полагаю, некоторые коллеги уже оказывались в ситуации, когда отладка внезапно пропадала, и различные "шаманские" методики (переустановка платформы, чистка локального кэша и прочее) результата не давали. Опишу свой опыт по выявлению и устранению причины.
Преамбула
Данная статья содержит основные моменты из моей публикации. Рассчитываю, что эта информация поможет оказавшимся в подобной ситуации решить проблему. Или хотя бы послужит примером диагностики в конкретной ситуации.
Начальное состояние
Периодические отваливается отладка. Основные подозреваемые - брандмауэр и антивирус выключены.
Анализ
Текущий порт отлачика tcp://srv1c:1562.
netstat -naot 1 | find "1562" при запуске сеанса отладки показывает наличие состояний SYN_SENT.
Настроен полный технологический журнал, поскольку заранее неизвестны события, содержащие необходимую информацию. Для сбора данных по клиентским сеансам моего пользователя файл настроек расположен в %UserProfile%\AppData\Local\1C\1cv8\conf
Значимые события технологического журнала клиента, собранного с момента запуска сеанса отладки до момента прекращения появления состояний SYN_SENT:
При соединение по TCP/IP открывается сокет и выбирается динамический порт. По умолчанию, диапазон динамических портов от 1024 по 5000. Увеличиваем до максимума.
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: MaxUserPort
Data Type: REG_DWORD
Range: 5000 to 65534
Default value: 5000
Recommended value: 65534
Когда соединение TCP закрывается, то сокет сразу не освобождается, а переходит в статус TIME_WAIT и ресурсы освободятся только через определённое время. По умолчанию, только через 4 минуты. Снизим это время до минимума - 30 секунд.
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: TcpTimedWaitDelay
Data Type: REG_DWORD
Range: 30 to 300
Default value: 240
Recommended value: 30
Отключение автотюнинга tcp протокола:
netsh int tcp set global autotuninglevel=disabled
Результат
Мониторинг сервера в течении нескольких дней показал, что после проведенных изменений даже при большом количестве сессий 1С отладка перестала отваливаться.
Специальные предложения
Я так понимаю, что это рекомендации к клиент-серверной версии, а что делать при такой же беде с файловой базой?
Однажды, пропала отладка для всех имеющихся баз на локальном пк, чистка кэша, отключение антивируса, брендмауэра не помогла. Впоследствии отладка сама включилась через несколько дней, из значимых событий на пк в эти дни было только обновление Skype.
Единственное, что смущает - попадание в зарезервированный диапазон динамических (эфемерных ) портов 49152 - 65535.
Может лучше сначала Range: 5000 to 49000 ?
(8) я нашел следующие разъяснения насчет диапазонов портов:
1. Номер порта выделяется для каждой сетевой службы, чтоб они работали независимо;
2. Порт назначается временно и только на время соединения. После завершения сеанса соединения порт снова становится свободен для использования, хотя в большинстве реализаций просто происходит увеличение на единицу номера последнего использованного порта вплоть до исчерпания всего диапазона эфемерных портов.
3. Номер порта - это абстракция, относящаяся к транспортному уровню (TCP & UDP), более низкие уровни (IP, ICMP, IGMP) - не имеют такой абстракции;
4. "Размещаются" порты в стеке TCP/IP, т.е. в реализованной в составе ОС части, т.е. программисту это не важно;
5. Порты для UDP & TCP - совершенно разные пространства, т.е. 21 порт UDP и 21 порт TCP - это 2 совершенно разные сущности.
6. Наконец, порты TCP/UDP подразделяются на "хорошо известные порты" (номера 0 - 1023), "динамические" (из диапазона 1024 - 49151), и "эфемерные" (49152 - 65535). Хорошо известные порты приписаны стандартным службам: telnet, ftp etc. и использоваться не должны (для других целей). Динамические порты - должны регистрироваться в международном комитете для использования новыми службами широкого применения. Эфемерные порты - это порты "оставленные" разработчикам для использования в своих частных задачах (где попало. ). Никаких гарантий об неконфликтности эфемерных портов в условиях эксплуатации, естественно, не даётся.
В этом контексте использование "эфемерного" диапазона не должно привести к каким то проблемам.
Можно более подробно разобрать, что вас смущает. Полагаю, полезно будет для всех.
Странно, у меня по умолчанию такие параметры установлены (только в шестнадцатиричной системе исчисления). Win 7 x64.
Может, стоит уточнить для каких ОС этот рецепт предназначен.
(10) по умолчанию этих параметров в соответствующих разделах реестра нет. В вашем случае, когда добавляли эти параметры, перед вводом значений не переключили предварительно систему исчисления в десятичную. При создании в форме ввода значения параметра по умолчанию установлена шестнадцатиричная, что объясняет ваши значения.
Применил параметры реестра, всё равно отладка не работает. Отлаживаю вебсервис (на клиенте и сервере отладка работает). На локальном компьютере iis и конфигуратор, на сервере сервер 1с и sql. Фаерволы, антивирусы отключены. В публикации прописал адрес отладки (в разных вариациях пробовал) из настроек отладки. Автоматическое подключение вебсервисов стоит. В тех журнале на клиенте такое (см скрин). Делал netsh winsock reset - не помогло. Есть какие-то мысли?
P.S. Отладка вчера работала, а сегодня отвалилась. Перезагружал и сервер и свою машину по нескольку раз, ничего не помогает.
(13) Да, я делал так, как было в инструкции, но это всё равно не помогло. В итоге, после n-ной попытки переопубликации вебсервиса и перезапуска его, отладка удивительным образом заработала. Шайтан.
Текущий порт отлачика tcp://srv1c:1562.
Как поменять текущий порт отладчика ?
(15) как минимум он устанавливается автоматически отладчиком. Иначе только менять диапазон в настройках "Конфигуратор" - "Отладка" - "Подключение". В открывшейся форме "Параметры отладки" кнопка снизу слева "Настройка" - регулировка диапазона используемых для отладки портов. Но какой порт платформа займет в каждом отдельном случае - ее усмотрение, будет занимать по порядку не занятые.
Сколько же я мучался.. и на всех последних платформах.
Решение принял другое - переход на отладку по http протоколу. Ничего не "отваливается".
Жаль, что раньше эту статью не увидел.
В сегодняшней статье я расскажу об уязвимостях сервера 1С в корпоративной сети.
Как показала практика, в инсталляциях с 1С все допускают одни и те же ошибки разной степени серьезности. Я не буду касаться очевидных вещей вроде установки обновлений, но пройдусь по специфике работы сервера приложений под Windows. Например, по возможности бесконтрольно манипулировать базами Microsoft SQL с помощью инструментов 1С.
Исторически так сложилось, что редко когда системные администраторы и программисты 1С работают как одна команда. Чаще всего специалисты по 1С не вникают в тонкости системного администрирования, а сисадмины не стремятся постичь нюансы работы 1С.
И получается инфраструктура с «детскими болячками», очевидными для специалиста по ИБ ― ниже привожу личный ТОП таких проблем.
По умолчанию платформа 1С при установке создает специальную учетную запись с ограниченными правами, под которой работают службы сервера ― USR1CV8. Все идет хорошо, до тех пор пока не становятся нужны ресурсы сети: например, для автоматических выгрузок-загрузок. Учетная запись по умолчанию не имеет доступа на сетевые папки домена, поскольку является локальной.
В своей практике я встречал множество способов решения этой задачи: папки с доступом на запись для группы «Все», сервер 1С под учетной записью с правами администратора домена, явно прописанные в коде учетные данные для подключения сетевого ресурса. Даже запуск сервера 1С под пользовательской сессией как обычное приложение.
Заходим на сервер по RDP, видим такое окно и получаем нервный тик.
Конечно, «захардкоженые» пароли и сетевые ресурсы с анонимным доступом на запись встречаются редко. В отличие от работы сервера 1С из-под обычной доменной учетной записи. Разумеется, с возможностью выполнить произвольный код «на сервере».
Как известно любому 1С-нику, но не любому системному администратору, в обработках 1С есть два режима выполнения процедур: на сервере и на клиенте. Запущенная в «серверном» режиме процедура будет выполнена под учетной записью службы сервера приложений. Со всеми ее правами.
Если сервер 1С работает с правами администратора домена, то потенциальный вредитель сможет сделать с доменом что угодно. Разумным выходом станет создание специальной учетной записи ― по мотивам USR1CV8, только уже в домене. В частности, ей стоит разрешить вход только на определенные серверы в оснастке «Пользователи и Компьютеры Active Directory».
Настройка входа только на разрешенные серверы.
Не лишним будет и разрешить вход на сервер только в качестве службы, отключив возможность локального (интерактивного) входа в систему. Сделать это можно через локальные политики безопасности непосредственно на сервере, либо с помощью доменных групповых политик.
Назначение прав пользователя в локальной политике безопасности.
Все то же самое касается и учетной записи сервера Microsoft SQL. Седых волос может прибавиться от вредных привычек:
- запускать SQL с правами администратора компьютера или даже домена для удобного резервного копирования;
- включать возможность запуска исполняемых команд через хранимую процедуру xp_cmdshell для переноса резервных копий на сетевые ресурсы через красивые планы обслуживания.
Регулярно в практике встречается подключение баз данных к серверу 1С под пользователем «SA» (суперпользователь в SQL). Вообще, это не так страшно как звучит, ведь пароль от SA захэширован в файле 1CV8Reg.lst на сервере приложений. Хэш злоумышленник получить гипотетически может ― не забываем про права учетной записи сервера ― но расшифровка окажется долгой, особенно если использовать брутфорс.
Но все же не лишним будет настроить аудит доступа к этому файлу с уведомлением ответственных лиц.
Другое дело, когда программистам 1С «делегируют» обязанности DBA. Опять же, из личного опыта: сервер SQL был в зоне ответственности программистов, как и интеграция внешнего сайта с базами 1С. Итогом был пароль SA в скриптах сайта.
Для собственного успокоения стоит поставить на SA сложный пароль или вовсе деактивировать эту учетную запись. На SQL тогда нужно включить доменную аутентификацию для управления и создать для 1С отдельное имя входа с правами на необходимые базы.
Если вы не хотите оставить возможность создавать базы SQL через интерфейс 1С, то новому пользователю хватит общей роли public и db_owner непосредственно в базе 1С.
Это можно проделать через Management Studio или простым скриптом T-SQL:
Правам пользователей в 1С почему-то мало кто уделяет внимание. А ведь пользователь с правами «Административные функции» или «Администрирование» запросто выгрузит базу в .DT через конфигуратор и унесет домой ― это подарит не одно мгновение волнительного счастья вашему руководству. Поэтому стоит поймать на рюмочку чая 1С-ника и посидеть совместно над базой, чтобы узнать, какие пользователи имеют подобные права. А заодно ― чем грозит понижение их полномочий.
Право выгрузить базу у роли Полные Права в типовой 1С: Бухгалтерии 2.0.
Следующий важный момент ― запуск внешних обработок. Как мы помним, в 1С можно запускать код с правами учетной записи сервера. Хорошо, если она не имеет административных прав на систему, но все равно стоит исключить возможность запуска подобных обработок для пользователей. И не забудьте попросить специалиста по 1С «встраивать» дополнительные отчеты и обработки в базу. Хотя не во всех обработках поддерживается встраивание ― эта возможность зависит от версии 1С.
Проверить, какие типовые роли не имеют прав на открытие внешних обработок, можно в конфигураторе.
Все эти действия не только помогут защититься от потенциального «внутреннего вредителя», но и станут дополнительной преградой на пути вирусов-шифровальщиков, маскирующихся под обработки 1С.
Если все же необходим запуск внешних обработок, то неплохим вариантом контроля и подстраховки будет аудит их запуска. Штатного механизма аудита у 1С пока нет, но в сообществе уже придумали несколько обходных маневров. Внедрять эти механизмы стоит в паре со специалистом 1С, также как и настраивать уведомления о событиях в журнале регистраций базы.
Отдельно отмечу возможность настройки доменной аутентификации пользователей вместо аутентификации 1С. И пользователям будет удобнее ― меньше паролей в их памяти снижает риск появления стикеров на мониторе.
Итак, пользователи теперь не могут запускать обработки, учетная запись сервера максимально ограничена. Но есть и еще кое-что: учетная запись администратора кластера 1С, которая не создается по умолчанию.
Ее отсутствие опасно: любой человек с ноутбуком при открытом доступе к сетевым портам сервера (по умолчанию это TCP:1540) может создать там свою базу, и ограничений на запуск обработок не будет. А еще злодей сможет получить информацию по базам данных, по работающим пользователям, изменить параметры кластера и даже принудительно завершить работу определенных пользователей.
Пример скрипта на PowerShell, изгоняющего всех пользователей изо всех баз сервера:
Использование подобного способа работы с сервером 1С в благих целях уже упоминалось в одной из предыдущих статей.
Создать администратора кластера не просто, а очень просто ― достаточно щелкнуть правой кнопкой на пункте «администраторы» в управлении кластером 1С, создать нового администратора, задав логин и пароль.
Создание администратора кластера 1С.
Я коснулся лишь части недоработок при настройке 1С: Предприятия. Для самостоятельного изучения рекомендую почитать до сих пор не потерявшие актуальность материалы:
Поделитесь в комментариях своими нестандартными решениями и курьезами при работе с системой 1С: Предприятие.
21 апреля пользователи Сети начали сообщать о проблемах с работой всех сервисов 1С. Недоступны обновления, невозможно зайти в личный кабинет и на сервис ИТС, не работает ЭДО и 1С:отчётность. 25 числа необходимо подавать отчёт в налоговую, но его невозможно подготовить из-за сбоя.
В официальном Telegram-канале 1C:Франчайзи появилась информация, что доступ к сервисам пропал из-за DDoS-атаки на ресурсы 1С и часть сайтов компании.
По неподтверждённой информации, кроме 1C DDoS-атаке подверглись РАР и ФСС.
Информационная служба Хабра направила 1С запрос с просьбой дать официальный комментарий по ситуации. Как указали в компании:
«С 21 апреля происходят DDoS-атаки на различные сервисы для учёта и отчётности в организациях, в том числе на ресурсы 1С. Часть наших сайтов и сервисов была временно недоступна или работали медленно и неустойчиво. На данный момент восстановлено нормальное функционирование большинства интернет-ресурсов и сервисов 1С, включая 1С:ЭДО и 1С-Отчетность. DDoS-атаки продолжаются, технические специалисты 1С отслеживают ситуацию и принимают усилия для обеспечения нормального функционирования интернет-ресурсов и сервисов 1С. Угрозы для данных пользователей не наблюдается, они не пострадали и надёжно защищены».
Несмотря на заявление компании, пользователи Сети продолжают жаловаться на полное прекращение работы 1С. В частности, пользователь Хабра @nat_young рассказал, что со вчерашнего дня в работе сервисов практически ничего не изменилось.
Facebook Если у вас не работает этот способ авторизации, сконвертируйте свой аккаунт по ссылке ВКонтакте Google RAMBLER&Co ID
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
Некоторые даже систему мониторинга для 5000 ПРОБ — пишут на 1С.
Не то что вы, ламеры, с nagios, cacti, zabbix, фу.
Доброго дня.
А есть среди нас спецы по 1С, в частности по настройке сервера приложений?
Столкнулся со странной ошибкой, которая дословно выглядит так:
"Ошибка загрузки сетевой инфраструктуры свободный порт из заданных диапазонов не найден"
Путем небольших исследований удалось вычислить, что проблема возникает при 32 одновременных сеансах 1С с одного терминального сервера.
т.е. 32 человека - работают норм, а 33-й и все последующие - получает вот такую ошибку.
Если пользователь который только-что получил эту ошибку зайдет на другой терминальный сервер - 1С запустится корректно.
Версия 1С: 8.3.7.1805 (последняя)
База - на сервере приложений (в качестве БД - MS SQL).
Параметры запуска сервера приложений - стандартные. Ничего специально не меняли, кроме одного параметра
«Количество ИБ на процесс = 1». (Но в любом случае это изменение было сделано уже после возникновения ошибки и на нее (на ошибку) не повлияло.)
База конечно самописная, на базе УТ, но программеры мамой клянутся, что ничего там такого не ставили, что мол все стандартное.
Это очень похоже на какие-то ограничения типа "принимать не более N сеансов с одного IP", но где порыться в 1С чтобы это увеличить - моя не понимать.
Облазил все настройки - не нахожу чего-то что могло помочь.
Помогите, а.
позязя.
UPD1: сделали тест: запустили на сервере терминалов другую базу много раз - запускается без вопросов. довели до 50 одновременных успешных запусков и пока успокоились.
на основной базе, которая нас интересует, проблема - сохраняется. Похоже что-то в самой базе не так, а не на сервере приложений.
Читайте также: