Подпись файла ложная (искажены данные)

Форум » АРМ "Клиент" АС Клиент-Сбербанк » Подпись файла ложная (искажены данные) » Ответить

Подпись файла ложная (искажены данные)

romlog: Подскажите на что может ругаться обновленная до 019 версия АРМ? На компе вроде бы снес все программы по удаленному администрированию, почистил все подозрительные процессы, антивирус нод32 стоит сканирование сделано, но ошибка как выскакивала так и выскакивает. Техподдержка говорит напишите заявление на отключение защиты встроенной в новую версию, но это же чушь, какие могут быть гарантии что после такого заявления деньги не улетучатся со счетов а потом нам скажут сами виноваты...

Ответов - 56, стр: 1 2 3 All

u14was: А как дословно ругается?

Gavdis: Аналогичная ошибка с текстом: Ошибка обработки файла 30D4OSAC.0DE (квитанция о приёме файла) в банке:Эл.подпись файла ЛОЖНАЯ (искажены данные?)

Smitha: Нам пришлось письмо писать в сбер чтоб отключили эту защиту (аля мы все риски берем на себя) и только после этого банк клиент заработал.

Gavdis: Решил ситуацию так: В папке BASE неведомым образом исчез файл сетевого ключа KL******.KEY. Далее под Администратором Сервис -> Настройки программы -> Защита информации -> Установить ключ и указал на файл KL******.NKL, а сам сетевой ключ KL******.KEY заново скопировал в папку BASE. Перезапустил, заработало.

Mike666: Нам пришлось письмо писать в сбер чтоб отключили эту защиту У Вас удалённое управление разрешено?

Gavdis: ранее по форуму пробегало здесь

Mike666: Gavdis С Вашей подсказкой насчитал 4 способа решения проблемы - и все для различных ситуаций.

Smitha: Mike666 пишет: У Вас удалённое управление разрешено? Что подразумевается под удаленным управлением?

PaNo: Совсем недавно сталкивался с такими же "граблями": данное сообщение выводится, если на компьютере установлены программы удаленного управления, либо включено RDP (VNC, Radmin и т.д.). В моем случае выявил закономерность, что если во время работы КБ не подключаться к ПК данными программами, то все нормально. (проверял на UltraVNC 9.x)

smon: Я сисадмин. Мои бухи в начале сентября сдуру накатили 18-е обновление (или это я раньше сдуру оставил им такие права на XP в виртуалке под ESXi сервером, на который они ходили по RDP) Теперь уже более месяца бегаем по кругу, пытаясь перенести базу на выделенный под этого клиент-сбербанка физический комп. Техподдержка кивает на отделение и на тамошнего сбрасывателя привязок, тот утверждает, что всё сделал уже позавчера. Но нихрена не работает... Другая проблема состоит в том, что мои бухи нарываются на второй экземпляр такого же клиента, для счёта в другом отделении (настойчиво предлагаемый им там новый "облачный" клиент они пощупали, но он им не пришёлся...) Моя задача - минимизировать собственные и бухов трудозатраты на жизнеобеспечение банк-клиента. Вот, нашёл этот форум, люди кажется тут по-настоящему в теме... Вопрос первый. [strike]Какими неприятностями чревата установка в обоих случаях 17-й версии по прежней схеме в виртуалку? [/strike] К сожалению, есть у нас валюта, по крайней мере для одного из двух счетов. Вопрос второй. Уживутся ли вместе оба экземпляра АРМ в одном компе (виртуальном или на худой конец физическом), или надо непременно рассадить их по разным клеткам? Вопрос третий. Может быть, есть секретное знание, как в 18-й (или уже 19-й?) версиях обойти технический запрет "удалённого доступа", не давая стрёмных подписок банку от имени конторы? ту би континуед... ===== не осилил добавить свое мыло в профиль: sundmoon@gmail.com

Mike666: smon пишет: Техподдержка кивает на отделение и на тамошнего сбрасывателя привязок, тот утверждает, что всё сделал уже позавчера. Но нихрена не работает... Какое сообщение при этом выдаётся? smon пишет: Какими неприятностями чревата установка в обоих случаях 17-й версии по прежней схеме в виртуалку? Если валюты нет - никакой. smon пишет: Уживутся ли вместе оба экземпляра АРМ в одном компе Вся "хитрость" в том, что печать из К-Б будет только при регистрации rko_fr3_kb.ocx через regsvr32. Если заменить стандартный ярлык cmd-хой, в которой прописать: %windir%\system32\regsvr32.exe путь_к_К-Б\rko_fr3_kb.ocx wclnt.exe то печатать будет этот клиент. Либо слепить какую-либо "оболочку" (программ в инете полно) с кнопками "Печать ООО Рога и Копыта", "Печать ООО Хвост и Метёлка". На одну подцепить регистрацию OCX из версии 07.017, на другую - 07.019 (без разницы от какого клиента). Несколько неудобно, ну так можно придумать нечто получше. smon пишет: Может быть, есть секретное знание, как в 18-й (или уже 19-й?) версиях обойти технический запрет "удалённого доступа", не давая стрёмных подписок банку от имени конторы? Понятие "удалённый доступ" оказалось крайне растяжимым и раплывчатым. Вчера на ноуте "снесли" Norton Backup On-Line, чтобы не выдавалась "ЭЦП ложная". Есть на примете клиент, у которого его админ работает через RAdmin ежедневно, и никаких трабл. Я предупредил клиента, но это его админ - ему клиент позволяет делать, что угодно. Так что сначала посмотреть нужно, что произойдёт. Если реализуете дотуп по Citrix, как у нас некоторые сделали, то вообще без дурдома обойдётесь и на будущее.

smon: Спасибо! Запрет "удалённого доступа" как раз больнее всего ударил по своим собственным админам и беспомощным бухам, мышкой которых приходится периодически возюкать для их собственной психологической стабильности. Наше главное требование к рабочему месту буха - сохранение одновременного удаленного доступа админа к рабочему столу буха, как минимум к основному. Второе требование - виртуализация экзотических софтов, для взаимной изоляции их ошибок, отделения их от ошибок железа и разграничения ответствености разных поддержек. Складывается впечатление, что СБ покушается на то, чтобы дополнительно отжать для себя часть ресурсов клиента на его, клиента, территории: физический комп и/или трудовой ресурс (постоянное присутственное время админа). В запарке в сентябре я недостаточно хорошо протестировал, что собственно запрещено, но у меня сложилось впечатление, что 18 версия выдавала "ошибку подписи" даже при подключении к десктопу гостя через консольный клиент ESXi (без RDP). Точно ли в 19-й версии статус этой ошибки динамический? Совершенно непремлемо после любого эксперимента с доступом предпринимать многодневные офлайновые телодвижения (ногами бухов по отделениям) для восстановления работоспособности АРМ. Особенно благодарю за предложение помощи с недосброшенной привязкой! Напишу сюда при первой возможности взглянуть на ошибку.

sb77: Gavdis пишет: Далее под Администратором Сервис -> Настройки программы -> Защита информации -> Установить ключ и указал на файл KL******.NKL, а сам сетевой ключ KL******.KEY заново скопировал в папку BASE. Сетевым ключом шифрования является файл KL******.NKL и вы правильно сделали, установив его средствами системы. Файл KL******.KEY является технологической транспортной компонентой и не используется при работе программы. Можете смело удалить его из каталога - ничего не сломается.

smon: По словам буха, 4 раза вылезает что-то вот такое: Ошибка обработки файла 0734SBEC.5B2. Уважаемый клиент, вы пытаетесь отправить файл с другого компьютера. Если вы действительно этого хотите, тогда измените параметры в меню Сервис/Параметры/ вкладка Каталоги и имена/ поле Документы подписываются с компьютера. ЕМНИП, я уже безуспешно пытался это поправить методом тыка (потому что поддержка ушла в глухую несознанку и твердила о необходимости в очередной раз "сбросить привязку"). И ещё вот такое: Описание таблицы docdetail.ddf не найдено в файле clsubsys.ddf (эту хрень я тоже видел, но бухи мне сейчас её мучительно надиктовали явно с ошибками "s как доллар" и т.п.) Версия там ещё 18-я стоит (она так и не заработала у нас без этой ошибки то ли вовсе ни разу, то ли... кажется, был просвет на несколько часов в самом начале. Причём поработало именно через "удалённый доступ", после того, как я по совету ТП скачал вручную и накатил полный дистрибутив.)

Черная Собака: поддержка ушла в глухую несознанку и твердила о необходимости в очередной раз "сбросить привязку"). Это сообщение, действительно, говорит о необходимости сбросить привязку. СБ покушается на то, чтобы дополнительно отжать для себя часть ресурсов клиента Сбер анализирует попытки взлома программы и затыкает дыры. Ваши ресурсы ему глубоко фиолетовы, ничего он отжимать не собирается.

smon: Это сообщение, действительно, говорит о необходимости сбросить привязку. А сбрасывательщик привязки в отделении (незаменимый кадр: дозвониться ему невозможно, обещаний перезвонить не исполняет, в общем... побеседовать с ним по душам можно, только представ перед ним ногами) - в третий раз утверждает, что сбросил эту привязку "позавчера". Само Тверское отделение втихаря мигрировало с насиженного места: бухи притащились туда в начале сентября к закрытым дверям. Сбер анализирует попытки взлома программы и затыкает дыры. (Вяло интересуюсь) законна ли внезапная инвалидация ЭЦП клиента? А фактический отказ в дистанционном обслуживании? (Извините я не в курсе и НЕ ХОЧУ входить в курс - но, кажется, за этот сервис взимаются деньги?) Ваши ресурсы ему глубоко фиолетовы, ничего он отжимать не собирается. Вы уверены, что он не мечтает сэкономить на зарплате здешних модераторов и прочих уважаемых участников? :spy:

smon: Собственно, мои знакомые коммерсы давно проголосовали ногами, свалив из сбера в альтернативные банки с сравнительно качественным ДО. Жаль, что не все могут последовать за ними, и что мне как раз приходится помогать кому-то из оставшихся несчастных.

Mike666: smon Ладно, не огрызайтесь! Вы не офсайте Сбербанка. По поводу ошибки отправки "с другого компьютера" - что выставлено в "Сервис" ---> "Параметры" ---> "Каталоги и имена" ---> "Документы подписываются с комьютера..."? Если не с того, что отправляет файлы в банк, то "галку" "Рабочее место осуществляет обмен данными с банком" нужно ОБЯЗАТЕЛЬНО убрать. Поехали далее - "Документы подписываются с компьютера ..." Если подписи "разносятся" с разных компов, то номера компьютеров должны быть для каждого оператора разные. "Первый" - это с какого отправляется (как правило), НО! Если платёжки создаются на одном и с него же отправляются - это безусловный "Первый", если начальство подписывает на своих компах - это "второй", "третий" и т.д. Этот признак должен быть жестко выставлен на каждом компе. Разобрались? Если подписи производятся на различных компьютерах, то ТПоддержке указывайте в заявках, что "привязку требуется снять" с компьютера 1, 2, 3 и тех, на которых идёт создание документов и подписание.

smon: "Компьютер один" единственный, галка стоит. База на него скопирована по инструкциям телефонной подддержки с другого компьютера (где ЭЦП стала "недействительной" из-за "удалённого доступа"). Телефонная поддержка кивает на необходимость сброса привязки, сбрасыватель утверждает, что всё сделал. В следующей итерации проверили на предмет отсутствия неотправленных исходящих документов со старого компа. И опять телефонная поддержка кивает на необходимость сброса привязки, сбрасыватель утверждает, что всё сделал... Пардон, заметил, что в новом компе (залитом со стандартного образа) присутствует сервис Dameware. Гляделкой я не пользовался. Может, в этом было дело? Сейчас буду ставить на чистую XP свежее АРМ для другого отделения. Хотя там валюты нет, попробую всё-таки использовать самый последний дистр (19.01? Где взять? А то в пакете из банка 17-я версия...) и разобраться с "удалённым доступом". Есть настойчивое желание упихать всё-таки этого монстра в виртуалку. И уже потом, после того как этот экземпляр заработает - буду переносить туда же старое АРМ.

Mike666: 19.01 пока нет, будет, может быть, на следующей неделе. В виртуалке размер диска трогать не рекомендую.

smon: Ага, поддержка пообещала свежий дистр во вторник. Но предложила поставить 17 из пакета, а потом обновиться. А вот скажите пожалуйста, когда инсталлятор спрашивает "ФИО первого и второго пользователей" - имеются в виду директор и главбух? У нас реально пользователь была одна (сейчас главбух, пенсионного возраста женщина, рвётся тоже научиться). В первом монстрике наша бух по очереди втыкала нужную флешку и подписывала то за директора, то за главбуха :) Мне при установке надо указывать не реальных пользователей, а тех, чьи будут подписи?

Mike666: smon пишет: скажите пожалуйста, когда инсталлятор спрашивает "ФИО первого и второго пользователей" - имеются в виду директор и главбух? У Вас в "доступности" инсталлятора лежат файлы Clientsb.cbp, либо WinCLNT.TRN. Уберите инсталляшку в "глухой" каталог.

smon: Гмм.. А мне как раз поддержка велела положить новый Clientsb.cbp, выданный на флешке с ключами, в папочку которая подсовывается инсталлятору...

Mike666: smon пишет: А мне как раз поддержка велела положить новый Clientsb.cbp, выданный на флешке с ключами, в папочку которая подсовывается инсталлятору... Вы устанавливаете или обновляете?

smon: На виртуалке есть папка C:\SBRF со старым АРМ (которое перестало работать с 18-м обновлением из-за "удалённого доступа", а затем делались попытки перенести базу и завести его на выделенном физическом компе, безуспешные из-за описанного выше казуса с недосбросом привязки.) Потому на то первое АРМ я пока временно забил. Было ли в виртуалку первое АРМ изначально установлено из инсталлятора или туда пересено, я не помню к сожалению. Я устанавливаю новое АРМ от другого отделения в старую виртуалку, но в папку C:\SBRF_VTOROE\CLIENTSB Блин, даже офиц. техподдержка у них по разным телефонам!.. По рекомендации второй поддержки я ставлю 17 версию с компакта из пакета, скопировав на C:\Distr-CLSB несколько файлов из Distr-CLSB с компакта (17-й версии) и положив туда же ключевые файлы с флешки (флешка и компакт из нового пакета). Инсталлятор запускал с компакта.

smon: И ещё вопрос. Можно ли, чтобы не позволять сущностям умножаться зря (т.е. флешкам плодиться и размножаться) записать первые сгенерённые инсталлятором ключи на ту же флешку из банковского пакета, откуда я беру ключи для самого инсталлятора?

Mike666: smon пишет: сгенерённые инсталлятором ключи на ту же флешку из банковского пакета, откуда я беру ключи для самого инсталлятора? Э-э-э... не совсем понял. В "банковском" пакете находятся ключи багка, а не ключи клиента. Ключи клиента находятся в базе и на носителях клиента.

smon: Пускай так. Надеюсь, ключам банка (тем, что на флешке из пакета) ничего плохого не сделается от того, что первые сгенерённые инсталятором ключи организации будут у нас храниться на той же банковской флешке? Флешек нам не жалко, только в них уже можно утонуть. Бухам-женщинам, конечно, несравненно легче поддерживать среди них порядок, чем мне - но и они путаются... Вчерашний вопрос актуален: ФИО каких "первого" и "второго" пользователей спрашивает инсталлятор? Я при первой попытке вчера ответил реальными ИФ бухов (решил, что это что-то вроде логинов). Но потом усомнился: может, здесь нужны ФИО лиц с правом подписи?

Mike666: smon пишет: решил, что это что-то вроде логинов Так и есть. Только "нормальный" перенос осуществляется копированием. Затем запускается Configwc и "забиваются" данные с "Параметров дистрибутивного комплекта" (кнопка "Дополнительно" при этом не нажимается), регистрируется rko_fr3_kb.ocx, после запуска в "Сервис" --> "Параметрах" --> "Связь" проверяется "Имя клиента на сервере". Всё. Без каких-либо переустановок.

smon: после запуска в "Сервис" --> "Параметрах" --> "Связь" проверяется "Имя клиента на сервере" Вот этого вот последнего я не помню, чтобы мне говорила поддержка первого АРМ. Посмотрю. Остальное написанное про нормальный перенос мне очень хорошо знакомо: я несколько раз проделал это в сентябре. Вот только привязка так и не перепривязалась отчего-то... Я отчаялся пока и до времени забил на проблему с первым АРМ. У меня сейчас иной план действий, благодаря тому что бухи как раз заказали установку ещё одного АРМ (от другого отделения). Завтра или в понедельник я предприму следующую попытку установить второе АРМ, в директорию C:\SBRF_VTOROE\CLIENTSB в ту же самую виртуалку, где в директории C:\SBRF\CLIENTSB стоит первое АРМ. А решать проблемы с первым буду только после того, как в хвост и в гриву протестирую второе, выжав из него максимум возможного удобства для себя любимого и своих подопечных (виртуалку и желательно удаленный доступ). Раз уж я вынужден их сопровождать - лучше я переутруждусь при установке, но обеспечу минимум проблем для себя в продуктиве, управление окружением АРМ без погружения в его потроха, изоляцию ожидаемых в будущем ошибок, лёгкость их устранения сисадминскими методами и свою доказательную базу в тех случаях, когда неисправность АРМ вызвана внутренними банковскими причинами. Я крайне зол оттого, что банк создаёт проблемы моим бухам, а те нервничают и перекладывают их на меня - тем яростнее моё стремление максимально оградить от покушения свой интерес, а также интерес создаваемой мною инфраструктуры (а значит, и интерес бухов как представителей моей конторы перед банком, а не наоборот!)

smon: Можно ли сделать общей для двух экземпляров АРМ в моём случае какую-то ещё информацию? Ключи? Подписи? AMICON-VPN? Давно надоела дурь с бесконечно приобретаемыми бухами криптопро... Хоть размножение амиконов попытаюсь пресечь в зародыше, раз уж вынужден в этом участвовать ((

Mike666: Амикон на разные банки будут различными, без вариантов. А "криптопро..." - это к другой программе????

smon: Конечно, к другой. :) Ещё только со сбербанком очередной пары криптопро нам не хватало... Спасибо за ценное указание про амиконы. А на каком уровне они будут различными - разные должны быть только физические ключи (которые постоянно в компе)? Разные туннели (могут ли они быть поднятыми одновременно)? Или задача пользователя (вернее, админа) следить за тем, чтобы в момент обмена был поднят правильный туннель? Как посоветуете мне её решать, чтобы минимизировать гимор для бухов в продуктиве? Но минимизируем без экстрима: от сбербанк-АРМ вышла хотя бы та польза, что юзавшая его бух постепенно стала довольно продвинутой юзершой. Она осознаёт те действия, которые я хочу для неё максимально автоматизировать.

Mike666: smon пишет: Разные туннели (могут ли они быть поднятыми одновременно)? Мне такое не удавалось ещё. Но... я не пробовал поднимать на последних версиях. smon пишет: задача пользователя (вернее, админа) следить за тем, чтобы в момент обмена был поднят правильный туннель? Верно.

smon: Пока надежды не теряю. Потому что у меня бух навострилась пользоваться клиентом сетевого USB-сервера )) Включает-отключает девайсы, понимает, что делать в случае, если девайс "удалённо занят". Проблемы возможны потом, при попытке научить этому главбуха.

Andrea: romlog пишет: Подскажите на что может ругаться обновленная до 019 версия АРМ? На компе вроде бы снес все программы по удаленному администрированию, почистил все подозрительные процессы, антивирус нод32 стоит сканирование сделано, но ошибка как выскакивала так и выскакивает. Техподдержка говорит напишите заявление на отключение защиты встроенной в новую версию, но это же чушь, какие могут быть гарантии что после такого заявления деньги не улетучатся со счетов а потом нам скажут сами виноваты... все это ерунда, пусть вам уберут на сервере Банка 2000 галочка - Клиенту запрещен удаленный доступ, и все будет нормально работать.

smon: пусть вам уберут на сервере Банка 2000 галочка И что же они попросят с нас взамен за эту навязанную нам услугу? :spy:

Smitha: smon пишет: И что же они попросят с нас взамен за эту навязанную нам услугу? Письмо о том что если украдут у вас деньги в этом виноваты будете вы а не банк.

smon: По-моему, цена непомерная. А услуга - повторяюсь! - навязанная. Впрочем, в 19.01 в клиентских настройках (Сервис-Параметры-Связь) обнаружилась галочка "Разрешить удаленный доступ". Опробую - отпишусь (смогу только на будущей неделе; так что если кто-то уже опробовал, колитесь сразу и не томите)

sb77: smon пишет: обнаружилась галочка "Разрешить удаленный доступ" Эта галочка совсем для другого - для модемных клиентов и была во всех версиях прграммы. Не тратьте на неё ваше время)))

smon: Старый зелёный амикон ключик вроде как задышал на ладан и начал подключаться через раз (по крайней мере c USB-IP сервера), а через раз пишет, что ключ дохлый (при этом выглядит как невнятный VPN-KEY c драйвером что-то вроде Shipka). Можыд и софтовое это, но... Спросил девушек из дистанционного обслуживания свежей инсталляции о возможности использовать их новый серебристый ключ ещё и для старого туннеля (к старому отделению, взамен сдохшего зелёного). Они уверенно ответили положительно и обещали свою помощь, если поддержка не поможет. (Поскольку телефоны поддержки у разных отделений разные, предчувствую, что предложение мною будет принято ) В общем, я решил разлучить АРМ(ы?)) и VPN роутер, примерно так: http://sergey-s-betke.blogs.novgaro.ru/networking/vpn/fpsu-ip/fpsu-router Ключи или буду цеплять к виртуалке скриптом и подставлять нужные директории через subst, или запихну в контейнер примерно вот так: http://klientsb.forum24.ru/?1-9-0-00000015-000-0-0-1310238752 (виртуалки под АРМ будут выделенными, без этих ваших онтернетов) Прокомментируйте, пожалуйста. И ещё вопрос: есть ли шанс в обоих АРМ-ах использовать единственную пару ключей директора и главбуха? А может, и мастер-ключ объединить? :spy: Если такое реально, это составит для меня доп. мотивацию оба АРМ-а засадить в одну виртуальную клетку.

smon: Еще вопрос: как обновить до свежей версии сбойнувшее после 18-го обновления из-за "удалённого доступа" старое ARM (в C:\SBRF) в старой виртуалке, в которой я давеча уже провёл свежую установку C:\SBRF_VTOROE Обновление с офсайта хочет накатываться строго на второе, а первого не чует.

smon: Ну и чисто из любопытства... Теоретиццкий такой интерес: нахера козе боян? В АРМ и так используется крипто, надо полагать серьёзное. Что помешало на нём же и IPSec замутить (при необходимости усилив его аппаратными токенами при _единственной_ проге, пощадив психику бухов и сисадминов)? Необходимость откатить и занести КОМУ НАДО? (деньги клиентов со всей страны) Стремление размазать отстатки отвественности банка перед клиентами? Или настоятельное побуждение известных органов ничуть себя не утруждая и не беспокоя Грефа заиметь бэкдор в каждую контору? :spy:

smon: Ога... додумались. Бизнес-онлайн с TLS-ключом. А толстый клиент у него действительно будет? Полноценный офлайновый кэш чтобы...

smon: Скажите, а вот 2 метра флеша на серебристом амиконе - его можно как-то использовать в наших мирных целях? Или это ресурс, зарезервированный разработчиками для своих нужд?

4141KuznetsovAV: Можно на этих 2-х метрах поселить главный ключ с подселением к нему ЭЦП

smon: Пока что мне удалось сделать в третьей виртуалке амикон-роутер на серебристом ключе, который работает как для нового, так и для старого АРМ от другого отделения (зелёный ключ отправляется на пенсию). В планах - после достижения стабильной работы обоих АРМ каждого в выделенной виртуалке - потестить удалённый доступ к этим виртуалкам. Вооружившись результатом этого предприятия (успешным или не очень), потом уже буду думать, как сократить количество виртуалок. Попутно кажется научился чистить базу от т. н. "привязок", по крайней мере старое АРМ заработало на переименованной виртуальной системе без хождения ногами в отделение. Если перепривязыватель не врал, АРМ от того компа уже дважды было перепривязано куда-то ещё...

smon: --4141KuznetsovAV-- есть ли шанс в обоих АРМ-ах использовать единственную пару ключей директора и главбуха? А может, и мастер-ключ объединить? :spy: Если такое реально, это составит для меня доп. мотивацию оба АРМ-а засадить в одну виртуальную клетку. ...А физической секурности кллючей уделить дополнительное внимание, невозможное в условиях, когда ключи плодятся подобно кроликам

smon: Пока что мне удалось сделать в третьей виртуалке амикон-роутер на серебристом ключе, который работает как для нового, так и для старого АРМ от другого отделения (зелёный ключ отправляется на пенсию). Иногда теперь не даёт подписать платёжку ЭЦПодписью: пишет "указанное действие недоступно при активном сеансе связи". Как вариант, я придумал уже перезапустить АРМ и (не запуская сеанс связи) подписать всё что надо, а потом отправить следующим рейсом. Посоветуйте более экономный вариант закрыть сеанс связи, не вылезая из виртуалки и не перезапуская АРМ. А также какой-нибудь визуальный индикатор "активности сеанса связи". Куда смотреть? Если вдруг смотреть некуда - то как организовать такой индикатор? (например, по ярлыку запуская скрипт)

smon: smon пишет: есть ли шанс в обоих АРМ-ах использовать единственную пару ключей директора и главбуха? А может, и мастер-ключ объединить? :spy: Получил официальный ответ от поддержки на свой вопрос о возможности объединить между двумя АРМ максимум криптографической информации (ключи и подписи директора-главбуха). Ответ таков: это возможно только в том случае, если оба счёта открыты в одном отделении. (( По-прежнему актуален вопрос о состоянии "активности сеанса связи". Каким образом оператор АРМ может узнать о том, что АРМ находится в этом состоянии, до того, как полезет подписывать платёжку и получит облом?

smon: Частичная победа! Старый слетевший в сентябре АРМ (от старого отделения), обновлённый мною до версии 19.01 - сейчас у меня нормально работает при подключении к виртуалке через RDP (это та же самая старая виртуалка, на которой он работал до слёта - потому новых хождений ногами в отделение не занадобилось). Амикон (единственный, от нового отделения) при этом стоит на отдельном роутере. Если существует секретное знание о возможности обобществить криптоключи для разных московских отделений, мне хотелось бы к нему приобщиться - чтобы объединить разные АРМ в одной виртуалке, упростив себе и бухам жонглирование ключами и подписями.

smon: А то как-то по смыслу бредово выходит: ключ организации и ЭЦП ответственных лиц ВНЕЗАПНО не удостоверяют самих этих лиц и организацию, а только в качестве клиентов конкретного отделения. "Раздвоение личности" и дальнейшее её тиражирование... Ради поддержания милого сберу внутреннего бардака. -- Или я не понимаю чего-то? :spy: Нет, то простое соображение, что "не надо класть все деньги в одну корзину", мне доступно. Так можно было бы продолжать торговать яйцами, обходясь без высоких информационных технологий. А с ними хочется уже чего-то более толкового.

smon: smon пишет: сейчас у меня нормально работает при подключении к виртуалке через RDP Увы, рано обрадовался. Работает через RDP на раз или два, а на второй-третий раз выдаёт то же самое: "электронная подпись ложная!" Зато от вмваре клиента вроде бы не слетает, так что начерно годится. Но надо будет это дальше ковырять...

smon: На сегодня мною было сделано и работает: отдельный амикон-роутер (внешний интерфейс смотрит в маскарядящий фаервол, с внутр. интерфейса убирана привязка амикон) Соседние виртуализованные АРМ, которые "осушествл. обмен с банком", смотрят по дефолту в этот роутер и лишены интернета; все они сделаны по одному образцу, на каждом подключены два вирт. removable диска, соотв. инициалам директора и главбуха; никакого лишнего софта на них нет, в т.ч на них нет ЗЛА(антивирей) С удовольствием бы оставил одну такую АРМ (объединив транспортную роль для всех отделений) - но не смог устранить путаницу из-за различия ЭЦП, связанных с разными отделениями. Вот здесь http://klientsb.forum24.ru/?1-2-0-00000189-000-20-0 в сообщениях автора pashtet78 изложены дальнейшие пути улучшения конструкции Собираюсь сделать (покритикуйте плиз следующую схему): На том амикон-роутере расшариваем папки базы каждого отделения (на внутреннем интерфейся отставляем нетбиос)... можно вместо этого создать лишний файловый сервер, но в моём интересе обойтись без лишних сущностей Делаем столько, сколько нужно, ARM только для набивания платёжек/обмена данными и просмотра базы. Ограничения на "удалённый доступ" на них не распространяются(??). Следовательно они могут быть и на физ. компах бухов вместе с прочим их г..софтом, требующим удалённой поддержки. Все АРМ настраиваем на расшаренные папки роутера. PROFIT!! (для админа и конторы; а банк нехай подавится своей костью: АРМ с транспортной ролью всё-таки не работают через "удалённый доступ") НО.... Стоит ли мне всё-таки позаботиться при этом об интересе сбербанка - не давая буховским г..компам постоянного доступа в его 10-ю сетку? Эта цель запросто может быть достигнута лишними интерфейсами и сетками/виланами c ACL в виртуальной среде. Или им там похрен?

WatsonRus: Gavdis пишет: Решил ситуацию так: В папке BASE неведомым образом исчез файл сетевого ключа KL******.KEY. Далее под Администратором Сервис -> Настройки программы -> Защита информации -> Установить ключ и указал на файл KL******.NKL, а сам сетевой ключ KL******.KEY заново скопировал в папку BASE. Перезапустил, заработало. Сегодня имел "счастье" столкнуться с подобной ситуацией с 18-й версией. :( Только у нас причина была несколько в другом - винт похоже начал сыпаться, и файл KL******.NKL видимо был запорчен, хотя еще на прошлой неделе все было Ок. Придется переносить всю инфу, включая систему, на другой винт. А это целый гемор с привязкой/отвязкой КБ. :( sb77 пишет: Сетевым ключом шифрования является файл KL******.NKL и вы правильно сделали, установив его средствами системы. Файл KL******.KEY является технологической транспортной компонентой и не используется при работе программы. Можете смело удалить его из каталога - ничего не сломается. Он, кстати, при переустановке сетевого ключа никуда и не копируется.

Mike666: smon пишет: Эта цель запросто может быть достигнута лишними интерфейсами и сетками/виланами c ACL в виртуальной среде. Вы молодец! Редко кто, на моей памяти, двигался не прямо, а "чуть вниз, влево, напрямо, ну и чуть вправо". Стало редкостью видеть увлечённого человека. WatsonRus пишет: Он, кстати, при переустановке сетевого ключа никуда и не копируется. Верно, дописывается в файл контроля.

полная версия страницы