14 ответов в этой теме

[dr_user]

Добрый день!

Dr.Web Enterprise Suite Server - версия файла 11.0.0.10030

Dr.Web Enterprise Suite - версия продукта 11.00.0.201810030

 

После перезапуска сервера onlin-связь с Главным сервером необратимо переходит в offline.

Связь в online восстанавливается только после пересоздания: связь удалить/создать - через 30 сек online.

Без перезапуска связь держится. Серверный протокол включен.

----

Возможно это имеет отношение к вопросу:

- из логов сервера:

[Proto/Common]   tcp://<ip-главного>:2193: ping disabled

[Proto/Common]   tcp://<ip-главного>:2193: requested for disconnect

[Transformation]   tcp://<ip-главного>:2193/dead: all filter removed from incoming and outcoming streams

[Transformation]   tcp://<ip-главного>:2193/dead: dead 1091/351 (100% 1091/351) (alive for 01.169)

[Proto/Common]   tcp://<ip-главного>:2193: generated new name, became tcp://<ip-главного>:2193/disconnected

- при этом с нашего сервера: ping <ip-главного> = ок, telnet <ip-главного> 2193 = ок, tcping <ip-главного> 2193 = ок

----

Подскажите пожалуйста, что делать? - проблема достала, перезапускается и наш и Главный, каждый раз пересоздаем связь...

Держатели Главного сервера отвечают "так это ж DrWeb, так и будет ..."

Спасибо.

[Afalin]

Подскажите пожалуйста, что делать?

Поделиться логами сервера с verbosity=all с попавшим в них воспроизведением проблемы.

[dr_user]

Связь-оффлайн: уровень детализации = все, связь удалена, сервер остановлен, лог удален,

 - 19:22:42 сервер запущен,

 - 19:23:30 создана связь с Главным "постоянно подключен", +30 сек - связь-онлайн, лицензия получена

 - 19:24:25 сервер перезапущен, связь-оффлайн, 5 мин ждем - дольше смысла нет, все равно не восстановится

 - 19:31 сервер остановлен

Лог прикреплен.

-------

То же с "переподключением через ..." - отключается и больше не подключается

-------

Обнаружено, что связь мгновенно восстанавливается, если

в свойствах связи вновь выбрать сертификат главного сервера, по "Сохранить" - сразу в онлайн.

 

Никакие другие изменения связи ее не восстанавливают.

только или удалить/создать или перевыбрать сертификат главного.

 

 

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

•  drwcsd.log   5,7Мб   4 Скачано раз

[Afalin]

Ваше замечание про сертификат очень кстати.

После установления связи сервера обмениваются актуальными сертификатами, так вот главный отдаёт какой-то другой сертификат, возможно, даже от другого закрытого ключа. Причём даже если в настройках связи отсутствует актуальный сертификат, на старте сервер всё равно должен туда добавлять его,

 

Так что вопросы к держателям главного:

1. Вот этот сертификат, с которым создаётся связь на подчинённом, и etc/drwcsd-certificate.pem на главном – это один и тот же файл с точностью до байта, верно?

2. На какой СУБД работает главный сервер? Я посмотрел, правда на 11.0.2 – актуальный сертификат в настройки связи добавляется, если его там нет. На главном похоже это не происходит. Кстати, хотелось бы в связи с этим взглянуть на детальный лог главного сервера на момент его запуска.

3. Не пропадёт ли обсуждаемая проблема, если вручную в настройках этой связи на главном добавить его же сертификат в "Собственные сертификаты Сервера", после чего пересоздать связь на подчинённом или заново подкинуть сертификат?

 

Собственно,

— правильный сертификат – размером 681 байт (или около того) и с телом, начинающимся с "MIIByTCCAXa",

— неправильный – 685 байт и "MIIByzCCAXi" соответственно.

Больше я про правильный ничего не знаю, так что больше подробностей для визуального сравнения не дам.

[dr_user]

Спасибо !!   Передали держателям главного, обещали заняться.

 

п.3 - после пересоздания связи на Главном, связь переходит в онлайн (без действий на подчиненном), но временно.

        Добавляют ли они свой сертификат вручную, или его добавляет сервер - не знаю, когда у них будет время, проверим

п.1 - попытаюсь проверить

[Afalin]

В общем, всё сводится к тому, чтоб понять, откуда берётся на главном сервере неправильный сертификат главного сервера, и как с этим бороться.

 

п.3 - после пересоздания связи на Главном, связь переходит в онлайн (без действий на подчиненном), но временно.

А вот этого кстати не должно быть, если никто не трогает уже упавшую связь на подчинённом. Потому что подчинённый уже потерял к тому моменту правильный сертификат главного.

[dr_user]

В сомнении... извиняюсь, если не так .... 

Сертификат главного на подчиненном мы добавляли руками в свойствах связи выбором файла

Сообщение было изменено dr_user: 03 Октябрь 2019 - 18:58

[Afalin]

Сертификат главного на подчиненном мы добавляли руками в свойствах связи выбором файла

Да, с этим понятно, тот сертификат нормальный.

Тут такая штука. На каждой стороне связи есть по два набора сертификатов:

1) сертификаты соседнего сервера – нужны, чтобы аутентифицировать этот соседний сервер (то есть не допустить работы с подставным сервером);

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

Проблема тут возникает после обмена сертификатами, главный говорит, что у него вот такой-то сертификат, хотя работает он на самом деле с другим сертификатом.

Решиться эта проблема должна сама, почему не решается – надо разобраться. И в качестве workaround – добавить правильный сертификат в собственные сертификаты именно главного, раз он сам этого не делает. Но раз что-то пошло не так, то может быть workaround тоже не взлетит.

 

Да, если workaround внезапно поможет – всё равно хочется выяснить корень проблемы. Не нравится нам "так это ж DrWeb, так и будет ...".

[dr_user]

Супер-фишка - картинки прилагаются:

 

Два файла сертификатов: 50… правильный подчиненного, 60… правильный главного.

Оба начинаются на MIIByTCCAXa.

 

Если в свойствах связи два раза выбрать 2й файл, то в «Сертификатах соседнего» 
видим ДВА РАЗНЫХ сертификата, один из них 60….

 

Так что держателям главного сообщаем конкретный номер кривого сертификата. Теперь уж должны исправить.

Спасибо!!

 

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

•  связь.jpg   25,73К   0 Скачано раз
•  файлы.jpg   11,86К   0 Скачано раз

[Afalin]

Теперь уж должны исправить.

Есть подозрение, что нам тоже надо что-то исправить. Подобная ситуация должна исправляться на каждом старте сервера. Я уж не думаю, что у главного там вечный аптайм, а сертификаты меняются сами по себе в процессе работы.

[Afalin]

Есть новости?

[dr_user]

Все печально. Не особо хотят что-то у себя менять...

 

В связи с этим вопрос - работа с сервером из командной строки: можно ли как-то заменять сертификат головного? 

(аналог через WEB: в свойствах связи выбрать файл, сохранить). 

Не через автокликеры извращаться, а как то штатно?

... раз в сутки менять, так  "с костылем" и работать ...

[Afalin]

Не особо хотят что-то у себя менять...

Делиться информацией о проблеме – тоже? Это да, печально.

Но по возможности попинывайте ответственных. Можете ссылаться на нас.

 

... раз в сутки менять, так  "с костылем" и работать ...

Да ну, можно ж проще. В планировщике заданий сервера создать задание, лучше даже ежечасное, на запуск скрипта такого вида:

local cert = dwcore.str_quote(
[[-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
]])

local db = database.get()
if not db or not db.begin() then return end

local osid = drwcs.license_key().uuid
local now  = dwcore.db_nowstamp()

local ids = db.exec( "SELECT DISTINCT id FROM servers WHERE osid=?", {false}, {osid} )
if not ids then return end

for _,id in pairs(ids) do
  local rez = db.exec( "SELECT COUNT(*) FROM servers WHERE osid=? AND id=? AND name=? AND value=?",
                       { true }, { osid, id[1], 'cert', cert } )

  if rez and rez[1][1] == 0 then
    db.exec( "INSERT INTO servers(osid,id,name,value,updatetime) VALUES(?,?,?,?,?)", nil,
             { osid, id[1], 'cert', cert, now } )
  end
end

db.commit()

Набросал навскидку, мог где-то наврать. Проверьте, пожалуйста.

Тело правильного сертификата подставить между квадратными скобками целиком как есть.

Сообщение было изменено Afalin: 08 Октябрь 2019 - 13:39

[dr_user]

Спаасибо!  Работает!

- при выполнении скрипта через Lua-консоль связь оживает, вешаем на планировщик

 

Да ну, можно ж проще.

... дык не руками ж, думали про шедулер, только внешний

[dr_user]

как то получился дубликат - удален

Сообщение было изменено dr_user: 08 Октябрь 2019 - 19:39