Vipnet coordinator linux 4 х не может выполнять трансляцию адресов nat следующего типа

Обновлено: 05.07.2024

Доступ в VipNet сеть с другого ПК - Форум по вопросам информационной безопасности

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

Как возможно настроить доступ к виртуальным IP-адресам сети VipNet c другого ПК (без ВипНета) в локальной сети.

Я прописал на этом ПК в качестве шлюза IP випнетовского ПК. Трафик идет, а вот в виртуальную сеть Випнета попасть не могу.

Приветствую!
Виртуальная сеть ViPNet - то, ради чего, собственно, требуется ПО ViPNet. Трафик в этой сети подвергнут криптографическим преобразованиям. Из открытой сети (без ViPNet и соответствующих ключей доступа - dst-файлов и сертификатов) в нее попасть нельзя.
Чтобы "пустить" открытые машины к ресурсу, находящемуся в виртуальной сети, существуют два пути: либо на каждую машину ставить ПО ViPNet и просить у администратора виртуальной сети нужные ключевые файлы, либо поставить аппаратный координатор ViPNet, к которому уже подключить открытые машины. Тогда координатор будет отвечать за маршрутизацию и шифр./дешифр. сетевого трафика в/из виртуальной сети относительно открытых машин.

oko
Речь идет о том, что открытый трафик приходит на координатор (программный) и дальше попадает по определенному адресу в виртуальной сети VipNet.
Т.е. компьютер випнет - это шлюзовой пк.

Я видел такую настройку, но повторить её не могу.

Т.е. вы из обычной машины с ПО ViPNet Client хотите шлюз-координатор сделать?
Тогда сложность в трансляции адресов и настройках межсетевого экрана. Если на машине установлено ПО ViPNet-координатор, то там есть секция правил NAT для виртуальной (защищенной) и открытой (незащищенной) сетей. Если же ПО ViPNet-Client, то навряд ли у вас это простыми средствами получится. Скорее придется делать NAT средствами Винды (без брандмауэра) и дальше ковырять правила открытого и защищенного трафика уже в ViPNet.

Действительно шлюз-координатор.
Действительно ПО ViPNet-координатор.

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

Осталось сделать туннелирование между открытой и закрытой сетью, и тут лажа:
кнопка IP-адрес в окне Фильтры для туннелирования - не активна.
Вот хоть тресни, а не активна. не пойму почему.
Я ведь несколько лет назад по инструкции настраивал такую штуку (но забыл все напрочь) и помню что кнопка должна работать.

Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или 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 требуют обоих типов связи.

Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.

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

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

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

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

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

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

Неинформативные конфиги

Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».

Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.

(Un)split tunneling

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

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

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

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

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

Именно для таких случаев в продуктах 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 для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.

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

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

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

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

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

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

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

пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения – защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;
с одной стороны взаимодействия отсутствуют связи. Например, вы связали два координатора, а справочники и ключи отправили только на один (или до второго они не дошли). В этом случае первый будет ждать зашифрованный трафик, но второй, так как не знает о существовании первого, будет присылать только незашифрованный;
туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором «забываем» это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.

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

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

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

В заключение

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

Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»

1.1 Настройка параметров работы через Firewall, осуществляющие преобразование адресов (NAT) Если узел с ПО ViPNet работает во внутренней сети с внутренними IP-адресами и на входе этой сети установлен Firewall или другое устройство, осуществляющее NAT, и если в локальной сети нет ViPNet-координатора, то в Мониторе требуется произвести некоторые настройки. Поскольку ПО ViPNet при работе через внешние сети осуществляет преобразование любого типа IP-пакетов в IP-пакеты с протоколом UDP, то организация их прохождения через устройства NAT не вызывает каких-либо сложностей. Может быть два типа Firewall: • Firewall (или устройство) со статическим NAT (см. п.1.1.1), • Firewall (или устройство) с динамическим NAT (см. п.1.1.2). Напомним, если есть ViPNet-координатор, установленный во внутренней сети, то на АП следует настроить работу через этот ViPNet-координатор (т.е. в поле Тип Firewall следует выбрать ViPNet-координатор (см. п.13.3, стр.126)), а настройки через Firewall (со статическим NAT или с динамическим NAT) произвести на координаторе. 1.1.1 Настройка параметров работы через Firewall, внешний IP-адрес которого известен и не меняется в процессе работы (тип Firewall "Со статическим NAT") На таком Firewall доступна настройка статических правил NAT. IP-адрес Вашего АП и порт доступа к нему, жестко заданы на Firewall.

Настройки на Firewall Для пропуска пакетов на Firewall (или устройстве с NAT), на котором можно настроить статические правила NAT, должен быть обеспечен: • Пропуск исходящих UDP-пакетов с IP-адресом и портом Вашего узла (Source-порт) на любой внешний адрес и порт (с подменой адреса источника на свой адрес). • Пропуск и перенаправление входящих UDP-пакетов с портом Вашего узла (Destination-порт) на IP-адрес Вашего узла.

На АП настройки работы через Firewall Со статическим NAT требуется производить, если в локальной сети нет ViPNet-координатора. В этом случае на каждом из абонентских пунктов должен быть выбран тип Firewall Со статическим NAT и произведена настройка маршрутизации на этот Firewall. При этом на каждом узле должен быть назначен свой порт доступа. А именно: Для настройки работы через Firewall, в окне Защищенная сеть дважды щелкните левой кнопкой мыши на собственной записи (имени Вашего АП). Откроется окно Настройки. В это окно можно также попасть, просто выбрав окно Настройки. Поставьте "галочку" в опции Использовать межсетевой экран (Firewall) и в нижней части появится дополнительное окно Параметры работы через Firewall (Рисунок 79). Далее в поле Тип Firewall необходимо выбрать значение Со статическим NAT (Рисунок 79), а также если требуется настроить: • Порт UDP (по умолчанию 55777) – параметр определяет номер порта, от которого преобразованные ПО ViPNet в UDP-формат пакеты уходят с Вашего узла (Source-порт), и на который такие пакеты приходят на Ваш узел (Destination-порт). Номер порта имеет смысл изменять, только если внутри Вашей сети через один Firewall (или устройство с NAT) работает несколько узлов с ПО ViPNet. В этом случае у всех таких узлов номера портов должны быть разные. • Опцию Зафиксировать внешний IP-адрес и порт доступа UDP через Firewall и поле Внешний IP-адрес Firewall настроить в зависимости от следующих ситуаций:  Если на внешнем Firewall с NAT есть возможность настроить статические правила только для входящих пакетов, предназначенных Вашему узлу, то есть обеспечить пропуск пакетов, имеющих адрес и порт назначения, указанных в соответствующих полях данного окна, а также их перенаправление на адрес Вашего узла, то опцию Зафиксировать внешний IP-адрес и порт доступа UDP через Firewall следует включить (поставить "галочку"). В этом случае в полях Внешний IP-адрес Firewall и Порт UDP необходимо указать внешний адрес Firewall и порт, на которые должны поступать пакеты для Вашего узла.  Если правила на внешнем Firewall с NAT настроены и для исходящих пакетов Вашего узла, и порт источника пакета при прохождении через Firewall не подменяется, то опция Зафиксировать внешний IP-адрес и порт доступа UDP через Firewall может быть выключена. В этом случае на других узлах параметры доступа к Вашему узлу будут регистрироваться по внешним параметрам пакета и внешний адрес Firewall также определится в процессе работы.

По завершении всех действий нажмите Применить.

Информация об IP-адресе Firewall и порте доступа сообщается программой через сервер IP-адресов всем остальным узлам, с которыми связан Ваш АП. 1.1.2 Настройка параметров работы через Firewall, где внешний IP-адрес и порт доступа заранее не известны и (или) могут меняться в процессе работы (тип Firewall "С динамическим NAT") Назначение режима работы с использованием типа Firewall "С динамическим NAT" и технология работы в этом режиме. Режим работы с использованием типа Firewall С динамическим NAT наиболее универсален и может использоваться практически во всех случаях. Однако основное его назначение – обеспечить надежную двустороннюю связь с узлами, работающими через устройства NAT, на которых настройка статических правил NAT затруднена или невозможна. Такая ситуация типична для простых устройств NAT с минимумом настроек, например, DSL-модемов, Wireless-устройств, а также при использовании технологии общего доступа Microsoft через компьютер, подключенный к Интернет по удаленному соединению и в других случаях. Затруднительно также произвести настройки на устройствах NAT, установленных у провайдера (в домашних сетях Home network, GPRS и других сетях, где провайдер предоставляет частный IP-адрес). Опишем кратко технологию пропуска трафика такими устройствами с NAT: Все устройства NAT обеспечивают пропуск UDP-трафика в режиме автоматического создания так называемых динамических правил NAT. То есть пропускаются любые исходящие пакеты с подменой адреса и порта, фиксируются их параметры, и на основании этих параметров создаются динамические правила пропуска для входящего трафика. В течение определенного промежутка времени (таймаута) пропускаются входящие пакеты, параметры которых соответствуют созданным правилам. По завершении данного промежутка времени после прохождения последнего исходящего пакета, соответствующие динамические правила удаляются, и входящие пакеты начинают блокироваться. То есть инициативное соединение извне с узлами, работающими через такие устройства NAT, невозможно, если не будет соответствующего исходящего трафика.

После выполнения всех настроек, необходимо проверить соединение с сервером, для этого необходимо в окне «Защищенная сеть» выбрать SM Profi-plus, Samara и проверить соединение

Компания Русь Телеком предлагает полный перечень программно-аппаратных продуктов ViPNet, а так же их установку, настройку и подключение к необходимым информационным системам. В соответствии с письмом Федеральной службы в сфере образования и науки от «03» февраля 2017 г. № 10-52 (Приложение №2), ООО «Русь Телеком», предлагает Вам выполнить обновление средств криптографической защиты информации семейства ViPNet из сети №2458 до версии 4.х, продления сертификатов технической поддержки производителей сертифицированных средств защиты информации, проведения аттестации по требованиям безопасности информации.

Создание защищенной, доверенной инфраструктуры передачи информации ограниченного доступа с использованием публичных и выделенных каналов связи
Развертывание инфраструктуры открытых ключей (PKI) с организацией Удостоверяющего центра с целью использования механизмов электронной подписи в прикладном программном обеспечении заказчика

подключиться к ГИС, ФИС (ФИС ГИА и Приема, ФИС ФРДО, ЕГИС ОТБ и мн др.)
Обеспечить безопасную передачу информации в соответствии с криптоалгоритмами ГОСТ РФ
Соответствовать требованиям ФЗ РФ №152 “О защите персональных данных”

Программные комплексы ViPNet

ViPNet Client

ViPNet Coordinator

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

ViPNet Administrator

ViPNet Administrator — это основной программный комплекс, предназначенный для настройки и управления защищенной сетью, включающий в себя: ViPNet NCC (Центр управления сетью, ЦУС) — программное обеспечение, предназначенное для конфигурирования и управления виртуальной защищенной сетью ViPNet. ViPNet KC & CA (Удостоверяющий и ключевой центр, УКЦ) — программное обеспечение, которое выполняет функции центра формирования ключей шифрования и персональных ключей пользователей — Ключевого центра, а также функции Удостоверяющего центра.

Программно-аппаратные комплексы ViPNet

ViPNet Coordinator HW100

ViPNet Coordinator HW 100 компактный криптошлюз и межсетевой экран с пропускной способностью до 100 Мбит/сек, построенный на базе ПО ViPNet Coordinator Linux. Выполняет в ViPNet-сети функции ПО ViPNet Coordinator, включая функцию VPN-сервера для доступа удаленных VPN-клиентов, оснащенных ПО ViPNet Client. Надежно защищает передаваемую информацию от несанкционированного доступа и подмены. Flash-диск обеспечивает высокую скорость работы и защиту от механического износа.

ViPNet Coordinator HW1000

ViPNet Coordinator HW1000 это криптошлюз и межсетевой экран с пропускной способностью до 950 Мбит/сек, построенный на аппаратной платформе телекоммуникационных серверов компании «Аквариус» - AquaServer. Построен на базе ПО ViPNet Coordinator Linux. Выполняет в ViPNet-сети функции ПО ViPNet Coordinator, включая функцию VPN-сервера для доступа удаленных VPN-клиентов, оснащенных ПО ViPNet Client. Надежно защищает передаваемую информацию от несанкционированного доступа и подмены.

ViPNet Coordinator HW2000

ViPNet Coordinator HW2000 это криптошлюз и межсетевой экран с пропускной способностью до 2.7 Gb/s, построенный на аппаратной платформе телекоммуникационных серверов компании «Аквариус» - AquaServer. Построен на базе ПО ViPNet Coordinator Linux. Выполняет в ViPNet-сети функции ПО ViPNet Coordinator, включая функцию VPN-сервера для доступа удаленных VPN-клиентов, оснащенных ПО ViPNet Client. Надежно защищает передаваемую информацию от несанкционированного доступа и подмены.

Все средства имеют необходимые сертификаты соответствия ФСБ РФ требованиям к средствам криптографической защиты информации, требованиям к средствам межсетевого экранирования, а также ФСТЭК РФ требованиям к отсутствию не декларированных возможностей, требованиям безопасности информации автоматизированных систем и информационных систем персональных данных.

Читайте также: