Vipnet совместимость с антивирусами
Данная проблема может возникать при отсутствии разрешения на создание файлов в папке, в которую Вы пытаетесь сохранить файл запроса *.p10. Попробуйте создать папку на «Рабочем столе» и выбрать ее в качестве целевой для сохранения файла запроса.
При работе в 1с возникает ошибка «Не найден криптопровайдер».
Убедитесь, что в настройках ViPNet CSP включена опция «Поддержка работы ViPNet CSP через Microsoft CryptoAPI».
При работе в 1с постоянно запрашивается путь к контейнеру с закрытым ключом.
Вам необходимо загрузить и установить набор ПО из личного кабинета ФНС , в подразделе «Получение сертификата ключа проверки электронной подписи» раздела «Профиль», выбрав вариант использования «Ключ электронной подписи хранится на Вашей рабочей станции». После перезагрузки ПК в данном разделе должна была появиться кнопка «Сформировать запрос на сертификат», далее ожидать выпуска сертификата, после этого его можно установить в хранилище ПК.
При работе с порталом СБИС выдаётся ошибка «Плохой ключ»
Необходимо проверить установку сертификатов УЦ и списка отозванных сертификатов, при их наличии и актуальности обратитесь в техническую поддержку портала.
После установки на компьютер ViPNet CSP пропадает доступ в интернет и приложения, при удалении выходит ошибка “Не удалось удалить ViPNet CSP”?
Данные ошибки могут возникать, если вы используете антивирус, несовместимый с ViPNet CSP, например NOD32. Для восстановления работоспособности:
- Загрузите ОС Windows в безопасном режиме;
- Запустите «от имени администратора» файл "C:\Program Files\InfoTeCS\ViPNet CSP\SafeModeUninstall.bat" для 32-разрядной ОС или "C:\Program Files (x86)\InfoTeCS\ViPNet CSP\SafeModeUninstall.bat" для 64-разрядной.
При установке ViPNet CSP возникает «Ошибка при выполнении операции Visual C++ Studio2008 Redistributable files».
Данная ошибка сигнализирует о невозможности установки компонентов Microsoft Visual C++ Studio 2008 Redistributable files. Удалите штатными средствами Windows через «панель управления»-«программы и компоненты» оба пакета Microsoft Visual C++ Redistributable 2008. Загрузите с сайта Microsoft актуальные версии компонентов и установите их:
В том случае, если установка пройдет неуспешно, обратитесь к IT специалисту вашей организации или в службу технической поддержки Microsoft.
При запуске ViPNet CSP возникают ошибки «Параллельная конфигурация неправильна» / «Не найдена зависимая сборка» / «0xc000007b»
Данные ошибки возникают вследствие некорректной работы компонентов Microsoft Visual C++ Redistributable.
Работоспособность при установке ViPNet CSP совместно с несертифицированными антивирусами.
Работоспособность с несертифицированными антивирусами возможна, но не гарантируется. Например, для совместной работы ViPNet CSP и антивирусов AVAST, AVG, необходимо использовать актуальную версию ViPNet CSP из раздела “Бета-версии” . При использовании ViPNet CSP совместно с антивирусом AVAST необходимо дополнительно отключить экран поведения.
При установке ViPNet CSP совместно с антивирусом NOD32 нарушается работоспособность системы.
На текущий момент совместимость с данным антивирусом не гарантируется. При возникновении проблем в работе Вашей ОС рекомендуем удалить текущую версию ViPNet CSP, загрузив ОС в безопасном режиме. Перед удалением необходимо вручную запустить службу установщика Windows. Если в безопасном режиме служба установщика Windows не запускается, примените bat-файл из папки C:\Program Files (x86)\InfoTeCS\ViPNet CSP\SafeModeUninstall.bat. Если в безопасный режим зайти не получается, то необходимо выполнить восстановление системы с последней контрольной точки.
Для решения возникшей ошибки необходимо произвести операцию восстановления ViPNet CSP. Для восстановления необходимо использовать версию ViPNet CSP 4.2.948766 из раздела “Бета-версии”.
Не работает электронная подпись в программе 1C.
Для работы в программе 1С вам необходимо установить и зарегистрировать ViPNet CSP. Далее необходимо получить цифровую подпись в одном из доверенных удостоверяющих центров (список доверенных удостоверяющих центров уточняйте у поставщика услуг) и установить контейнер с сертификатом в ViPNet CSP. Дополнительно вам необходимо установить корневой сертификат удостоверяющего центра и список отзыва сертификатов (их можно скачать с сайта вашего удостоверяющего центра).
Рекомендуем проверить настройки подписи в 1С. Отсутствие подписи может быть вызвано не корректными настройками в 1С, например, задан другой тип криптопровайдера или не указан текущий сертификат. Более подробное описание по настройкам вы можете уточнить в технической поддержке 1С.
При попытке запустить программу ViPNet CSP выходит ошибка "Программа не может быть запущена, поскольку нарушена целостность системы регистрации".
Для решения проблемы требуется удалить CSP, удалить файл csp.brg, находящейся по пути %ProgramData%\InfoTeCS\ViPNet CSP, установить CSP, зарегистрировать программу заново.
При попытке установить ПО ViPNet CSP 4.x выходит ошибка: " Не удалось запустить приложение, поскольку его параллельная конфигурация неправильна."
Для решения проблемы необходимо:
При попытке осуществления функции подписи на портале ФНС России личным сертификатом, изданным в УЦ ФНС России начиная с 28 июня 2016 г., возникает проблема с невозможностью выбора личного сертификата.
Необходимо выполнить проверку сертификата на валидность. Если при проверке сертификата возникает ошибка «Недостаточно информации для проверки этого сертификата», то данная ошибка означает, что в хранилище сертификатов Windows отсутствует корневой сертификат УЦ ФНС России, изданный 28 июня 2016 года.
По данному вопросу рекомендуем вам обращаться в техническую поддержку ФНС России для предоставления нового корневого сертификата УЦ ФНС России.
Полученный новый корневой сертификат УЦ ФНС России необходимо установить в хранилище Windows в доверенные корневые центры сертификации.
Не удается получить код регистрации через Интернет.
Не удается работать с внешним устройством, если на нем установлено сразу два апплета.
Если на вашем внешнем устройстве установлено сразу два апплета, ViPNet CSP распознает внешнее устройство, соответствующее лишь одному из этих апплетов. Работа сразу с двумя апплетами не поддерживается. Чтобы использовать в ViPNet CSP какой-либо определенный апплет из записанных на вашем токене, в главном окне ViPNet CSP на странице “Подключаемые устройства” отключите использование всех типов устройств, кроме требуемого.
Например, если на токене установлены апплеты JaCarta и JaCarta ГОСТ, ViPNet CSP по умолчанию распознает устройство типа JaCarta. Чтобы использовать ваш токен как устройство JaCarta ГОСТ, в программе ViPNet CSP отключите поддержку всех типов внешних устройств, кроме eToken GOST/JaCarta GOST.
Выполнение криптографических операций на внешнем устройстве семейства JCSD занимает длительное время.
При подключении внешнего устройства семейства JCSD к компьютеру под управлением ОС Windows Vista или Windows Server 2008 выполнение криптографических операций с использованием ключей, находящихся на таком устройстве, может занимать длительное время.
Для ускорения выполнения криптографических операций с использованием устройств JCSD рекомендуем обновить операционную систему.
Невозможно редактировать подписанный документ Microsoft Word или Excel.
Чтобы внести изменения в подписанный документ Microsoft Word или Excel, удалите электронную подпись и внесите необходимые изменения. После этого вы можете снова подписать документ.
Не удается подписать макрос или базу данных Microsoft Access 2007.
Если при попытке подписать макрос или создать подписанный пакет Microsoft Access 2007 в окне выбора сертификата электронной подписи нет доступных сертификатов, это значит, что вы не можете подписывать код. Обратитесь в удостоверяющий центр за сертификатом, который имеет атрибут «Подписывание кода» в расширенном использовании ключа.
Не найден закрытый ключ, соответствующий сертификату.
Если при выборе сертификата для подписания открывается окно ViPNet CSP – “Инициализация контейнера ключей”, это значит, что не найден закрытый ключ, соответствующий выбранному сертификату. Это может произойти в том случае, если контейнер ключей был удален в программе ViPNet CSP. Чтобы подписать документ выбранным сертификатом, в окне ViPNet CSP – “Инициализация контейнера ключей” укажите путь к контейнеру, который содержит закрытый ключ, соответствующий сертификату. Если вы не знаете местоположение контейнера ключей, использование выбранного сертификата невозможно.
Если в окне ViPNet CSP “Инициализация контейнера ключей” вы укажете путь к контейнеру ключей, этот контейнер будет добавлен в список в разделе “Контейнеры ключей” окна ViPNet CSP.
Ошибка проверки сертификата.
Проблемы при использовании устройства типа eToken Aladdin.
Если вы используете устройство типа eToken Aladdin, и при формировании запроса на сертификат ваш компьютер зависает, убедитесь, что установлено программное обеспечение eToken PKI Client 5.1 SP1.
Не удается установить или удалить программу.
Следуйте за нашими новостями в удобном для вас формате
Антивирусные продукты Dr.Web совместимы с ViPNet Client компании «ИнфоТеКС»
2 июня 2021 года
Программный комплекс ViPNet Client успешно протестирован на совместимость с антивирусными продуктами компании «Доктор Веб».
Компании «ИнфоТеКС» и «Доктор Веб» по итогам исследований выпустили cертификат о совместимости, который подтверждает корректную работу Dr.Web Desktop Security Suite (для Windows) версии 11.5 с ViPNet Client 4 версии 4.5.3, а также Dr.Web Desktop Security Suite (для UNIX) версии 11.1 с ViPNet Client 4U for Linux версии 4.10.
ViPNet Client 4 — программный комплекс, обеспечивающий защиту рабочих мест пользователей и безопасное удаленное подключение к внешним ресурсам, используя все преимущества технологии ViPNet VPN и отечественные алгоритмы ГОСТ.
«Технологическое партнерство, сложившееся межу нашими компаниями, дает возможность предлагать рынку обогащенные решения по защите информации. Совместная работа нашего VPN-клиента с антивирусными продуктами «Доктор Веб» предоставляет пользователям многоуровневую защиту рабочих станций, позволяет безопасно работать в сети Интернет, а также с удаленными и локальными ресурсами», — отметил Николай Смирнов, директор по развитию продуктов компании «ИнфоТеКС».
«В области информационной безопасности всё более востребованными становятся взаимно дополняющие друг друга решения, гарантированно совместимые между собой. И особенно ценно, когда каждый из таких продуктов имеет давнюю историю разработки и успешного применения. Совместимость продуктов Dr.Web и ViPNet Client — важный шаг на пути нашего многолетнего сотрудничества с ИнфоТеКС. VPN-сервисы призваны обеспечить безопасное подключение к сети, однако сами по себе они не защищают от угроз со стороны вредоносных программ, нежелательного и рекламного ПО, поэтому антивирус при работе с VPN необходим», — говорит руководитель направления технологических партнерств «Доктор Веб» Евгения Хамракулова.
Последствия перепрошивки
Координатор недоступен
«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.
3. Бонус
Failover подразумевает, что железок у вас две, и они работают вместе, представляясь как один кластер. Работа основана на VRRP плюс синхронизация криптосессий.
eth0 — это интерконнект между нодами кластера
192.168.2.2 — это IP-адрес второй ноды кластера
Обратите внимание на секцию [misc] и опцию «reboot = no». По умолчанию она установлена в yes, и если failover с первого раза не запустится, то вам придется переустанавливать ОС ПАК заново из образа. При этом в инструкции указано, что значение по умолчанию именно «no». Возможно, это уже пофиксили, но вы все равно имейте ввиду.
Проверяем, что и у вас и у партнера установлен одинаковый тип шифрования:
iplir set cipher-mode cfb
Еще из полезного, настройки модуля шифрования:
iplir show config
После всех импортов-экспортов тут должны быть ваши сети и сети партнера, между которым нужно настроить обмен. Ну и не забудьте правильно настроить маршрутизацию, чтобы трафик на узлы партнера заворачивался в координатор.
О компании «ИнфоТеКС»:
Компания ИнфоТеКС (АО «Информационные Технологии и Коммуникационные Системы») — российский разработчик и производитель высокотехнологичных программных и программно-аппаратных средств защиты информации.
В настоящее время портфель компании насчитывает более 50 продуктов для защиты информации. Флагманская разработка — технология ViPNet, гибкое VPN-решение для безопасной передачи данных в защищенной сети.
Центральный офис компании расположен в Москве, представительства открыты в 9-ти городах.
Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или ViPNet Coordinator HW (от «Инфотекса»)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.
Сразу оговорюсь, что мы поговорим о сертифицированной на сегодня ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х появилось много интересного, например, DGD (Dead Gateway Detection) и измененный механизм кластеризации, обеспечивающий практически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на ключевых командах и переменных, а подробное описание по этим «ключам» можно будет найти в документации.
Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.
В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.
Обработка прикладных протоколов (ALG)
На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:
- при использовании NAT должен быть включен ALG;
- при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
- при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
- ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.
Служебные порты и TCP-туннель
Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.
1. Ты помнишь, как все начиналось?
Защищенная сеть партнера построена на базе решения ViPNet от отечественного производителя — компании Инфотекс. До недавнего времени использовались индивидуальные клиенты ViPNet client с именными ключами. Однако сотрудников у нас много, а ключей — всего десять, больше партнер не дает. Как-то справлялись, но было жутко неудобно, поэтому решили ставить выделенный шлюз.
После переговоров с менеджером Инфотекса и специалистами партнера остановились на ПАК ViPNet Coordinator HW1000 на базе сервера Aquarius. Импортозамещение же Внутри этого ПАК — обычный debian-based линукс с собственным шеллом (можно выйти в bash) и установленным софтом ViPNet Coordinator (тестовую версию можно скачать в виде пакета).
Т.к. рынок таких решений крайне небольшой, то стандартизацией там и не пахнет. Ты должен купить железку у того же производителя, что и твой партнер, иначе ничего не получится. Отсюда и уровень сервиса — никаких тебе NBD (хотя стоимость поддержки далеко не копеечная), хотя саппорт отвечает довольно оперативно, стоит отметить, чего, порой, не скажешь о менеджерах.
Первым «открытием» после получения оборудования было то, что управляющий софт требует для своей работы 16-bit MS-DOS подсистему (!). Учитывая, что программ две («Центр Управления Сетью» и «Удостоверяющий и Ключевой Центр»), используют они общие папки (хотя в документации описано их разнесение на разные АРМ), то наименее геморройным вариантом стала установка виртуалки с Win2003 x32. 2015й год говорите? x86-64? Не, не слышали. Версия софта, поддерживающего 64-битные ОС, в настоящий момент проходит сертификацию органами — был ответ саппорта.
Инструкция пользователя подробна и многостранична, а описание готовых схем занимает едва ли полтора десятка страниц и наполовину состоит из рисунков. Если бы не помощь коллег, которые уже запускали подобные ПАК (Саша, спасибо!), то процесс только настройки и освоения документации затянулся бы, думаю, на месяц-другой. Сам же Инфотекс настоятельно рекомендует пройти пятидневные курсы (разумеется, платные, но относительно дешевые), либо воспользоваться услугами интегратора. Но мы ведь не ищем легких путей, правда? :) К слову, краткую инструкцию саппорт мне, все же, прислал.
(Un)split tunneling
Неинформативные конфиги
Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».
Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.
Невозможность работы GRE
Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:
Поэтому, если вы используете множественные GRE-подключения, необходимо избегать применения NAT к этим подключениям. В крайнем случае выполнять трансляцию 1:1 (правда, при использовании публичных адресов это достаточно непрактичное решение).
4. Через тернии — к звездам!
Итак, настройка завершена, но канал между нашим ПАК и сетью партнера не поднимается. И тут-то началось самое интересное.
Естественно, был заведен тикет в саппорте, были уточняющие вопросы, неоднократный сброс ПАК «в дефолт», перепроверка всех настроек, в т.ч. самим саппортом через удаленную сессию…
Через месяц стучания в бубен и копирования очередного файлика из одной папки в другую канал поднялся. Бинго? В общем, да, но осадочек-то остался немалый! Месяц, потраченный почти впустую, сотни писем в саппорт и администратору партнера, бесконечный обмен настройками (одна из фишек ViPNet — импорт-экспорт настроек между ПАК с ключевой информацией и настройками сетей) и письмо от руководства в сторону Инфотекс с предложением забрать глючную железку взад.
Были даже привлечены разработчики, ответ которых был, по-своему, гениален: «наверное, вы делали что-то не так». Ну разумеется, канал-то в итоге заработал. И работает до сих пор, тьфу-тьфу.
Коллеги подсказывают, что они мучались тоже с месяц, и оно, в итоге, «заработало само», когда подключилась техподдержка производителя.
Мистика, не иначе. А может, это, своего рода, посвящение — система покоряется только настойчивым.
В заключение хочу сказать, что не стремлюсь кого-то «полить грязью», просто описываю свой опыт. Особый диссонанс поначалу вызвала терминология, заточенная, как мне кажется, на специалистов ИБ, нежели на сетевиков: абонентские пункты, дистрибутивы ключей, коллективы пользователей, связи и прочее. Хотя, железо рассчитано на крупные компании, а в них, как правило, присутствуют айтишники-безопасники. С другой стороны, явная заточка под госструктуры (а кто еще в здравом уме будет пользовать ГОСТовское шифрование?) накладывает требования по локализации, ну а заодно и на терминологию, похоже.
Для удаления ViPNet в данном случае вам необходимо выполнить следующее:
- Выполнить запуск Операционной Системы в безопасном режиме(клавиша F8).
- Запустите редактор реестра: Пуск - Выполнить, укажите regedit.exe и нажмите ОК
- В реестре найдите слева ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal
- В этой ветке создайте раздел с названием MSIServer (путь должен получиться HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\MSIServer)
- Откройте этот раздел. Справа дважды щелкните по "(По умолчанию)"
- Введите значение service и нажмите на ОК.
- Запустите Пуск - Все выполнить , укажите services.msc и нажмите на ОК
- Найдите службу Установщик Windows, щелкните правой кнопкой и запустите ее.
- Теперь можно удалить ViPNet через Установку и удаление программ в Панели управления.
Некорректно удалилась предыдущая версия программы ViPNet
- Нажмите на Пуск -> Выполнить (или на клавиатуре Win+R)
- В появившемся окне введите regedit.exe и нажмите на ОК
- Открыть папку HKEY_LOCAL_MACHINE\Software\InfoTecs\Setup\Products
- Если в ней есть папка Infotecs-Client, переименовать ее в -Infotecs-Client(поставить вначале -)
- Если в ней есть папка Infotecs-Client, переименовать ее в -Infotecs-Client(поставить вначале -)
Недостаточно места на диске C
На диске C: должно быть не менее 10 ГБ свободного места. Удалите (перенесите) лишние файлы с этого диска и заного Установите ViPNet в программе обновления.
Отключена служба Брандмауэр Windows
При этом в логе C:\ProgramData\InfoTeCS\InstallerData\ViPNet Client\Logs\Setup.msi_XXX можно увидеть строчку вида
Failed to start service MpsSvc. Error code = 1058, (0x422) - Указанная служба не может быть запущена, поскольку она отключена или все связанные с ней устройства отключены.
- Откройте Пуск -> Панель управления -> (проверьте что справа-вверху стоит вид "Мелкие значки" или "Крупные значки") -> Администрирование
- Запустите Службы
- Найдите службу Брандмауэр Windows. Дважды кликните на ней, зайдя в свойства.
- В окне свойств убедитесь, что Тип запуска отличен от "Отключено". Если установлено "Отключено", выберите вариант "Автоматически" и нажмите на ОК.
- Попробуйте переустановить ViPNet
Проблемы с антивирусным ПО
Выключите антивирус полностью и попробуйте установить ViPNet снова, возможно потребуется удаление антивируса.
Отсутствуют обновления ОС
Работает только на лицензионной Windows!
Установите все последние обновления ОС
Проблемы с установкой драйвера ViPNet (что-то, вероятнее всего драйвера, блокирует изменение одной ветки реестра)
Также эту проблему (0x80070005) можно увидеть в логе C:\ProgramData\InfoTeCS\InstallerData\DrvInstall\InstallIpLirim.log :
2017/11/17 14:59:58 - Installing component "IplirLwf"
2017/11/17 15:00:01 - INetCfgClassSetup::Install successful
2017/11/17 15:00:01 - Successfully installed, apply the changes
2017/11/17 15:00:01 - Operation failed with error 0x80070005.Установку ViPNet необходимо производить в безопасном режиме с загрузкой сетевых драйверов (решение для Windows 7):
- Перезагрузитесь и в начале загрузки жмите много раз F8
- Выберите вариант загрузки Безопасный режим с загрузкой сетевых драйверов
- Загрузитесь до рабочего стола, ошибки Secret Net игнорируйте
- Запустите редактор реестра: Пуск - Выполнить, укажите regedit.exe и нажмите ОК
- В реестре найдите слева ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network
- В этой ветке создайте раздел ("папку") с названием MSIServer (путь должен получиться HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\MSIServer)
- Откройте этот раздел. Справа дважды щелкните по "(По умолчанию)"
- Введите значение service и нажмите на ОК.
- Запустите Пуск - Все выполнить , укажите services.msc и нажмите на ОК
- Найдите службу Установщик Windows, щелкните правой кнопкой и запустите ее.
- Запустите установку ViPNet снова.
Неверные настройка даты, времени и часового пояса.
Проверьте настройки даты и времени. Должно быть точное московское время. Максимальная допустимая раница 2 часа.Не запустилась служба ViPNet.
- Зайдите в ViPNet под администратором.
- Файл - Конфигурации - Отключить защиту.
- Файл - Конфигурации - Включить защиту.
- Проверьте доступность узлов.
Блокирует трафик от ViPNet клиента
- Проверьте наличие ПО, которое может блокировать трафик. Это может быть любой Firewall или Антивирус.
- Если вы используете прокси, то необходимо разрешить прохождение пакетов от ViPNet, добавить необходимы адреса в исключение.
- Попробуйте подключить ПК к другой сети. Если узлы стали доступны, то возможно трафик блокируется сетевым оборудованием.
Проблемы с ОС или сетевыми драйверами
- Попробуйте установить ViPNet с этой ключевой на другой ПК. Если все узлы доступны, то скорее всего проблема в ПК.
- Удалите ViPNet клиент, и полностью переустановить сетевые драйвера. Установите клиент повторно.
Проблемы с самой ключевой информацией
Ничего не помогло, вы ипользовали свежую ключевую, у вас в сети ничего не блокируется и на соседнем ПК все работает, а переустановка не помогает.
В данном случае потребуется переустановка ОС.
Проверьте наличие прокси. Необходимо добавить адрес системы в исключение.
Прокси нет, а в браузере вы видите ошибку DNS.
- В инструкции по установке ViPNet есть пункт настройка DNS. Выполните настройку DNS.
- Можно добавить адрес в файл host, в виде IP адрес DNS имя. В файле host есть примеры добавления.
- Зайдите в ViPNet под администратором.
- Сервис - Настройка приложения.
- Прикладные протоколы.
- Выберите протокол Передача файлов FTP и снимите галочку с tcp 21.
В данном случае велика вероятность того, что MFTP на данном узле сломан.
Для проверки на наличие ошибок необходимо сделать следующее:Для проверки доступа в сеть Интернет можно отключить ViPNet клиент. Для этого необходимо:
- Зайдите в ViPNet под администратором.
- Файл - Конфигурации - Отключить защиту.
Если при отключении защиты ViPNet, доступ в сеть Интернет есть, то фильтры открытой сети были настроены неверно или не настраивались. Необходимо настроить фильтры открытой сети на доступ в сеть Интернет.
Если при откллючении защиты ViPNet, Доступ в сеть Интернет не появился, значит проблема не связанна с клиентом ViPNet. Рекомендуется проверить сеть в организации и настройки сети на рабочем месте. Возможно стоит обновить сетевые драйвера.
Отключить обрабуотку прикладного протокола DNS.
- Зайти в режим администратора.
- Сервис.
- Настройка приложения.
- Прикладные протоколы.
- Двойной клик по строке "Система доменных имен (DNS)"
- Снять галочки с используемых портов и нажать ОК.
- Нажать кнопку применить.
Настройте фильтры открытой сети по инструкции.
Добавление фильтра открытой сети открывающего весь трафик.
Есть 2 способа устранить данную проблему.
- Переинициализировать ViPNet клиент свежей ключевой. Для получени нового файла ключевой информации ViPNet, необходимо сделать обращение в ГАУ РК ЦИТ. Пример обращения на получение ключевой информации можно найти ниже.
- Запросить обновления справочников и ключей. Для этого необходимо сделать обращение в ГАУ РК ЦИТ. Пример обращения на рассылку справочников и ключей можно найти ниже. Данный способ поможет устранить проблему только, если ваш ViPNet клиент обновлен до версии 4 и работает исправно.
О статусе письма можно узнать в справке приложения Деловая почта.
Не рекомендуется устанавливать ViPNet клиент и Континент АП на одно рабочее место. Это приведёт к конфликту между двумя программами и вы не сможете получить доступ к информационным системам.
Для получения доступа к системе СУФД через ViPNet, необходимо оформить обращение в ГАУ РК ЦИТ с просьбой открыть доступ и настроить рабочее место.
Необходимо будет настроить файл hosts. По умолчнию файл находится тут: "Системный диск:\Windows\System32\drivers\etc\ ". Файл hosts необходимо открыть в любом текстовом редакторе с правами администратора и добавить следующие строки:
10.136.7.36 s0700w03.ufk07.roskazna.local
10.136.7.36 sufd.s0700w03.ufk07.roskazna.local- Континент АП или иные клиенты VPN
- Антивирус Dr.Web
- Программные межсетевые экраны
В обращении необходимо указать следующую информацию:
- ID узла ViPNet клиента, ключевая которого вам нужна.
- ID узла ViPNet клиента, на Деловую почту которого вам будет направлена данная ключевая.
Можно указать список из ID узлов ViPNet.
Важно! Убедитесь в том, что вы указываете именно ID узла (в 3 версии ViPNet клиента Номер АП), а не ID пользователя. Они очень похожи друг на друга. У некоторых узлов эти значения могут быть одинаковыми. Инструкцию Как узнать ID узла? можно посмотреть тут.
Важно! Убедитесь в том, что узел, который вы указываете в качестве получателя может получить письмо по Деловой почте. Он должен быть рабочим, а узел ЦИТ_S_B_Сыктывк_Коммун-я 8;Core доступен.
Пример:
Просьба выслать ключевую информацию для узла *ID узла (1)* по Деловой почте на узел *ID узла (2)*.
В обращении необходимо указать следующую информацию:
- ID узла ViPNet клиента на который необходимо выслать обновления.
- Описать проблему. Рекомендуется приложить скриншот с ошибкой.
Важно! Узел, который вы указываете в качестве получателя может быть сломан, и обновления до узла не дойдут. В данном случае поможет только переинициализация ключей или переустановка клиента.
Пример:
Просьба выслать обновление справочников и ключей для узла *ID узла (1)* , так как Описание проблемы(2).
В обращении необходимо указать следующую информацию:
- ID узла ViPNet клиента которому необходимо открыть доступ.
- IP адрес, DNS имя и наименование системы, к которой необходимо открыть доступ.
Важно! Рекомендуется указывать как можно больше информации о системе. Если вы укажите только название информационной системы, есть вероятность того, что мы будем запрашивать у вас дополнительную информацию.
Важно! Мы можем открыть доступ только к системам, которые сопровождает ГАУ РК ЦИТ. Доступ к другим системам, например ФРДО, Промед или ТФОМС открывают администраторы соответствующих сетей. Со своей стороны ГАУ РК ЦИТ может только сделать связь между вашим узлом и узлом чужой сети, поэтому открытие доступа к таким системам может занять значительно больше времени.
Пример:
Просьба открыть доступ для узла *ID узла (1)* к Информация о системе(2).
Нешифрованный трафик вместо зашифрованного
Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:
- пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения – защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;
- с одной стороны взаимодействия отсутствуют связи. Например, вы связали два координатора, а справочники и ключи отправили только на один (или до второго они не дошли). В этом случае первый будет ждать зашифрованный трафик, но второй, так как не знает о существовании первого, будет присылать только незашифрованный;
- туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором «забываем» это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.
В заключение
Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности ViPNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом). А если вам не хочется погружаться во все сложности работы с ViPNet или это слишком трудозатратно, то всегда можно отдать управление вашей ViPNet-сетью в руки профессионалов.
Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»
Сразу оговорюсь, что описанной ниже истории никогда не случалось. Все совпадения случайны, все персонажи вымышлены.
В силу своей профессиональной деятельности, нам приходится работать с разными операторами связи. Практически все они — федерального уровня, либо их «дочки» в странах СНГ. Одной из таких компаний является… Пусть он будет Z.
История взаимоотношений с ним давняя и коллеги, наверное, расскажут много интересного. Но это как-нибудь потом, а пока расскажу свою историю я.
Требования к безопасности в этой компании серьезные — положение обязывает (А еще 152-ФЗ «О защите персональных данных»). Причем если раньше требования были драконовские (в духе «Миссия невыполнима»: изолированное помещение, сканер сетчатки, автоматчики. ), то сейчас свелись к просто строгим: индивидуальные учетки и шифрованные каналы связи между нами и заказчиком. Шифрование — ГОСТовское, никакого вамбуржуйскогозаграничного IPSec. Рынок таких решений мал, поставщиков — раз-два и кончились. Реализация… ну не Checkpoint и не Cisco, но терпимо.Но это была присказка, а за сказкой прошу под кат!
Не забываем про время
Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.
2. Поехали!
Начинается все с установки ПО администратора: Центр Управления Сетью (ЦУС), Удостоверяющий и Ключевой Центр (УКЦ) и ViPNet Client, которым мы будем проверять наш канал. Для работы потребуется лицензия (идет вместе с ПАК). Клиент пока не запускаем, нам для него еще ключи надо сделать. Файлик лицензии копируем в C:\Program files\InfoTecs\. Ребутаемся.
Запускаем ЦУС.
Интерфейс ЦУСПринимаем настройки по умолчанию. Открываем Службы -> адресная администрация -> Структура сети ViPNet.
Создаем сервер-маршрутизатор (СМ). В подавляющем большинстве случаев он понадобится один, даже если у вас кластерная конфигурация. В СМ создаем Абонентский Пункт (АП) admin.
Структура сети ViPNetТеперь проверяем:
Проверка конфигурации
Сформировать все справочникиС ЦУС пока закончили, запускаем наш УКЦ
Внешний вид УКЦПервичная настройка происходит с помощью незамысловатого мастера. Описывать каждую кнопку не буду, пробегусь кратко.
Пользователь которого назначаем админом сети — admin, параметры по умолчанию не меняем. Отмечаем галкой «создать ассиметричный мастер ключ»Задать пароль администратора для группы «Вся сеть» (в эту группу по умолчанию входят все сетевые узлы), который используется для входа в режим администратора на Сетевых Узлах (наших координаторах).
Созданные дистрибутивы будут отображены в УКЦ в разделе Ключевой центр > Своя сеть ViPNet > Ключи > Дистрибутивы ключей.После этого перезапускаем УКЦ — он спросит пароль. Вводим тот самый пароль администратора, который только что сгенерировали.
Маленькая ремарка: если при первой установке какой-то из паролей вы вдруг забыли, то проще всего будет перенастроить все заново (удалить ЦУС и УКЦ, удалить папку InfoTecs) — со второго-третьего раза настройка занимает минут пятнадцать и идет почти на автомат).
Формируем экспорт для сети нашего партнера.
В ЦУС: Службы -> Экспорт. Т.к. у нас пока ничего нет, добавляем сеть для экспорта (это доверенная сеть вашего партнера). Добавляем туда все наши СУ и все ТК. Жмем Копировать.
Полученные файлики нужно будет забрать в папке NCC\EXPORT, запихнуть в зашифрованный архив и передать администратору сети-партнера.
Принимаем импорт. Копируем содержимое архива в папку IMPORT, перезпускаем ЦУС. Службы -> необработанный импорт.Возвращаемся в УКЦ
Принимаем симметричный мастер-ключ (см. мануал по УКЦ) либо создаем свой — тут как договоритесь с партнером
Создаем ключи узлов (см. мануал по УКЦ)
Своя сеть -> Ключи -> Ключи узлов. На каждом узле ПКМ -> перенести в ЦУСЦУС
Сформировать все справочники, затем делаем повторный экспорт и отсылаем партнеру. Принимаем импорт.Готовим дистрибутивы ключей
УКЦ -> КЦ -> СУ -> Открыть. Задаем пароль администратора.
ЦУС -> Службы -> Файлы для… УКЦ -> Дистрибутивов. (копируем оба СУ: VPN1000 и admin)
УКЦ -> Сервис -> Автоматически создать -> Дистрибутивы ключейПереносим дистрибутивы (файлы *.dst) на съемный носитель (с помощью команды Перенести в папку в контекстном меню).
Копируем на этот же носитель пароли пользователей (меню Сервис > Сохранить пароли в файле > Пароли пользователей).Итак Номер вашей сети 1234
доверенная сеть 4321В сети номер 1234 делаем следующее:
— Делаем резервную копию (архив)
— Формируем начальный экспорт как описано в документации
— Задаем шлюз для меж сеть
— Копируем начальный экспорт
— Генерируем ИСММК для сети 4321 в УКЦ
— Делаем экспорт для сети 4321потом делаем следующее:
— Передаете начальный экспорт для сети 4321
— копируете начальный экспорт из сети 1234 в папки имопрта ЦУС и УКЦ сети 4321.Теперь перейдем в сеть 4321:
— Делаем резервную копию (архив)
— Подключаем межсетевой канал
— Установить связи между ТК 2-х сетей 1234 и 4321
— Сформировать ответный экспорт для сети 1234
— Не забыть задать СМ_шлюз и скопировать ответный экспорт
— Так же не забыть проверить наличии аномальных ситуаций.
— Сформировать справочники
— Импортировать список сертификатов ЭЦП администраторов сети 1234 в УКЦ сети 4321
— Импорт ИСММК из сети 1234
— Сформировать новые КУ в ЦУС и перенести их в ЦУС
— Разослать обновления из ЦУСТеперь перейдем к следующему этапу:
— Передать ответный экспорт для сети 1234. И далее все действия будет выполнять там.
— Провести импорт ответного экспорта в ЦУС и УКЦ и создать и создать заключительный экспорт.
— Подключить межсетевой канал. в ЦУС
— Посмотреть и проверить есть ли связь между ТК двух сетей 1234 и 4321.
— Проверить имеются ли аномалии
— Сформировать справочники.
— Сделать импорт списка сертификатов ЭП УЛ второй сети в УКЦ первой сети.
— Сформировать новые ключи узлов и перенести в ЦУС
— Рассослать обновления КУ и адресных справочников из ЦУС.
— Еще раз проверить правильность выполнения процедуры установки межсетевого взаимодействия
— Импортировать заключительный экспорт сети 4321Конверт не доставлен
Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.
Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.
Замена координатора
Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.
Пересечения адресов
В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.
Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.
Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.
Кластеризация и сбой ноды
Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.
При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.
В кластерном исполнении существует две распространенные проблемы: циклическая перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтобы понять суть этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, если за отведенное время пакетов нет, отправляет пинг на testip. Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.
Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.
Читайте также: