Vipnet coordinator hw1000 руководство администратора - Большая энциклопедия инструкций и руководств

Решил написать общую инструкцию по настройке координатора vipnet hw1000 с 4-ой версией прошивки. Будет исходить из того, что на координаторе будет использоваться два порта — первый внешняя сеть, второй внутренняя сеть.

Перед выездом к месту установки координатора, заблаговременно, необходимо получить или запросить следующее:

ip-адрес, маску сети и шлюз внешней сети (eth0);
ip-адрес и маску сети внутренней сети (eth1);
DST-файл с паролем для координатора (в нем должны зашиваться указанные выше IP-адреса) – необходимо сбросить на USB Flash Disk с файловой системой FAT32.

По хорошему стоит иметь подготовленную флэшку с прошивкой 3-ей и 4-ой версии, если координатор не обновлялся давно, тогда пароль администратора сети может не подойти, но если там никакие ключе не были установлены, тогда всё в порядке.

Пароль от координатора лучше записать на бумажке.

Подключаем монитор и клавиатуру к координатору. Включаем его.
Ждем запуска.
Вводим логин user.
Вводим пароль от координатора. Пароль от DST-файла. Пароль вводится, но не отображается.
Вводим команду Enable. В конце строки для ввода должен появится символ #.
Вводим пароль администратора ViPNet. Его нужно узнать у администратора вашей сети ViPNet или посмотреть к ключевом центре ViPNet. Сообщение «Admin login failed due to wrong password», значит пароль введён неверно.
Вводим команду Admin Remove Keys.
Вводим Yes (именно с большой буквы и полностью).
Ждем запуска.
Вводим логин user.
Вводим пароль user.
Выбираем режим 2. 1 – управление командной строкой, а 2 – графический режим. Для управления установкой в полноэкранном режиме дополнительно могут использоваться следующие клавиши: Tab — переход между элементами интерфейса. «пробел» — выбор пункта меню. «стрелка вверх», «стрелка вниз», «+», «–» — задание числовых значений (например, времени), переход между элементами интерфейса.
Нажимаем Next.
Выбираем регион Asia.
Нажимаем Next.
Выбираем страну Russia.
Нажимаем Next.
Выбираем часовой пояс. Обязательно выбирать правильно, иначе не будет работать подключение.
Нажимаем Next.
Проверяем правильность Страны и Часового пояса. Нажимаем Yes.
Устанавливаем текущую дату. В высветившемся окне календаря проверяем правильность даты.
Нажимаем Next.
Устанавливаем текущее время. В высветившемся окне при помощи клавиши Tab выбираем и устанавливаем правильное время перемещая курсор поочередно по окнам.
Нажимаем Next.
Выбираем считывание ключей с USB.
Подключаем USB Flash Disk c Vipnet ключом к координатору. Ставим значок * напротив надписи USB при помощи клавиши Пробел.
После обнаружения координатором всех DST-файлов на USB-носителе, выбираем из предложенных DST-файл (vipnet ключ).
Нажимаем Next.
Вводим пароль DST-файла (парольную фразу).
Нажимаем Next.
Выбираем интерфейс ETH0. Ставим * на «Activate interface on boot» (ставим * на UP). Выбираем активным интерфейс ETH0.
Нажимаем Next.
Выбираем «Set static IP-address ETH0».
Выбор производится при помощи передвижения синей полосы на нужную строку и проставлением * при помощи клавиши пробел..
Нажимаем Next.
Указываем IP-адрес и маску сети для интерфейса ETH0.
Нажимаем Next.
Выбираем интерфейс ETH1. Ставим * на «Activate interface on boot» (ставим * на UP). Выбираем активным интерфейс ETH1.
Нажимаем Next.
Выбираем «Set static IP-address ETH1».
Нажимаем Next.
Указываем IP-адрес и маску сети для интерфейса ETH1.
Нажимаем Next.
Для интерфейса ETH2 ставим * на «Down». Делаем интерфейс ETH2 не активным. Для этого перемещаем синюю полосу на «Down» и ставим знак * клавишей Пробел.
Нажимаем Next.
Для интерфейса ETH3 ставим * на «Down». Делаем интерфейс ETH3 не активным. Для этого перемещаем синюю полосу на «Down» и ставим знак * клавишей Пробел.
Нажимаем Next.
Вводим IP-адрес сетевого шлюза.
Нажимаем Next.
Отключаем функциональность DNS-сервера. Перемещаем синюю полосу на «OFF» (Disable starting the DNS server at boot) и ставим знак * клавишей Пробел.
Нажимаем Next.
Отключаем функциональность NTP-сервера. Перемещаем синюю полосу на «OFF» (Disable starting the NTP server at boot) и ставим знак * клавишей Пробел.
Нажимаем Next.
Прописываем условное наименование данного координатора. Для этого в появившейся командной строке «HW1000………..» удаляем все, что находится после знака тире и прописываем условное название данного координатора маленькими латинскими буквами (например, HW1000-office-mira22 или HW1000-iis-lenina23)
Нажимаем Next.
Диапазон виртуальных адресов оставляем по умолчанию. Выбираем No. Появится вопрос «Do you want to specify custom virtual IP address range?». Перемещаем синюю полосу на «No» и ставим знак * клавишей Пробел.
Нажимаем Next.
Перемещаем синюю полосу на «No» и ставим знак * клавишей Пробел.
Нажимаем Next.
Перемещаем синюю полосу на «No» и ставим знак * клавишей Пробел.
Нажимаем Next.
Нажимаем Finish.
Вводим логин user.
Вводим пароль от DST-файла.
Вводим команду Machine reboot и нажимаем Enter.

Теперь необходимо проверить на клиентских компьютеров доступность данного координатора.

Источник

logo

Категории продуктов

Дополнительно

Услуги

Истории успеха

Центр загрузок

О компании

Документация

Документация на продукты ViPNet не требует для своего скачивания какой-либо предварительной регистрации и заполнения форм и доступна без ограничений

Документация представлена в виде zip-архивов или pdf-файлов. Для просмотра документации понадобится бесплатная программа Adobe Acrobat Reader. Вы ее можете скачать с сайта компании Adobe.

При скачивании документации просим вас обращать внимание на указанный номер версии. Эксплуатируемая вами версия продуктов ViPNet может отличаться от представленной на сайте версии документации

Также вы можете скачать

Источник

Время на прочтение
12 мин

Количество просмотров 143K

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

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

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

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

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

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

Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка «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. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

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

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

Самые популярные выводы это:
iplirdiag -s ipsettings —node-info <идентификатор узла> ##отображение информации об узле
iplirdiag -s ipsettings —v-tun-table ##отображение всех загруженных в драйвер туннелей

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

(Un)split tunneling

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

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

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

В заключение

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

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

Источник

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

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

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

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

(Un)split tunneling

Служебные порты и TCP-туннель

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

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

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

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

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

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

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

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

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

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

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

В заключение

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

Источник

В данной статье мы расскажем вам, как настроить Vipnet coordinator hw1000 — новую модель координатора, который является ключевым компонентом современных сетей Vipnet. Vipnet coordinator hw1000 отличается высокой производительностью и надежностью, а его настройка — процесс достаточно простой и понятный даже для начинающего пользователя.

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

1. Подключите Vipnet coordinator hw1000 к сети питания и убедитесь, что он включен. Подождите несколько секунд, пока устройство загрузится.

2. Получите доступ к веб-интерфейсу Vipnet coordinator hw1000, открыв веб-браузер и вводя в адресной строке IP-адрес координатора. Введите логин и пароль для авторизации.

3. После успешной авторизации вы попадете на главную страницу настроек Vipnet coordinator hw1000. Здесь вы сможете изменить различные параметры настройки, такие как IP-адрес, маску подсети, DNS-серверы и т.д.

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

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

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

Теперь ваш Vipnet coordinator hw1000 настроен и готов к использованию. Вы можете подключать к нему другие устройства и настраивать как локальную, так и удаленную сеть, в зависимости от ваших потребностей и требований. Надеемся, что данная инструкция помогла вам успешно настроить ваш Vipnet coordinator hw1000!

Содержание

Инструкция по настройке Vipnet coordinator hw1000: подробное руководство
Шаг 1: Подключение оборудования
Шаг 2: Настройка IP-адреса
Шаг 3: Ввод логина и пароля
Шаг 4: Настройка соединения
Шаг 5: Настройка беспроводной сети
Шаг 6: Завершение настройки
Примечание:
Подготовка к настройке
Установка и подключение координатора Vipnet coordinator hw1000
Настройка сетевых параметров
Настройка безопасности

Инструкция по настройке Vipnet coordinator hw1000: подробное руководство

Для успешной настройки Vipnet coordinator hw1000 вам потребуется следовать определенной последовательности действий. Ниже представлена подробная инструкция:

Шаг 1: Подключение оборудования

Подключите Vipnet coordinator hw1000 к источнику питания и убедитесь, что индикатор питания включился.

Подключите компьютер или ноутбук к Vipnet coordinator hw1000 с помощью Ethernet-кабеля.

Шаг 2: Настройка IP-адреса

Откройте любой веб-браузер на компьютере или ноутбуке.

Введите IP-адрес «192.168.1.1» в адресную строку браузера и нажмите Enter.

Шаг 3: Ввод логина и пароля

В открывшемся окне введите логин и пароль для доступа к настройкам Vipnet coordinator hw1000. Логин и пароль по умолчанию — «admin».

Шаг 4: Настройка соединения

В главном меню выберите раздел «Настройки сети» и перейдите на вкладку «WAN».

Выберите тип соединения в зависимости от вашей сети. Для широкополосного доступа выберите «PPPoE».

Введите данные вашего интернет-провайдера, такие как логин и пароль, в соответствующие поля.

Нажмите кнопку «Сохранить» для сохранения настроек.

Шаг 5: Настройка беспроводной сети

В главном меню выберите раздел «Настройки сети» и перейдите на вкладку «Wi-Fi».

Включите беспроводную сеть.

Введите название сети (SSID) и выберите тип шифрования.

Задайте пароль для доступа к беспроводной сети и нажмите кнопку «Сохранить».

Шаг 6: Завершение настройки

После сохранения настроек перезагрузите Vipnet coordinator hw1000, чтобы применить изменения.

Ваш Vipnet coordinator hw1000 готов к использованию. Вы можете подключиться к беспроводной сети и наслаждаться быстрым и безопасным интернет-соединением.

Примечание:

В случае возникновения проблем при настройке Vipnet coordinator hw1000, обратитесь к документации, предоставленной производителем, или обратитесь в службу поддержки.

Подготовка к настройке

Перед началом настройки Vipnet coordinator hw1000 необходимо выполнить несколько предварительных действий:

Проверьте наличие всех комплектующих: Vipnet coordinator hw1000, блок питания, провода для подключения.
Убедитесь, что у вас имеются все необходимые разрешения и полномочия для проведения настройки.
Ознакомьтесь с документацией, прилагаемой к Vipnet coordinator hw1000, чтобы понять принцип работы устройства.
Установите Vipnet coordinator hw1000 в подходящем месте, обеспечивающем эффективную работу устройства.
Проверьте наличие надежного и стабильного источника питания, подключенного к блоку питания устройства.

После выполнения этих действий можно приступать к процессу настройки Vipnet coordinator hw1000.

Установка и подключение координатора Vipnet coordinator hw1000

Установка и подключение координатора Vipnet coordinator hw1000 включает в себя следующие шаги:

1. Физическое подключение:

Соедините блок питания с сетевым шнуром и вставьте в розетку.
Подключите интерфейсный кабель от блока питания к порту питания на задней панели координатора hw1000.
Подключите Ethernet-кабель от порта Ethernet на задней панели координатора hw1000 к сетевому коммутатору или маршрутизатору.

2. Настройка сетевого соединения:

На вашем компьютере откройте сетевые настройки и выберите вкладку «Соединения».
Создайте новое сетевое соединение, выбрав тип «Ethernet» и задав IP-адрес в соответствии с настройками вашей локальной сети.
Установите «По умолчанию» для параметров DNS-сервера.

3. Конфигурация координатора:

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

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

После успешной установки и настройки координатора Vipnet coordinator hw1000, вы сможете использовать его для организации защищенной сети и управления удаленными устройствами.

Настройка сетевых параметров

Для корректной работы Vipnet coordinator hw1000 необходимо настроить сетевые параметры:

1. Подключение к сети:

Подключите Ethernet-кабель к порту WAN на задней панели устройства и вашему маршрутизатору.

2. Назначение статического IP-адреса:

Для назначения статического IP-адреса устройству Vipnet coordinator hw1000 выполните следующие шаги:

Откройте веб-браузер и введите в адресной строке IP-адрес вашего устройства (по умолчанию 192.168.1.1).
В открывшейся панели авторизации введите логин и пароль (по умолчанию admin/admin).
В главном меню выберите «Сеть» или «Network».
Выберите раздел «LAN» или «Локальная сеть».
Настройте следующие параметры:
- IP-адрес устройства: введите желаемый IP-адрес (например, 192.168.1.100).
- Маска подсети: введите маску подсети (например, 255.255.255.0).
- Шлюз по умолчанию: введите IP-адрес вашего маршрутизатора.
Сохраните настройки.

3. Проверка подключения:

После настройки сетевых параметров устройства, убедитесь, что оно успешно подключено к сети, проверив доступ в Интернет.

Поздравляем! Теперь вы можете использовать Vipnet coordinator hw1000 с настроенными сетевыми параметрами.

Настройка безопасности

При настройке Vipnet coordinator hw1000 важно обратить особое внимание на защиту системы для обеспечения безопасности ваших данных. В данном разделе мы расскажем о важных настройках безопасности, которые рекомендуется выполнить при первоначальной настройке аппарата.

Смена пароля администратора

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

Войдите в административный интерфейс устройства, используя текущие учетные данные.
Перейдите в меню «Настройки» и выберите раздел «Пароль».
Введите текущий пароль и новый пароль для администратора. Подтвердите новый пароль.
Сохраните изменения и перезагрузите устройство.

Обновление прошивки

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

Настройка брандмауэра

Один из самых важных аспектов безопасности сети — настройка брандмауэра. Брандмауэр Vipnet coordinator hw1000 обеспечивает защиту от внешних атак и несанкционированного доступа.

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

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

Настройка безопасности Vipnet coordinator hw1000 позволит вам обеспечить надежную защиту вашей сети и данных. Помните, что безопасность — непрерывный процесс, требующий постоянного мониторинга и обновления мер безопасности в соответствии с развитием угроз и технологий.

Источник