Effaceurs Опубликовано 19 Февраля 2014 Жалоба Поделиться Опубликовано 19 Февраля 2014 Добрый день. Не могу выяснить закономерность, к примеру высылаю обновление ключевой информации на АП. На самом АП открываю транспортный модуль, жму опросить, наблюдаю, что обновления пришли, (в поле принято и отправлено есть изменения). Однако само предложение программы об обновлении не поступает (галочка выдавать предупреждение перед vipnet обновлениями стоит). В итоге для того что бы обновление пошло, нужно либо ждать определенное время (всегда разное).Можно ли инициировать, после получения файлов обновления, само обновление vipnet вручную и с чем связана такая задержка? Спасибо. Монитор клиент версии 3.2. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Effaceurs Опубликовано 5 Марта 2014 Автор Жалоба Поделиться Опубликовано 5 Марта 2014 Ситуация на некоторых координаторах схожая, но обновления вообще не происходит. Обновления ключей доходят, в папке ССС появляются файлы KEA*** .CNF .UP1 .LZH .DTM. Но обновления не происходит, в чём может быть причина? Спасибо. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Rinya Опубликовано 5 Марта 2014 Жалоба Поделиться Опубликовано 5 Марта 2014 может при отправке информации, с ЦУС уходят с какими то параметрами. Как рассылаете обновления с ЦУС? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Effaceurs Опубликовано 6 Марта 2014 Автор Жалоба Поделиться Опубликовано 6 Марта 2014 Отправляю всё как обычно, (немедленно). Дело в том, что в сети 27 координаторов. Половина работают нормально (обновляются автоматически), половина принимают ключи и справочники, но обновления программы не происходит. Файлы с обновлениями, просто скапливаются в каталоге ССС и всё. Если переустановить программу VipNET Coordinator (полностью удалив каталог с программой), то программа работает как положено, но переустанавливать хлопотно, да и слишком тривиальное решение в данном случае. Скорее всего необходимо очистить какой-то каталог в программе, удалить файлы, только вот что... просто не понятно, что мешает программе обновиться. (сервера перезагружал, бесполезно).Лог mftp06.03.2014 10:31:13.439 2844 <-PUT F=58CE3A79.CTL L=56112 P=106.03.2014 10:31:13.442 2844 ->OFS F=58CE3A79.CTL L=006.03.2014 10:31:13.633 2844 R=6944, T=694406.03.2014 10:31:13.811 2844 R=47488, T=5443206.03.2014 10:31:14.013 2844 R=1680, T=5611206.03.2014 10:31:14.214 Received 58CE3A79.CTL via MFTP from 06AE000A (101,65 KB/sec)06.03.2014 10:31:14.425 2844 ->OFS F=58CE3A79.CTL L=5611206.03.2014 10:31:14.639 Read C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\IN\58CE3A79.CTL06.03.2014 10:31:14.872 start decrypting file C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\IN\58CE3A79.CTL06.03.2014 10:31:15.292 stop decrypting file06.03.2014 10:31:15.554 Unpack C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\KEAUMFE.LZH06.03.2014 10:31:15.780 Unpack C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\KEAUMFE.CNF06.03.2014 10:31:16.187 Unpack C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\KEAUMFE.DTM06.03.2014 10:31:16.551 Save chr06.03.2014 10:31:16.727 AnswerforCCC F69C7059.CTL06.03.2014 10:31:16.942 2844 <-GET06.03.2014 10:31:17.156 2844 ->GET06.03.2014 10:31:17.344 2844 Timeout WaitMail 30006.03.2014 10:31:17.547 F69C7059.CTL -> I=06AE000A P=220 F=14006.03.2014 10:31:17.759 F69C7059.CTL moved from OUT\$TMP$ to ENV\CBF6B9E006.03.2014 10:31:17.969 2844 ->PUT F=F69C7059.CTL L=140 P=22006.03.2014 10:31:18.180 2844 <-OFS F=F69C7059.CTL L=006.03.2014 10:31:18.587 2844 S=140, T=14006.03.2014 10:31:18.993 2844 <-OFS F=F69C7059.CTL L=14006.03.2014 10:31:19.182 Sent F69C7059.CTL to 06AE000A06.03.2014 10:31:19.472 2844 ->GET06.03.2014 10:31:19.647 2844 <-GET06.03.2014 10:31:19.823 2844 Timeout WaitMail 300 Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Effaceurs Опубликовано 7 Марта 2014 Автор Жалоба Поделиться Опубликовано 7 Марта 2014 Ещё есть один вопрос.Налажено межсетевое взаимодействие, между двумя координаторами (СМ1 мой, доступен публично, без экранов) и (СМ2 чужой). СМ2 имеет только внутренний ip адрес (192.168.100.51), публично доступен через шлюз (Ш - 89.239.128.150). В свойствах СМ2 на координаторе СМ1, я на вкладке межсетевой экран добавляю адрес Ш, выставляю минимальную метрику 1. Всё работает как положено. Однако, затем, автоматически в свойствах узла СМ2, на вкладке межсетевого экрана (рис 2.), помимо добавленного мною адреса Ш, добавляется внутренний адрес СМ2, и узел СМ2 становится недоступным. Удаляю вручную внутренний адрес СМ2 на вкладке межсетевого экрана, через минуту он появляется там автоматически. Выставляю метрику 9999 для внутреннего адреса СМ2, всё равно узел недоступен. Помогает только поднять адрес Ш, зелёной стрелочкой выше внутреннего адреса СМ2 (рис. 3), то всё работает, однако со временем, он (внутренний адрес СМ2) сам встаёт выше адреса Ш (рис. 2) и связь пропадает.Вопрос в чём, почему игнорируется метрика, зачем автоматически в межсетевой экран подсовывается внутренний адрес СМ2, почему они меняются местами?Соответственно, на рисунке 2, узел недоступен, на рисунке 3 узел доступен. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Rinya Опубликовано 7 Марта 2014 Жалоба Поделиться Опубликовано 7 Марта 2014 на СМ2 скорее всего выставлены некорректные настройки работы через межсетевой экран. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Effaceurs Опубликовано 12 Марта 2014 Автор Жалоба Поделиться Опубликовано 12 Марта 2014 Пронаблюдал одну закономерность. Серверы на которых установлено ПО Випнет Координатор, находятся в домене. Соответственно если перезагрузить машину, на которой координатор не обновляется (напомню, что ключи и справочники появляются в папке ССС), то при последующем входе, после перезагрузки, процессы monitor.exe и другие которые относятся к випнету, запущены от имени системы, соответственно, что бы увидеть перед собой випнет монитор, нужно было убивать процесс в диспетчере задач, и запускать его вручную с ярлыка. На другом сервере, где координатор тоже не обновляется, все процессы относящиеся к випнету запускаются вообще от имени другого пользователя (который в систему не заходил, но есть в домене). Соответственно на 1й снимке экрана, видно, что монитор запускается от имени пользователя raider, когда на 2м снимке экрана, видно что я единственный пользователь вошедший в систему.Как я понял, где-то при установке, что-то пошло не так. Есть идеи? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Effaceurs Опубликовано 14 Марта 2014 Автор Жалоба Поделиться Опубликовано 14 Марта 2014 Нашёл решение. Для моего случая, если кому интересно, то лезем в реестр по ветке - [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\ViPNet-Monitor\Parameters]В поле objectname пишем свой [логин]@[домен]. Перезагружаемся, сразу же випнет обновился и все файлы из ССС обработались и удалились. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Echo Опубликовано 14 Марта 2014 Жалоба Поделиться Опубликовано 14 Марта 2014 Вероятно, есть проблемы с правами учетной записи __ViPNet User__, скорее всего, за счет применения доменных политик, которые эту запись не учитывают, либо запрещают. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения
Присоединиться к обсуждению
Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.