74 ответов в этой теме

[Gennadys]

После обновления до v.11 агенты на станциях с Windows XP периодически получают "отказ в соединении с сервером".

Получают в совершенно произвольный момент, в dwservice.log в этот момент пишется "invalid server signature".

 

Если такую станцию перезагрузить, в большинстве случаев они без каких-либо проблем опять подключаются к серверу.

Хотя, изредка, подключаются после 2-3 перезагрузки или приходится переустанавливать агента.

 

Лечится ли это как-нибудь ? И если да, то как ?

 

Логи с одной из проблемных станций прилагаю.

Прикрепленные файлы:

•  Logs.zip   1,3Мб   1 Скачано раз

[Yury Vovk]

Могли бы вы включить дебажный лог агента на одной из проблемных станций? В предоставленном вами не достаточно информации для того что бы понять что происходит.

А так же скажите, у вас в сети один ES сервере или возможно настроен кластер серверов? Опишите немного то как организована ваша антивирусная сеть.

[Gennadys]

Сервер, на данный момент - один, версии 10 от 11.08.16, на ubuntu 14.04.5 x64 в виртуалке vmware vsphere 6.

До недавнего времени был второй, версии 6.

Но агенты на проблемных станциях переустановлены (drw_remover + установка по сети) после того как старый сервер погашен.

Кластеров нет.

Агенты в локалке, в домене, маршрутизаторов между ними и сервером нет.

 

Установил уровень лога агента "Все", но пока ни одна станция не отвалилась и в логах ничего подозрительного не вижу.

Как поймаю проблему - приложу логи.

[Denis V. Kuznetsov]

Хотелось бы присоединиться к теме, испытываю подобные же проблемы: именно Windows XP, почему-то по одной только за раз, т.е. получаю уведомления "Авторизация станции a821431a-af8e-45da-8740-6fcc867a044d (tcp://192.168.1.123:1884) не выполнена, поскольку станция предоставила неправильные параметры авторизации. Доступ отвергнут." с одной лишь станции в одно время. Три таких станции переустановили, и  с ними больше проблем нет, но на следующее утро появляется новая. Конфигурация сети подобная, разве что 6го сервера нет уже довольно давно. Клиентов на XP немного, но разобраться неплохо бы. Включить дебажный лог не получится думаю на станции ибо статус ее оффлайн.

[Gennadys]

Прилагаю логи с уровнем лога агента "Все".

Примерно в 11:15 15.09.2016, после перезагрузки, агент "подхватился".

В dwservice.log до указанного timestamp'а - "invalid server signature", после - все хорошо.

Прикрепленные файлы:

•  Logs.zip   1,97Мб   5 Скачано раз

Сообщение было изменено Gennadys: 15 Сентябрь 2016 - 11:49

[Denis V. Kuznetsov]

прицепил со своей станции лог, сегодня кстати новая уже станция отвалилась (вчерашняя просто выключена, видимо человек не работает)  Logs.zip   960,45К   2 Скачано раз

Сообщение было изменено Denis V. Kuznetsov: 16 Сентябрь 2016 - 14:20

[Yury Vovk]

Спасибо, пытаемся понять в чём может быть дело.

 

Gennadys, а у вас на станции, с которой предоставлен лог, что то странное со временем происходит:

 

line #159966 2016-Sep-15 11:15:01.579839 [348] [INF] [reconnector] 20160915.111501.57 tr3 [01716 015c] noname [Layer/TextProto] tcp://192.168.79.252:2193: rcv <1 SIGNATURE e23b1790 3f9fe1b5 baa39dec 32013531 bd6e6a9d db76e9c3 0b71682b 885372ca ac0f2be7 01e88a1e 4d07703d d5b2623e 7f5555fc 3e0b2b18 29cdf495 cd693854 d65e7432 59d909bb badcdcbd bc23e501 9a73c70c 677bb88e 5ca71b85 54a5d2d0>

 

line #164247 2016-Sep-15 11:14:45.090604 [1668] [INF] [reconnector] 20160915.111445.09 tr3 [01720 0684] noname [Layer/TextProto] tcp://192.168.79.252:2193: rcv <1 SIGNATURE 96abf2bf 8db1c2ad b5d9669d 30e39511 be98770e 5093720f 9f9aecda 13f9fef6 7b5adc96 e9bb578e ebe9c22a 84c77400 5ebec25a ceac727f 5fc1515c 26ef29b7 1e7e2ee6 ffe55793 8b556ec8 eabfd847 3ac4cd4c 4d2c7edf c15b3fb5 b497465f>

 

line #160236 2016-Sep-15 11:15:25.499818 [276] [INF] [main] Set delayed status.

line #160237 2016-Sep-15 11:13:21.593750 [1732] [LOG] Starting service...

 

по какой то причине станция путешествует назад во времени на пару минут.

 

Маловероятно, что это может быть причиной проблемы, но поведение само по себе не нормальное...

[Kirill Polubelov]

Если в ВМ -- то без синхронизации с хостовой системой, время в гостевой имеет свойство убегать вперёд.

Известно, что при этом происходит аварийный разрыв связи.

[Afalin]

Известно, что при этом происходит аварийный разрыв связи.

На данный момент это касается только сервера, работающего в ВМ.

[Gennadys]

Прыжки во времени были из-за сбоя синхронизация времени.

И сервер DrWeb, и домен синхронизируются из единого источника, который подвис. Агенты синхронизируются с доменом.

После исправления временной синхронизации проблема на агентах осталась.

[Gennadys]

Еще один момент: выставил проблемным станциям права  "Изменение режима работы" и "Изменение конфигурации Агента Dr.Web".

Если у станции "отказ в соединении с сервером", то при выборе в настройках

"Основные" - "Режим" - "Подключение к серверу централизованной защиты" - "Изменить" - "Способ подключения" - "Подключиться как новичок" - "OK" - "OK"

сброс станции в новички не происходит.

Во вложении логи (к попыткам подключиться как новичок относятся последние 10-20 минут).

 

 

 

[Gennadys]

Логи к предыдущему посту во вложении

Прикрепленные файлы:

•  Logs.zip   7,16Мб   1 Скачано раз

[Gennadys]

Есть какие-нибудь новости по поводу данной проблемы ?

Может быть есть какие-то пути если не решения, то обхода проблемы ?

Около десятка компов (всегда разных) сидит без защиты до нескольких дней - если не перегружать их до победного или не переустанавливать агента через ремувер.

Организация бюджетная, около 40 компов на Win XP и обновить их легальной возможности нет.

[Yury Vovk]

сброс станции в новички не происходит.

Он и не произойдет, так как агент пытается не корректно валидировать подпись сервера, попробуйте выставить галку "Разрешить использовать публичный ключ, не соответствующий серверу"  или экспортировать публичный ключ сервера и и указать непосредственно его. 

Есть какие-нибудь новости по поводу данной проблемы ?

Объективно не видно ни какой причины, почему так происходит, кроме предположения что по какой либо причине значение публичного ключа в реестре у вас различно от перезагрузки к перезагрузки.

 

Проверьте значение HKEY_LOCAL_MACHINE\SOFTWARE\Doctor Web\Settings\Es\ServerPubKey в реестре, и сравните его значение с публичным ключом у вас на сервере (ключ желательно получить через экспорт в ЦУ)

 

Так же я бы порекомендовал вам в дополнение завести запрос в тех поддержку (номер тикета скиньте мне в личку) и приложить туда сисинфо с двух проблемных станций

[Denis V. Kuznetsov]

Проверьте значение HKEY_LOCAL_MACHINE\SOFTWARE\Doctor Web\Settings\Es\ServerPubKey в реестре,

сравнил с ключом на другой станции, они одинаковы

 

причем станция с уже трижды переустановленным DrWeb'ом, вновь впадает в это состояние, похоже придется и правда тикет создавать...

 

так как агент пытается не корректно валидировать подпись сервера

по-моему все же сервер не валидирует станцию, а не наоборот

[Afalin]

по-моему все же сервер не валидирует станцию, а не наоборот

Если видите в логе "invalid server signature", то именно сервер не аутентифицирован станцией.

[Kirill Polubelov]

Кстати, так, в порядке версии, без сисинфо и пр.,

 

 

До недавнего времени был второй, версии 6.

 

Он остался и не потушен?

 

А в настройках агентов этих не несколько ли серверов указано?

[Kirill Polubelov]

А вижу, вижу, что по крайней мере, на одной из станций, ищется сервер мультикастом, но подключается всегда по одному и тому же IP.

[Denis V. Kuznetsov]

Если видите в логе "invalid server signature", то именно сервер не аутентифицирован станцией.

я вижу уведомления в почте от сервера "Авторизация станции a821431a-af8e-45da-8740-6fcc867a044d (tcp://192.168.1.123:1327) не выполнена, поскольку станция предоставила неправильные параметры авторизации. Доступ отвергнут.", что в купе с одинаковыми ключами на нормально работающих и не нормально работающих станциях, наводит меня на другие мысли

[Kirill Polubelov]

Прежде чем идти в СТП с сисинфо, если не затруднит, покажите, пожалуйста:

 

1. Раздел (из веб-фейса управления):

АВ-сеть -> проблемная станция -> Агент Dr.Web -> Сеть.

Интересует кол-во заданных там открытых ключей.

 

2. На проблемной станции непосредственно -- раздел режим