Обновления Справочников И Ключевых Данных.

[Effaceurs]

Добрый день.

Не могу выяснить закономерность, к примеру высылаю обновление ключевой информации на АП. На самом АП открываю транспортный модуль, жму опросить, наблюдаю, что обновления пришли, (в поле принято и отправлено есть изменения). Однако само предложение программы об обновлении не поступает (галочка выдавать предупреждение перед vipnet обновлениями стоит). В итоге для того что бы обновление пошло, нужно либо ждать определенное время (всегда разное).

Можно ли инициировать, после получения файлов обновления, само обновление vipnet вручную и с чем связана такая задержка? Спасибо.

Монитор клиент версии 3.2.

[Effaceurs]

Ситуация на некоторых координаторах схожая, но обновления вообще не происходит. Обновления ключей доходят, в папке ССС появляются файлы KEA*** .CNF .UP1 .LZH .DTM. Но обновления не происходит, в чём может быть причина? Спасибо.

[Rinya]

может при отправке информации, с ЦУС уходят с какими то параметрами. Как рассылаете обновления с ЦУС?

[Effaceurs]

Отправляю всё как обычно, (немедленно). Дело в том, что в сети 27 координаторов. Половина работают нормально (обновляются автоматически), половина принимают ключи и справочники, но обновления программы не происходит. Файлы с обновлениями, просто скапливаются в каталоге ССС и всё. Если переустановить программу VipNET Coordinator (полностью удалив каталог с программой), то программа работает как положено, но переустанавливать хлопотно, да и слишком тривиальное решение в данном случае. Скорее всего необходимо очистить какой-то каталог в программе, удалить файлы, только вот что... просто не понятно, что мешает программе обновиться. (сервера перезагружал, бесполезно).

Лог mftp
06.03.2014 10:31:13.439 2844 <-PUT F=58CE3A79.CTL L=56112 P=1
06.03.2014 10:31:13.442 2844 ->OFS F=58CE3A79.CTL L=0
06.03.2014 10:31:13.633 2844 R=6944, T=6944
06.03.2014 10:31:13.811 2844 R=47488, T=54432
06.03.2014 10:31:14.013 2844 R=1680, T=56112
06.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=56112
06.03.2014 10:31:14.639 Read C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\IN\58CE3A79.CTL
06.03.2014 10:31:14.872 start decrypting file C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\IN\58CE3A79.CTL
06.03.2014 10:31:15.292 stop decrypting file
06.03.2014 10:31:15.554 Unpack C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\KEAUMFE.LZH
06.03.2014 10:31:15.780 Unpack C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\KEAUMFE.CNF
06.03.2014 10:31:16.187 Unpack C:\Program Files (x86)\InfoTeCS\ViPNet Coordinator\CCC\KEAUMFE.DTM
06.03.2014 10:31:16.551 Save chr
06.03.2014 10:31:16.727 AnswerforCCC F69C7059.CTL
06.03.2014 10:31:16.942 2844 <-GET
06.03.2014 10:31:17.156 2844 ->GET
06.03.2014 10:31:17.344 2844 Timeout WaitMail 300
06.03.2014 10:31:17.547 F69C7059.CTL -> I=06AE000A P=220 F=140
06.03.2014 10:31:17.759 F69C7059.CTL moved from OUT\$TMP$ to ENV\CBF6B9E0
06.03.2014 10:31:17.969 2844 ->PUT F=F69C7059.CTL L=140 P=220
06.03.2014 10:31:18.180 2844 <-OFS F=F69C7059.CTL L=0
06.03.2014 10:31:18.587 2844 S=140, T=140
06.03.2014 10:31:18.993 2844 <-OFS F=F69C7059.CTL L=140
06.03.2014 10:31:19.182 Sent F69C7059.CTL to 06AE000A
06.03.2014 10:31:19.472 2844 ->GET
06.03.2014 10:31:19.647 2844 <-GET
06.03.2014 10:31:19.823 2844 Timeout WaitMail 300

[Effaceurs]

Ещё есть один вопрос.

Налажено межсетевое взаимодействие, между двумя координаторами (СМ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]

на СМ2 скорее всего выставлены некорректные настройки работы через межсетевой экран.

[Effaceurs]

Пронаблюдал одну закономерность. Серверы на которых установлено ПО Випнет Координатор, находятся в домене. Соответственно если перезагрузить машину, на которой координатор не обновляется (напомню, что ключи и справочники появляются в папке ССС), то при последующем входе, после перезагрузки, процессы monitor.exe и другие которые относятся к випнету, запущены от имени системы, соответственно, что бы увидеть перед собой випнет монитор, нужно было убивать процесс в диспетчере задач, и запускать его вручную с ярлыка. На другом сервере, где координатор тоже не обновляется, все процессы относящиеся к випнету запускаются вообще от имени другого пользователя (который в систему не заходил, но есть в домене). Соответственно на 1й снимке экрана, видно, что монитор запускается от имени пользователя raider, когда на 2м снимке экрана, видно что я единственный пользователь вошедший в систему.

Как я понял, где-то при установке, что-то пошло не так. Есть идеи?

[Effaceurs]

Нашёл решение. Для моего случая, если кому интересно, то лезем в реестр по ветке - [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\ViPNet-Monitor\Parameters]

В поле objectname пишем свой [логин]@[домен].

Перезагружаемся, сразу же випнет обновился и все файлы из ССС обработались и удалились.

[Echo]

Вероятно, есть проблемы с правами учетной записи __ViPNet User__, скорее всего, за счет применения доменных политик, которые эту запись не учитывают, либо запрещают.