
Создание координатора в ViPNet Administrator 4
Пришла пора расскащать про создание випнет ключа на координатор в ViPNet Administrator 4 при помощи Центра управления сетью и ключевого центра.
Открываем Центр управления сетью ViPNet.
Переходим во вкладку Координаторы.
Нажимаем на кнопку с плюсиком для создания нового координатора.
Ставим галочку Настроить после создания.
Режим работы. По умолчанию лучше всегда ставить Выполняет функции VPN-сервера, так как альтернативный вариант предполагает, что канал до него не будет шифроваться, то есть сетевые пакеты от клиентов до координаторов не выполняющих функции VPN будут ходить в открытом виде. Если и использоваться такой вариант, то только внутри закрытой инфраструктуры, но зачем тогда такое дорогое устройство? Подразумевается, что второй вариант будет использоваться как координатор без клиентов для туннелирования ресурсов.
Имя координатора. Тут единые рекомендации выработать сложно, но я бы называл примерно так:
Тип координатора + организация + служба + адрес
Например, HW1000 Газпром ОИБ Вавилова 14.
Обязательно оставляем галочку Создать одноименного пользователя.
Всё заполнили, теперь нажимаем Создать.
Это нормально - ругается, что за ним нет клиентов.
Основные параметры нового координатора.
Все поля уже знакомы - имя и описание, но в данном случае, если редактируете имя, то всегда нажимайте да, а не нет, как в случае с пользователями или клиентами.
Для координаторов описания лучше заполнять, особенно если сеть большая. Историю, где находится, этаж, кабинет, номер юнита в стойке.
Тут заполняются координаторы без функции VPN-сервера, для которых функцию VPN-сервера будет выполнять наш создаваемый координатор.
Клиенты, зарегистрированным за этим координатором. Так как он только создаётся тут пусто.
В связи с узлами по умолчанию добавляется Администратор сети. Остальные связи вам необходимо продумать самостоятельно.
Тут можно добавить связи со всеми узлами из заранее созданной группы без вступления в эту группу.
Это пользователя координатора и он тут должен быть один, если это не так, то кто-то при заведение многопользовательского клиента указал не тот сетевой узел.
Данный пользователь нужен только для механизмов выработки ключей для самого координатора, и не более того.
Тут можно добавить координатор в группу узлов с установлением связи со всеми узлами из заранее созданной группы, но уже вместе с вступлением в эту группу.
В случае с "Связи с группами узлов" вы можете устанавливать связь с 8 координаторами для 100 пользователей, а вот с "Группы узлов" все 100 пользователей вступят в группу и будут иметь связь между собой.
Межсерверные каналы. В нескольких предложениях объяснить что это такое, зачем нужно и как это употреблять практически невозможно. Для разных схем построения сети требуются абсолютно разные коцепции с межсетевыми каналами. Про это нужно отдельную большую статью писать - такая не была заплонирована, но я подумаю.
В общем количестве случае все координаторы связывают межсерверным каналом с опорным координатором. Это очень сложный вопрос, часто связывают с координатором, за которым спраятан администратор, чтобы все узлы моглы получать транспортные и служебные пакеты.
Межсетевые каналы - это про межсетевое взаимодействие и по умолчанию тут ничего выбирать не нужно. Как не трудно догадаться, тут указывается для какой сети через какой шлюзовой координатор отправлять пакеты.
Про Роли узла планирую написать отдельную статью, но в целом тут можно указать что это у вас за устройство. По умолчанию пусто и это нужно исправить - нажимаем Добавить.
Выбираем подходящую роль для нашего узла и нажимаем добавить. Дополнительной ролью может быть DNS-сервер, но про это лучше рассказывать отдельно, поэтому планирую написать отдельную статью о том как это настраивать.
Добавили роль координатору.
Кстати, у всех ролей есть свойства и их можно настраивать.
В документации про функцию сделать его интернет шлюзом не особо уточняется, но работать с ним становится сильно сложнее, и это понятно. В общем, смотрящие в интернет координаторы должны иметь такую отметку, но если вы не имеете глубоких знаний vipnet-сетей, тогда лучше не ставить эту галочку сейчас.
Любые настройки данной вкладки зашиваются в DST-файл и при их изменении может потребоваться ручная смена DST-файла на координаторе. Удобнее всего не задавать такие IP адреса, но в некоторых случаях без них могут не работать Linux клиенты и некоторые другие.
Если в DST-файле нет информации об IP-адресе координатора, а он не находится в прямой видимости, тогда от куда клиенту знать где искать этот координатор? ARP-запросы отправлять? А что в них указывать? Mac адрес тоже не записан в DST-файл. В опорного координатора обязательно нужно указывать IP-адрес, а вот у остальных не обязательно, так как клиенты через него смогут узнавать эти данные про других, главное грамотно составить межсерверные каналы.
В общем, тема довольна сложна и также заслуживает отдельной статьи, но не уверен, что есть столько времени, чтобы их расписывать. Все таки про всё это должен подробно писать Инфотекс, а так как они это толком не делают, приходится писать другим. Подумаю, если не забуду, напишу.
Но если нужно, задаётся IP-адрес в ЦУСе просто.
Помните, если на координаторе в настройках задан один IP, а в ЦУСе другой, то однозначно будут проблемы с доступностью данного координатора.
Можно использовать отдельный координатор в качестве MFTP, но это тоже не стоит использовать новичкам.
Еще одна сложная категория. Сама по себе вкладка про то, что будет межсетевым экраном для него и его клиентов.
Со статической трансляцией адресов означает, что задаваемые клиентам виртуальные адреса будут постоянные.
Лично я считаю, что это самый удобный вариант для большинства случаев. В больших сетях всегда приходится кого-то где-то прописывать по виртуальному адресу, а поменять отображение (visibility или tunnel_visibility) для отдельного координатора или на всем координаторе не всегда можно сделать.
И пункт использовать TCP-туннель тоже оставляйте, так как некоторые провайдеры при DDOS атаках могут блокировать соединения UDP по портам 55000+, и вот именно в таких случаях спасает TCP-туннель (в настройках клиента можно переключить).
Также доступна динамическая трансляция адресов, координатор в качестве межсетевого экрана и не используется.
Динамическая трансляция подразумевает смену виртуального адреса при каждом подключении клиента или перезапуске службы iplir.
Координатор в качестве межсетевого экрана должен использоваться, когда он смотрит в интернет без всяких межсетевых экранов, но не бегите активировать эту функцию на дейсвующем координаторе, так как можно очень умело всё сломать. С таким функционалом нужно играть только когда вы профессионал, или строите сеть с нуля.
Настройки межесетевого экрана для клиентов.
Очень полезная функция, если нужно открыть какой-то ресурс за координатором, например, сайт. Фильтрами туннелированных узлов доступ к нему можно будет контроллировать. Очень удобно. Кстати, эта история работает и в обратную сторону, то есть можно разрешить работать с координатором пулу туннелированных IP-адресов, на которых не стоит никаких випнет клиентов.
Добавлять туннели не сложно, и можно добавлять целый диапозон. И да, лучше не добавлять в такой диапозон адрес, с которого работает компьютер с vipnet client, так как у него могут быть периодические проблемы с доступом.
В целом, удобно, сайт за координатором - добавил в туннель IP сайта внутри сети координатора, и добавил в связи координатор всем, кому нужно будет ходить на этот сайт.
И да, при такой схеме от сайта до координатора все пакеты будут открытыми, а уже от координатора зашифрованные.
Если вы не знаете как это делается в vipnet сети и у нас это не реализовано, не делайте. Я напишу отдельную статью про это, но для этой схемы вам нужен свой DNS во внутренней сети, иначе это всё небезопасно.
При необходимости добавить из интернет DNS-сервер он будет автоматически добавлен в качестве туннелируемого адреса на этом координаторе. Задумайтесь об этом.
В целом, система удобная, так как позволяет вставить свою зону и придутельно применить для всех или конкретных клиентов.
Нажимаем применить и Ок.
Далее по отработанной схеме - Справочники и ключи, Создать справочники - Создать для всей сети.
Пошел процесс создания справочников.
Статус стал - Ожидаются ключи, поэтому открываем ключевой центр.
Как видим тут тоже статусы есть.
Для нового координатора создаем дистрибутив ключей.
По результату открывается папка с DST-файлов на координатор и XPS-файлом, в котором хранится пароль. Пароль рекомендую напечатать или записать, так как с координатора вы его не откроете.
Для нового кординатора статус изменился и он не просит передать ключи в ЦУС, но если смотреть в ЦУСе, то там можно увидеть обратное - ожидание ключей, поэтому выделяем все для кого требуется и наши новые DST и передаем ключи в ЦУС.
Ключи получены - статус готово к отправке.
Справочники и ключи, а далее отправить справочники и ключи.
Для незначительных изменений можно сразу просто отправлять на весь список, но при значительных изменениях используйте опцию Отложить применение обновления до ...
Отложенное применение может спасти от ситуации, когда справочники будут применены на координаторе раньше, чем на клиенте за ним, и из-за этого пропадёт связь координатора с клиентом и он просто не сможет получить эти важные справочники.
Есть еще вариант сначала отправлять клиентам, а только потом координаторам, но ждать пока все клиенты получат слишком долго, поэтому отложенное применение более рациональная история.
Добавление связей, новых клиентов, новых координторов - отправляем сразу на всю сеть, а вот изменение параметров на опорном координаторе, на координаторе с большим количеством клиентов, смена мастер ключей, смена пароля администратора - это значительные изменения и лучше использовать отложенное применение.