Проблемма При Подключении Нового Клиента К Сети

[rupas]

проблема следующая. есть работающая сеть Vipnet

добавляю новый сетевой узел.

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

в списке сетевых узлов координатора узел появился.

однако при попытке связи координатор сообщает что не найден ключ для сетевого узла.

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

в чём может быть причина заранее спасибо

[Stratos]

rupas

Значит не прошло обновление ключей на координаторе.

[rupas]

обновление ключей посылал несколько раз и вроде согласно логов всё принято и установлено

[Stratos]

rupas

Какие версии ПО? Вплоть до сборок.

[aknis]

обновление ключей посылал несколько раз и вроде согласно логов всё принято и установлено

в транспортном каталоге в подкаталоге "ccc" и "ccc\key" файлики случаем не лежат? И в каком логе вы смотрели успешное обновление КН?

[rupas]

проблема решена. обновления пришли но не применились. и файлики в ccc\key действительно лежали. помогла ручная перезагрузка монитора в одном случае и машины в целом в другом случае.

[aknis]

проблема решена. обновления пришли но не применились. и файлики в ccc\key действительно лежали. помогла ручная перезагрузка монитора в одном случае и машины в целом в другом случае.

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

[MORO]

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

+1

[Echo]

+1

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

Для разбора этой ситуации как минимум потребуется:

лог ЦУС и знание системного времени ЦУС по отношению к Гринвичу

лог MFTP Администратора

лог MFTP Клиента и знание системного времени Клиента по отношению к Гринвичу

логи с Клиента (в том числе и monitor.log), тем более, что пришлось перезагрузить компьютер

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

В общем, просьба. Если такое происходит часто, попробуйте собрать инфу, может, что-то прояснится

[MORO]

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

Для разбора этой ситуации как минимум потребуется:

лог ЦУС и знание системного времени ЦУС по отношению к Гринвичу

лог MFTP Администратора

лог MFTP Клиента и знание системного времени Клиента по отношению к Гринвичу

логи с Клиента (в том числе и monitor.log), тем более, что пришлось перезагрузить компьютер

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

В общем, просьба. Если такое происходит часто, попробуйте собрать инфу, может, что-то прояснится

Так я и не предъявляю претензий. Я просто поставил "+1" в знак того, что да - такое дело наблюдается иногда и у меня в хозяйстве. Не скажу, чтобы часто. Да и не мешает особо.

Но, как поймаю, указанный Вами комплект постараюсь собрать. Мож и пригодится. ))

P.S. Отправка обновлений с изменением года на предыдущий вбита в мозг и моторику на уровне условного рефлекса. ))) Правда, в новых версиях ЦУС этот диалог уже выглядит иначе.