Ключевая Информация

[rasul]

версия vipnet client 3.0 (6.4059)

как на координаторе,так и и клиентах.

ситуация возникла такая.

в одном из подведомственных организаций необходимо было перенести ПО vipnet.

в общем получилось так, что пришлось создавать новый АП Y.

Затем удалил старый Q в организации , разослал всю необходимую информацию.

// Но вышел вопрос, что все- таки некоторые пользователи VipNet не могли отсылать письма по адресу (вследствие недостаточной внимательности).

Пришлось удалить вновь созданный АП Yв организации (разослав информацию), и создал новый АП с именем Q.

То есть получилось так, что удалив на сервере ап Q - я создал еще раз ап Q с тем же именем.

В принципе ничего особенного произойти не должно во взаимодействии клиентов между собой. (думаю)

Но похоже с тех пор один из аб.пунктов сети отправляет письма на ап Q, они не доходят.До остальных все доходит.

mftp ошибок не дает, ключи вроде в порядке.

простите за сложность выполненных операций, так уж получилось.

обращаюсь к вам, поможите.

[Echo]

То есть получилось так, что удалив на сервере ап Q - я создал еще раз ап Q с тем же именем.

В принципе ничего особенного произойти не должно во взаимодействии клиентов между собой. (думаю)

Смотря что считать особенным - создание нового узла со старым именем не восстанавливает старый узел. Фактически Вы сначала удалили узел Q, затем создали сначала узел Y, а за ним узел Qнов, так что ключи и справочники с идентификаторами узла Q не равны ключам и справочникам узла Qнов. Поможет только формирование и отправка новых КН и новых справочников на все связанные узлы. Также проверьте связи по ТК - все ли сделаны, затем обязательно ножмите Сформировать все справочники в ЦУС, независимо от результата заново запросите в УКЦ справочники для УКЦ-Справочники сетевых узлов и сделайте в УКЦ новые КН (не обновления ключей, а новые КН). И разошлите. В крайнем случае, попробуйте сделать ДСТ и проинициализировать на узлах. Это гарантированно обновит ключи (при правильной первичной инициализации).

[rasul]

Поможет только формирование и отправка новых КН и новых справочников на все связанные узлы. Также проверьте связи по ТК - все ли сделаны, затем обязательно ножмите Сформировать все справочники в ЦУС, независимо от результата заново запросите в УКЦ справочники для УКЦ-Справочники сетевых узлов и сделайте в УКЦ новые КН (не обновления ключей, а новые КН). И разошлите.

Да, это всё я проделал.ведь если бы этого я не сделал, то остальные узлы этой сети (а также другие - межсетевое)не смогли бы взаимодействовать между собой.

А вот по этому поводу

В крайнем случае, попробуйте сделать ДСТ и проинициализировать на узлах. Это гарантированно обновит ключи (при правильной первичной инициализации).

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

[Echo]

Да, это всё я проделал.ведь если бы этого я не сделал, то остальные узлы этой сети (а также другие - межсетевое)не смогли бы взаимодействовать между собой.

А вот по этому поводу

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

Связь остальных узлов тут ни при чем - при создании или удалении узла появляется или удаляется только ключ связи с этим узлом, остальные ключи не трогаются.

Если проблема после первичной инициализации ДСТ файлов и на новом узле и на связанном с ним старом узле осталась - пишите или звоните в техподдержку, возможно, у Вас есть проблемы с изменением файлов на диске. В общем, надо проверять.

В теории, повторюсь, удаление узла и создание узла с тем же именем - это создание нового узла, а не восстановление старого удаленного.

[rasul]

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

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

таким образом выходит проблема, что на некоторых ап меняется ключевая инфа на некотор.период назад и тем самым происходит неизвестные проблемы.

Сегодня возникла ситуация на одном из АП. К нему приходит письмо и выходит ошибка "Целостность данного сертификата не подтверждена и т.п."

Теперь приходится по одному выявлять и решать проблемы - как полностью создавать дистрибутив.(надеюсь, поможет)

Уже и не знаю, что может случиться.

[Echo]

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

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

таким образом выходит проблема, что на некоторых ап меняется ключевая инфа на некотор.период назад и тем самым происходит неизвестные проблемы.

Сегодня возникла ситуация на одном из АП. К нему приходит письмо и выходит ошибка "Целостность данного сертификата не подтверждена и т.п."

Теперь приходится по одному выявлять и решать проблемы - как полностью создавать дистрибутив.(надеюсь, поможет)

Уже и не знаю, что может случиться.

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

Оно, по идее, должно аннулировать все остальные обновления, которые были сформированы раньше.

Версию Вашу проверить несложно - смотрите в ЦУС - Управление-Запросы и ответы, скажем месяца за 3 или по проблемным узлам. Там видно, кто когда обновился и что именно высылалось, и совпало ли это с началом проблем.

Как крайний вариант заготовить новые ДСТ или полные КД и подкладывать их на проблемные узлы.

Как раз тема для техподдержки. Боюсь в "неформальной" переписке на форуме подробного разбора не получится.

А страшного по идее случиться не должно - пока действует связь и Вы не забыли пароль Администратора УКЦ все можно восстановить...