ТП Инфотекс

Введение

Настоящие правила распространяются на аппаратные платформы из состава ПАК ViPNet (далее — оборудование) производства компании «ИнфоТеКС» и регламентируют порядок действий, сроки, а также иные аспекты, связанные с осуществлением гарантийного и постгарантийного обслуживания.

(un)split tunneling

Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»).

Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям.

Причем, согласно концепции вендора, в первом случае координатор должен либо туннелировать прокси-сервер, либо сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в любой конфигурации.

1.Порядок приема оборудования на гарантийное обслуживание

Заказчик или Поставщик обращается в службу технической поддержки Производителя для проведения удаленной диагностики оборудования. Данному обращению присваивается уникальный номер, который в будущем является идентификатором обращения.

Удаленная диагностика осуществляется в срок до 3 рабочих дней с момента получения обращения.

В случае положительного заключения о возможной неисправности оборудования служба технической поддержки предложит предоставить заполненный пользователем ПАКа Акт неисправности оборудования и передаст решение проблемы в Сервисный центр Производителя. Форма Акта неисправности приведена в Приложении № 1.

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

На этапе диагностики характера неисправности определяется: гарантийный случай или нет.

Сроки диагностики характера неисправности в Сервисном центре составляют до 5 рабочих дней с момента получения Производителем Оборудования.

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

Ремонт осуществляется в согласованные с Заказчиком сроки. Максимально возможный срок гарантийного ремонта составляет 45 рабочих дней.

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

2.Порядок выдачи оборудования из ремонта

В случае невозможности ремонта Заказчику по согласованию с ним выдается аналогичное оборудование, за исключением случаев, не признанных гарантийными.

Правила гарантийного обслуживания

На всё оборудование, поставляемое в составе ПАК ViPNet, устанавливается гарантийный срок 1 (один) год с момент продажи.

Гарантийное обслуживание может осуществляться:

Гарантийное обслуживание производится в сервисном центре АО «ИнфоТеКС».

В рамках гарантийного обслуживанияПроизводитель принимает обращения как от Поставщиков ПАК, так и от Заказчиков. Заказчик с запросом на услуги гарантийного обслуживания может обращаться как к своему Поставщику, который передает заявку на рассмотрение и обработку Производителю, так и напрямую к Производителю.

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

Возврат оборудования из Сервисного центра осуществляется за счёт Производителя.

На период ремонта Производитель не предоставляет Заказчику оборудования на замену находящемуся на ремонте.

Правила постгарантийного обслуживания

При наступлении негарантийного случаяПроизводитель по согласованию с Заказчиком (Покупателем, Пользователем) осуществляет постгарантийное обслуживание оборудования.

Производитель извещает Заказчика или Поставщика о стоимости постгарантийного обслуживания оборудования соответствующим письмом/актом с предложением заключить договор на постгарантийное обслуживание, либо по средствам выставления счета..

Оплата лицом, обратившимся за постгарантийным обслуживанием, счета, выставленного Производителем, признается согласием этого лица с условиями постгарантийного обслуживания (конклюдентным действием). В этом случае, ремонт осуществляется в срок, не превышающий 45 рабочих дней с момента полной оплаты счета.

Если Производителем счет на оплату не выставлялся, Производитель осуществляет постгарантийное обслуживание оборудования только после подписания с Заказчиком/Поставщиком отдельного соглашения/договора на постгарантийное обслуживание, в котором регламентируются условия и сроки постгарантийного обслуживания.

После ремонта оборудования на него устанавливается гарантийный срок 6 месяцев в части проведенных работ.

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

АО «ИнфоТеКС» вправе не осуществлять постгарантийное обслуживание, если обратившееся за ним лицо, имеет задолженность или неисполненные обязательства перед АО «ИнфоТеКС».

Ограничения и особые условия

Поставщик не несет ответственности за дефекты и неисправности оборудования, происшедшее с ним в результате:

• ненадлежащих условий эксплуатации: некачественная питающая сеть, короткое замыкание, перегрузки, наличие механических, тепловых и электрических повреждений, замятые контакты, трещины, сколы, следы ударов, полное или частичное изменение форм аппаратной части;
• несоблюдения правил транспортировки и условий хранения, технических требований по размещению и эксплуатации оборудования;
• действий Покупателя и/или Пользователя, связанных с использованием оборудования не по назначению;
• при возникновении форс-мажорных обстоятельств (пожаров, наводнений и т. д.)

Гарантия не распространяется:

• На любые изделия, которым причинен ущерб в результате работы в сопряжении с данным изделием. (ПАК ViPNet);
• самостоятельно произведенный ремонт оборудования или замена штатных узлов и деталей.

Производитель не несет ответственности за прямые или косвенные убытки Заказчика и/или Поставщика, связанные с потерей информации или временным выходом из строя и ремонтом оборудования.

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

Гарантийное обслуживание не включает в себя:

Приложение № 1

5 обновление сертификата vipnet client – ассоциация учителей информатики

Vipnet client 4 | сетевые экраны, виртуальные частные сети, шифрование, безопасные коммуникации | инфотекс

Vipnet coordinator 4 | сетевые экраны, виртуальные частные сети, шифрование | инфотекс

Vipnet coordinator ig | сетевые экраны, виртуальные частные сети, шифрование | инфотекс

Випнет и криптопро на одном устройстве

Для выполнения определённых рабочих задач потребуется совместимость с отечественными ПО или возможность использования электронной подписи, которая находится на облачном сервисе. В этом плане возможности ViPNet CSP 4 ограничены. Такие задачи решает продукция компании КриптоПро. Криптопровайдер КриптоПро CSP и программу КриптоАРМ можно купить в нашем интернет-магазине.

Вопросы и ответы по продукту vipnet coordinator hw

Вопросы и ответы по продукту vipnet tls gateway

Замена координатора

Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью).

Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.

Кластеризация и сбой ноды

Горячий резерв – это 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 и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.

Конверт не доставлен

Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между координаторами (то есть не напрямую по защищенному каналу).

Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.

Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.

Координатор недоступен

«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем.

Купить thc-119-2000-4.x-p2 сертификат активации сервиса прямой технической поддержки пак vipnet coordinator hw2000 4.x на срок 1 год, уровень – премиальный по лучшей цене

Купить tsc-99-4.x-p2 сертификат активации сервиса прямой технической поддержки по vipnet statewatcher 4.x на срок 1 год, уровень – премиальный по лучшей цене

Настройка скзи

Для настройки и регистрации СКЗИ VipNet CSP 4 необходимо:

1. Найти скачанный файл, для этого перейти в меню «Пуск», «Все программы», «ViPNet», «ViPNet CSP»;
2. В открывшемся окне выбрать пункт «Зарегистрировать ViPNet CSP» и нажать «Далее»;
3. В следующем окне выбрать пункт «Запрос на регистрацию (получить код регистрации)» и нажать «Далее»;
4. В окне «Способ запроса на регистрацию» выбрать пункт «Через Интернет (online)» и нажать «Далее». При выполнении операции компьютер должен быть подключен к сети Интернет;
5. В окне «Регистрация ViPNet CSP» заполнить все поля и ввести полученный серийный номер. Нажать «Далее»;
6. После успешной регистрации нажать «Готово».

Не забываем про время

Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir.

Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.

Невозможность работы gre

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT.

Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:

Поэтому, если вы используете множественные GRE-подключения, необходимо избегать применения NAT к этим подключениям. В крайнем случае выполнять трансляцию 1:1 (правда, при использовании публичных адресов это достаточно непрактичное решение).

Нешифрованный трафик вместо зашифрованного

Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:

Обработка прикладных протоколов (alg)

На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса.

Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:

Управляется модуль командами группы «alg module» из привилегированного режима (enable).

Обязательства исполнителя

При оказании услуг по технической поддержке ПОЛЬЗОВАТЕЛЕЙ ИСПОЛНИТЕЛЬ обязуется:

• иметь действующую лицензию ФСБ России, позволяющую осуществлять техническое обслуживание шифровальных (криптографических) средств;
• обеспечивать предоставление услуг по технической поддержке ПОЛЬЗОВАТЕЛЕЙ с надлежащим качеством и в соответствии с установленными в настоящих условиях сроками;
• обеспечивать регистрацию всех ОБРАЩЕНИЙ ПОЛЬЗОВАТЕЛЯ в службу технической поддержки ИСПОЛНИТЕЛЯ;
• предоставить информацию о версии ПРОДУКТА, решающего проблему ПОЛЬЗОВАТЕЛЯ, либо предоставить информацию о планируемых сроках выхода новой версии ПРОДУКТА, решающего проблему ПОЛЬЗОВАТЕЛЯ, либо при невозможности использования новой версии ПРОДУКТАПОЛЬЗОВАТЕЛЕМ, предоставить информацию о возможном обходном решении (workaround) проблемы ПОЛЬЗОВАТЕЛЯ, если таковое имеется;
• предоставлять ПОЛЬЗОВАТЕЛЮ исчерпывающую информацию о ходе решения зарегистрированного ОБРАЩЕНИЯ.

Обязательства пользователя

Пользователь обязуется:

• устанавливать и использовать ПРОДУКТ в соответствии с эксплуатационной документацией; 
• при обращении в службу технической поддержки ИСПОЛНИТЕЛЯ идентифицировать себя, отвечая на соответствующие вопросы сотрудника службы технической поддержки, и предоставлять информацию о наличии действующего СЕРТИФИКАТА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ;
• при обращении в службу технической поддержки ИСПОЛНИТЕЛЯ предоставлять информацию, максимально полно описывающую возникшую проблему;
• предоставлять по запросу сотрудника службы технической поддержки ИСПОЛНИТЕЛЯ дополнительно запрашиваемую информацию (схемы, лог-файлы, конфигурации и т. п. информацию); 
• следовать рекомендациям службы технической поддержки ИСПОЛНИТЕЛЯ. 

Ограничения в предоставлении услуг технической поддержки

Техническая поддержка предоставляется только по ПРОДУКТАМ, используемым в строгом соответствии с требованиями эксплуатационной документации, в рекомендованных Производителем операционных системах, устройствах и программно-аппаратных комплексах. 

ПОЛЬЗОВАТЕЛЯМ, использующим неактуальные версии ПРОДУКТОВ, предоставляются известные решения проблем и существующие исправления или рекомендации в проведении обновления на актуальные версии ПРОДУКТОВ при наличии действующего СЕРТИФИКАТА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ.

В случае выявления сотрудниками службы технической поддержки ИСПОЛНИТЕЛЯ факта использования ПРОДУКТОВ с несоблюдением правил и требований эксплуатации ПРОДУКТОВ, рекомендованных Производителем, ПОЛЬЗОВАТЕЛЮ может быть отказано в предоставлении услуг технической поддержки.

В случае, когда ПОЛЬЗОВАТЕЛЬ не может предоставить информацию о действующем СЕРТИФИКАТЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ, специалисты службы технической поддержки ИСПОЛНИТЕЛЯ вправе отказать ПОЛЬЗОВАТЕЛЮ в предоставлении услуг технической поддержки.

Общение ПОЛЬЗОВАТЕЛЯ и сотрудников службы технической поддержки ИСПОЛНИТЕЛЯ должно соответствовать общепринятым нормам делового этикета и переписки, категорически не допускаются оскорбления и нецензурные выражения.

Пересечения адресов

В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов.

Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual».

Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия.

Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС.

Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ.

Последствия перепрошивки

Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка «unsupported hardware», которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI.

Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный «кирпич». С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD.

Чтобы не гадать, в чем конкретно проблема, можно обратиться к флешке, с которой производится прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей.

Например, ошибка cpu::Vendor(#3)==’GenuineIntel’ 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

Предоставление услуг технической поддержки

ВРЕМЯ РЕАКЦИИ на ОБРАЩЕНИЕ ПОЛЬЗОВАТЕЛЯ определяется уровнем критичности ИНЦИДЕНТА, присвоенным при регистрации ОБРАЩЕНИЯв службе технической поддержки ИСПОЛНИТЕЛЯ, а также видом СЕРТИФИКАТА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ.

Если в ОБРАЩЕНИИ ПОЛЬЗОВАТЕЛЯ содержится информация о совокупности ИНЦИДЕНТОВ, то каждый ИНЦИДЕНТ регистрируется в службе технической поддержки ИСПОЛНИТЕЛЯ с присвоением своего уникального номера для идентификации и с присвоением своего уровня критичности ИНЦИДЕНТА.

Если в ходе разрешения ИНЦИДЕНТА службой технической поддержки ИСПОЛНИТЕЛЯ выясняется, что проблема связана с продуктами сторонних производителей, то ПОЛЬЗОВАТЕЛЮ рекомендуется обратиться в службу технической поддержки стороннего производителя.

При отсутствии в течение 7-и (семи) рабочих дней со стороны ПОЛЬЗОВАТЕЛЯ реакции на предложенные службой технической поддержки ИСПОЛНИТЕЛЯ способ разрешения ИНЦИДЕНТА, рекомендации или реакции на запрос дополнительной информации по ОБРАЩЕНИЮ данное ОБРАЩЕНИЕ считается неактуальным и работа над этим ОБРАЩЕНИЕМ заканчивается, ОБРАЩЕНИЕ считается закрытым, о чем ПОЛЬЗОВАТЕЛЬуведомляется соответствующим извещением (по телефону или электронной почте).

В случае поступления от ПОЛЬЗОВАТЕЛЯ информации по закрытому ОБРАЩЕНИЮ по прошествии 7-и (семи) дней такое ОБРАЩЕНИЕ регистрируется как новое ОБРАЩЕНИЕ в службу технической поддержки ИСПОЛНИТЕЛЯ.

Сертификаты соответствия

Служебные порты и 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-пакетов, как будто его вовсе нет.

Термины и определения

Производитель

 — АО «ИнфоТеКС».

Заказчик (Покупатель, Пользователь)

 — конечный пользователь ПАК ViPNet производства АО «ИнфоТеКС».

Поставщик

 — авторизованный партнёр компании АО «ИнфоТеКС», осуществивший поставку ПАК ViPNet Заказчику (под Поставщиком может подразумеваться АО «ИнфоТеКС» в тех случаях, когда поставка Заказчику осуществляется напрямую без посредников).

Гарантийный срок

 — срок, в течение которого производится гарантийное обслуживание оборудования в составе ПАК ViPNet.

Гарантийное обслуживание

 — осмотр, диагностика неполадок/неисправности или ремонт (в случае невозможности или экономической нецелесообразности ремонта замена на аналогичное) оборудования, производимые Производителем за свой счет при наступлении гарантийного случая.

Гарантийный случай

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

Постгарантийное обслуживание

 — ремонт (или в случае невозможности или экономической нецелесообразности ремонта замена на аналогичное оборудование или списание) оборудования Заказчика, производимый Производителем за счет Покупателя или Пользователя, при наступлении негарантийного случая.

Негарантийный случай

 — выход из строя оборудования в результате:

Удаление скзи

Перед удалением СКЗИ нужно сделать резервную копию контейнеров закрытых ключей.

1. Для удаления криптопровайдера необходимо перейти в «Пуск», «Панель управления», «Программы и компоненты» или «Установка и удаление программ». В списке установленных программ найти «VipNet CSP», нажать правой кнопкой мыши на строку «VipNet CSP» и выбрать пункт «Удалить»;
2. Далее произойдёт удаление криптопровайдера, после которого необходимо перезагрузить компьютер.
3. После удаления нужно очистить реестр от записей, принадлежащих программе.

Установка сертификатов

Для установки сертификатов необходимо выполнить следующие шаги:

1. Дважды кликнуть левой кнопкой мыши по ярлыку программы. В открывшемся окне «Настройка ViPNet CSP» перейти в «Контейнеры ключей»;
2. Программа автоматически найдёт созданные ранее контейнеры. Нажать кнопку «Добавить контейнер», если необходимого нет в списке. В открывшемся окне указать контейнер закрытого ключа. Нажать «Обзор», выбрать необходимый ключ и нажать «ОК».
3. Далее пользователю необходимо установить сертификат из контейнера в системное хранилище «Личные сертификаты». Для этого надлежит выделить контейнер в списке и нажать «Свойства»;
4. В открывшемся окне выбрать «Открыть»;
5. Пройти шаги мастера установки сертификата, нажимая кнопки «Установить сертификат», «Далее», «Далее» и «Готово».

В заключение

Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности ViPNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом).