Настройка авторизации соединений сервера 1С Предприятие
При программном подключении к серверу 1С:Предприятия сервер сначала принимает, а затем закрывает соединение: не пройдена авторизация. При этом для авторизации используется логин, который нигде у клиента не указан. Предполагаю, что он где-то в серверных настройках прописан. Вопрос: где он прописан и как его поменять?
Логи сервера (технологический журнал):
> 03:15.484001-0,CONN,0,process=ragent,ClientID=4427,Protected=1,Txt='Accepted, > client=(2)192.168.166.181:50920, server=(2)192.168.3.30:1740' > 03:15.562002-0,CONN,2,process=ragent,t:clientID=4427,Txt=Srvr: > SrcUserName1: nsk5025nk$@MYDOMAIN.LOCAL > 03:15.562003-0,CONN,2,process=ragent,t:clientID=4427,Txt=Srvr: > DstUserName1: 1c-subs@MYDOMAIN.LOCAL(MYDOMAIN.LOCAL\1c-subs) > 03:15.562004-3,CALL,1,process=ragent,t:clientID=4427,Interface=7f58f27d-5ad8-43a1-aa1e-c982f41bed5c,IName=IRemoteCreatorService,Method=0,CallID=-396525813,MName=createRemoteInstance,Memory=17930,MemoryPeak=18416,InBytes=0,OutBytes=0 > 03:15.578001-0,CONN,2,process=ragent,t:clientID=4427,Txt=Srvr: > DstUserName2: MYDOMAIN\1c-subs(MYDOMAIN\1c-subs) > 03:15.578003-0,SCOM,3,process=ragent,t:clientID=4427,Func='setSrcProcessName(##AdminProcess##,##AdminProcess##)' > 03:15.578004-4,CALL,1,process=ragent,t:clientID=4427,Interface=7f58f27d-5ad8-43a1-aa1e-c982f41bed5c,IName=IRemoteCreatorService,Method=0,CallID=-396525744,MName=createRemoteInstance,Memory=845229,MemoryPeak=846384,InBytes=408,OutBytes=0 > 03:15.594001-1,CALL,2,process=ragent,p:processName=##AdminProcess##,t:clientID=4427,t:applicationName=COMConsole,t:computerName=1c-subs,Method=methodsCount,CallID=-396525739 > 03:15.594005-1,SCALL,3,process=ragent,p:processName=##AdminProcess##,t:clientID=4427,t:applicationName=COMConsole,t:computerName=1c-subs,ClientID=4415,Interface=0459eaa0-589f-4a6d-9eed-c1a7461c8e3f,IName=IClusterRegistry,Method=0,CallID=81613048,MName=getRegistryParams > 03:15.594006-3,CALL,2,process=ragent,p:processName=##AdminProcess##,t:clientID=4427,t:applicationName=COMConsole,t:computerName=1c-subs,Interface=73cdaa77-2afc-436c-b738-58c772e3a0bf,IName=IServerClusterAdmin,Method=0,CallID=-396525738,MName=ibRegistries,Memory=13943,MemoryPeak=17823,InBytes=0,OutBytes=0 > 03:15.594010-1,SCALL,3,process=ragent,p:processName=##AdminProcess##,t:clientID=4427,t:applicationName=COMConsole,t:computerName=1c-subs,ClientID=4415,Interface=0459eaa0-589f-4a6d-9eed-c1a7461c8e3f,IName=IClusterRegistry,Method=14,CallID=81613049,MName=ibrAuthenticate > 03:15.594011-3,CALL,2,process=ragent,p:processName=##AdminProcess##,t:clientID=4427,t:applicationName=COMConsole,t:computerName=1c-subs,Interface=73cdaa77-2afc-436c-b738-58c772e3a0bf,IName=IServerClusterAdmin,Method=10,CallID=-396525737,MName=regAuthenticate,RetExcp='Ошибка > операции администрирования Администратор кластера не > аутентифицирован',Memory=-120,MemoryPeak=3936,InBytes=0,OutBytes=0 > 03:15.594014-1,CALL,2,process=ragent,p:processName=##AdminProcess##,t:clientID=4427,t:applicationName=COMConsole,t:computerName=1c-subs,Method=Release,CallID=-396525735 > 03:15.594016-0,EXCP,1,process=ragent,ClientID=4427,Exception=NetDataExchangeException,Descr='server_addr=(2)192.168.166.181:50920 > descr=recv returns zero, disconnected line=2355 > file=src\DataExchangeServerImpl.cpp' > 03:15.594017-0,EXCPCNTX,0,ClientComputerName=,ServerComputerName=,UserName=,ConnectString= > 03:15.594018-3,EXCPCNTX,0,SrcName=MEM,OSThread=8804,process=ragent > 03:15.594019-0,CONN,1,process=ragent,ClientID=4427,Txt=Incomming > connection closed: client disconnected > 03:15.594020-32020,CONN,0,process=ragent,t:clientID=4427,t:clientID=4427,t:computerName=1c-subs,t:applicationName=COMConsole,t:connectID=0,Calls=6 > 03:15.594021-16019,SCOM,2,process=ragent,t:clientID=4427,ProcessName=##AdminProcess##,SrcProcessName=##AdminProcess##
SrcUserName1: nsk5025nk$@MYDOMAIN.LOCAL
— это имя пользователя, под которым запущена служба Агента 1С Предприятия (причем nsk5025nk — это имя компа, на котором она запущена). А вот откуда берутся имена
DstUserName1: 1c-subs@MYDOMAIN.LOCAL(MYDOMAIN.LOCAL\1c-subs) DstUserName2: MYDOMAIN\1c-subs(MYDOMAIN\1c-subs)
мне непонятно. Прошу подсказать, где эти настройки.
Комп (и пользователь), на котором запускается клиент подключения, вообще почти никак не фигурирует в логах. Единственный его след — это адрес и порт в первой строке: client=(2)192.168.166.181:50920
P.S. MYDOMAIN я подставил сюда вместо реального имени домена.
Ошибка что не найден файл DataExchangeServerlmpl.cpp ?
Здравствуйте. В технологическом журнале куча сообщений вида «не удается найти указанный файл line 1901 file = src\DataExchangeServerlmpl.cpp». Ошибки валятся с указанием айпишника веб-сервера. Подскажите пожалуйста кто с подобным сталкивался — что это за файл вообще? Платформа 8.3
Сосновский Виктор (1С, Москва) 02.12.2013 11:58
Отвечает на
1199053
Появление таких записей не является ошибкой и значит отсоединение клиентского приложения от сервера
1С: Предприятия, например, при закрытии клиентского приложения.
От себя добавлю — переживать не стоит, скорее всего частый разрыв соединения. Скорее всего выход в сеть через 4G, 3G, Wifi ломается, может есть сбойных хаб в цепи, сетевая карта. Других проблем с этой ошибкой нет.
Если вопрос еще актуален, то ниже выдержка из руководства администратора 1С:
Последовательность элементов определяет условие, при выполнении которого событие будет помещено в журнал. В журнал помещаются только такие события, которые удовлетворяют условию. Иначе говоря, если условие, определяемое последовательностью элементов , принимает значение Истина, то событие будет записано в журнал. Событие включается в журнал, если оно удовлетворяет всем условиям внутри хотя бы одного из элементов . То есть условия внутри объединяются по И, а элементы объединяются по ИЛИ.
Условия задаются элементами:
Каждый из этих элементов, кроме элемента like, определяет простое сравнение значения параметра события (имя которого задается атрибутом property) со значением атрибута value.
В данном случае в технологическом журнале будут регистрироваться события, относящиеся к группе с именем PROC.
Ссылка на источник:
its.1c.ru
File src dataexchangeserverimpl cpp
Обычно, когда отваливается отладка, первоначальными подозреваемыми становятся брандмауэр или антивирус. Соответственно, самый простой способ проверить их влияние на возникшую проблему — отключить их и запустить отладочный сеанс. Но в некоторых случаях проблема может скрываться совершенно в другом месте. Общая рекомендация — не начинать бездумно применять все подряд «шаманские» способы из интернета, а в необходимом объеме собрать техническую информацию о возникающих событиях и ошибках, сопровождающих запуск отладки на исследуемой машине.
Теперь расскажу, как проходило расследование ситуации и последующая настройка сервера в моем случае. Для начала необходимо определить используемый на данный момент порт отладки. Это можно посмотреть в конфигураторе через меню «Отладка» — «Подключение» — «Настройка». В моем случае это было tcp://srv1c:1562.
Выполнение netstat -nao | find «1562» показало, что к порту отладки имеют отношение только мои процессы конфигуратора и клиента, запущенного на отладку. Запуск периодического опроса портов netstat -naot 1 | find «1562» с последующим запуском отладки выявил наличие состояний SYN_SENT, что означает, что клиент все таки пытается достучаться порта отладки.
После этого решил посмотреть, какие события пишет клиент во время запуска в технологический журнал. Поскольку мне неизвестно, какое событие будет содержать необходимую информацию, то я буду собирать все события с момента старта отладки до момента, пока SYS_SENT не прекратятся.
xmlns="http://v8.1c.ru/v8/tech-log"> location="C:\v8\client\logs" history="1"> > property="name" value=""/> > name="all"> > > >
Файл настроек журнала кладется в %UserProfile%\AppData\Local\1C\1cv8\conf, потому что мне нужны события только моих сеансов. После этого снова запускаем клиент на отладку и изучаем логи. В логе конфигуратора ничего интересного не оказалось. Из лога клиента целиком полученные данные приводить смысла нет, покажу только значимые события, связанные с сетевой активностью.
30 : 25.862000 — 0 ,EXCP, 1 ,process = 1cv8,ClientID = 0 ,Exception = NetDataExchangeException,Descr = ‘server_addr=any:1560 descr=10048(0x00002740): Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). line=261 file=src\DataExchangeServerImpl.cpp’
30 : 25.862003 — 0 ,EXCP, 1 ,process = 1cv8,ClientID = 0 ,Exception = NetDataExchangeException,Descr = ‘server_addr=any:1561 descr=10048(0x00002740): Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). line=261 file=src\DataExchangeServerImpl.cpp’
30 : 25.862006 — 0 ,EXCP, 1 ,process = 1cv8,ClientID = 0 ,Exception = NetDataExchangeException,Descr = ‘server_addr=any:1562 descr=10048(0x00002740): Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). line=261 file=src\DataExchangeServerImpl.cpp’
30 : 30.199000 — 0 ,EXCP, 3 ,process = 1cv8,Usr = Админ,ClientID = 3 ,Exception = NetDataExchangeException,Descr = ‘server_addr=tcp://127.0.0.1:1562 descr=127.0.0.1:1562:10060(0x0000274C): Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера. ;
line=1043 file=src\DataExchangeTcpClientImpl.cpp’
30 : 34.208000 — 0 ,EXCP, 3 ,process = 1cv8,Usr = Админ,ClientID = 4 ,Exception = NetDataExchangeException,Descr = ‘server_addr=tcp://127.0.0.1:1562 descr=127.0.0.1:1562:10060(0x0000274C): Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера. ;
line=1043 file=src\DataExchangeTcpClientImpl.cpp’
Коды ошибок сокетов можно посмотреть на MSDN. В моем случае ошибка 10048(0x00002740) является причиной, 10060(0x0000274C) — следствие. Проблема оказалась знакомой — неделю назад настраивал другой сервер, на котором периодически отваливались клиенты с такой же ошибкой.
Приступаем к настройке TCP протокола с помощью редактирования реестра (regedit), отсутствующие параметры в ветках необходимо создать руками:
При соединение по 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
Выполненный ping srv1c показал использование протокола tcp/ipv6. Если в нем явной необходимости нет, то рекомендуется его отключить. Одного отключения протокола в свойствах подключения недостаточно, нужно еще отключить компоненты.
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Value: DisabledComponents
Data Type: REG_DWORD
Value: 0xff
На некоторых сайтах можно встретить рекомендацию установить значение 0xfffffff. Данное
значение, согласно вышеуказанной статье от Microsoft, является некорректным и может привести к задержкам при загрузке системы (Additionally, system startup will be delayed for 5 seconds if IPv6 is disabled by incorrectly, setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value should be 0xff).
Перезагружаем сервер. Мониторинг сервера в течении нескольких дней показал, что после проведенных изменений даже при большом количестве сессий 1С отладка перестала отваливаться.