Вы находитесь на странице: 1из 48

Практические работы

«Работа с ПАК ViPNet HW VA»


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

7.1. Описание лабораторной схемы

Простейшая первоначальная схема стенда практической работы состоит из


трех сетей, правая и левая (по схеме 7.1) из которых представляют собой
защищенные сегменты одной корпоративной ViPNet-сети, третья же сеть
(центральная в схеме) олицетворяет собой очень упрощенную имитацию
пространства сети Интернет (с т. н. «белым» адресным пространством).
На начальном этапе в состав ViPNet-сети входят следующие СУ:
• Левая (по схеме) подсеть (10.10.10.0/28):
– Незащищенные компьютеры PC1 и PC3 (Windows 7)
– Координатор K1 (на базе ПАК HW VA)
• Правая (по схеме) подсеть (10.10.20.0/29):
– Незащищенные компьютеры PC2 и PC4 (Windows 7)
– Координатор K2 (на базе ПАК HW VA)
• Центральная (по схеме) сеть (30.30.30.0/30):
– Координатор K1 (на базе ПАК HW VA)
– Координатор K2 (на базе ПАК HW VA)

Рис. 7.1. Первоначальная схема физических соединений


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

Рис. 7.2. Cхема простейшей сети ViPNet для практикума

Примечание. Для удобства работы с схемами, встречающимися ниже в


описании практических работ, они продублированы дополнительно, в
большем разрешении, в конце данного учебного пособия в разделе
Приложения (стр. 135).
Примечание.
Как работать в командном интерпретаторе ПАК ViPNet HW VA?
Контекстная справка позволяет вам просмотреть информацию о командах и
параметрах, ввод которых возможен в текущей ситуации. Контекстная справка
вызывается с помощью символа «?».
Чтобы просмотреть список всех доступных вам групп команд, в приглашении
интерпретатора ViPNet введите символ «?»:
hostname> ?

inet Set of commands for routing, interfaces and network tools

failover Control command for Failover daemon

iplir Control command for IpLir daemon

mftp Control command for MFTP daemon

enable go to administrator mode

exit leave command interpreter

version view the versions of the appliance

who show vipnet sessions

machine display or change machine settings


debug

ups

firewall firewall management

alg control of the properties of the application-level gateway

hostname> _
Левая колонка списка содержит первое слово группы команд, правая —
краткое описание ее назначения.
В случае ввода символа «?» в процессе набора команд, интерпретатор ViPNet
предложит вам варианты завершения текущего или следующего слова
команды, в зависимости от положения курсора:
hostname> machi?

machine halt or reboot the machine

hostname> machi_

hostname> machine ?

halt switch the machine off

reboot reboot the machine

show display statistics

hostname> machine _
После информации о вариантах завершения команды отображается
приглашение интерпретатора ViPNet с ранее введенной командой для
редактирования. Редактировать команды можно как обычно: стирать символы
клавишей Backspace или Delete, перемещаться по тексту c помощью клавиш
со стрелками влево и вправо.

7.2. Развёртывание ключевых баз

Перед началом эксплуатации на ПАК Coordinator HW необходимо развернуть


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

Для первоначального развертывания ключевых баз необходимо наличие


файла *.dst (дистрибутива ключевых баз). Развертывание ключевых баз можно
выполнить одним из следующих способов:

• С помощью компьютера, а точнее, ноутбука, который подключается к


порту Ethernet 1 ПАК.

• С помощью съемного носителя информации USB (USB-флэш), которая


вставляется в USB-разъем комплекса.
• С помощью CD/DVD-диска при условии подключения по USB к ПАК
внешнего DVD-привода.

В любом случае предполагается, что на ноутбуке или носителе находится


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

Для начала процедуры развертывания ключевых баз введите логин user и


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

При использовании консоли (монитора и клавиатуры) мастер может работать


в одном из двух режимов: в обычном консольном режиме или в режиме с
полноэкранным псевдографическим интерфейсом. Выбор режима работы
мастера производится после его запуска, в ответ на сообщение Please select
setup wizard operating mode:
 1 — консольный;
 2 — полноэкранный.
В ответ на предложение начать установку в консольном режиме
Would you like to start installing keys or restoring configuration?
[y/n] следует ввести символ y и нажать клавишу Enter. В дальнейшем, следуя
указаниям мастера, необходимо выполнить ряд действий, перечисленных
ниже:
 Инициация установки справочников и ключей на ПАК.
 Установка часового пояса, а также даты и времени.
 Выбор нужного дистрибутива ключей (dst-файл).

Рис. 7.3. Выбор файла *.dst для первичной инициализации ПАК ViPNet HW VA

 Настройка сетевых параметров ПАК (ip-адреса, адрес шлюза).


Рис. 7.4. Настройка сетевых параметров ПАК ViPNet HW VA

 Настройка параметров DNS-сервера.


 Настройка параметров NTP-сервера.

Рис. 7.5. Настройка параметров DNS- и NTP-серверов

 Изменение имени компьютера (hostname), если это необходимо.


 Изменение диапазона виртуальных адресов, если это необходимо.
 Проверка связи ПАК с одним или несколькими узлами сети ViPNet.
 Завершение мастера установки.

Рис. 7.6. Завершение мастера установки ПАК ViPNet HW VA


Командный интерпретатор или оболочка (shell) запускается автоматически
после успешной авторизации пользователя в ОС Linux. Для авторизации
необходимо ввести логин user и пароль пользователя, который должен
совпадать с паролем дистрибутива ключевых баз ViPNet.

После успешной авторизации пользователя появляется приглашение


командной строки:
Server1> _
Командная строка может работать в одном из двух режимов:
 Режим пользователя
 Режим администратора (привилегированный)
Сразу после запуска командная оболочка находится в режиме пользователя
(знак > в приглашении командной строки). В режиме пользователя
недоступны многие команды, требующие прав администратора.
Для перехода в привилегированный режим нужно выполнить команду enable
и затем ввести пароль администратора. Если авторизация пройдет успешно, то
режим командной строки сменится на привилегированный режим (значок # в
приглашении командной строки):
Server1> enable
Type the administrator password:
Server1# _

Рис. 7.7. Вход в режим администратора ПАК ViPNet HW VA

Для возвращения в режим пользователя следует использовать либо сочетание


клавиш Ctrl+D либо ввод команды exit. Подобным образом можно совсем
выйти из командной оболочки.

7.3. Подготовка лабораторного стенда


Для настройки стенда потребуется осуществить несколько сетевых
настроек узлов, входящих в схему (см. рис. 7.7 ):
• Сетевые адреса для компьютеров PC1 и PC3 будут раздаваться по
протоколу dhcp c координатора К1;
• Сетевые адреса для компьютеров PC2 и PC4 будут раздаваться по
протоколу dhcp с координатора К2;
• На координаторах К1 и К2 - следует настроить конкретные маршруты до
удаленных сетей.
Рис. 7.8. Первоначальная схема практикума - сетевой уровень

Для работы с настройками ПАК перейдите в режим администратора сетевого


узла: введите команду enable и пароль администратора, переданного вам с
дистрибутивом ключей.

Для настройки dhcp-сервера на ПАК используются следующие команды:

inet show dhcp server - проверка состояния настроек dhcp-сервера

Рис. 7.9. Проверка состояния настроек dhcp-сервера

inet dhcp server int eth1 - назначить интерфейс, с которого пойдет раздача
сетевых адресов
inet dhcp server range 10.10.10.3 10.10.10.9 - диапазон раздаваемых адресов
inet dhcp server router 10.10.10.1 - информация о шлюзе по умолчанию
inet dhcp server mode on - включить автозагрузку dhcp-сервера
Рис. 7.10. Настройка dhcp-сервера на координаторе K1

inet dhcp server start - старт сервиса dhcp

Рис. 7.11. Запуск dhcp-сервера

Добавление конкретного (не по умолчанию) маршрута до удаленной сети (на


примере координатора K1)

1 inet route add 10.10.20.0 next-hop 30.30.30.2 netmask


255.255.255.248 distance 7 weight 1
2

10.10.20.0 – номер удаленной сети


30.30.30.2 – адрес шлюза
255.255.255.248 – маска удаленной сети

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


inet show routing.
Рис. 7.12. Добавление маршрута и просмотр таблицы маршрутизации на Server 1

Сделайте аналогичную настройку на координаторе К2:

Рис. 7.13. Добавление конкретного маршрута до удалённой сети для К2

После настроек сетевых параметров узлов следует проверить, «пингуют» ли


друг друга узлы PC1 и PC3 с одной стороны и узлы PC2 и PC4 с другой, после
выполнения команды vpn stop на обоих координаторах.
Если сетевая доступность вышеперечисленных узлов достигнута, то после
этого необходимо выполнить команду vpn start.

7.4. Firewall. Фильтры по умолчанию

Целью данного задания является изучение особенностей прохождения


сетевого трафика с умолчательными правилами фильтрации на
Координаторах Linux.

Рис. 7.14. Виды сетевого трафика

Примечание. Все изменения настроек ПАК производятся в режиме


администратора узла ViPNet или администратора сети ViPNet. Для этого
потребуется ввод соответствующего пароля администратора после
входа в командную оболочку и выполнения команды enable.
Для включения регистрации всех типов пакетов в журнале ip-пакетов для
каждого из сетевых интерфейсов координатора следует:
• Остановить службу iplir командой iplir stop.
• Далее, командой iplir config eth* (где * – номер сетевого
интерфейса ПАК, то есть для всех задействованных интерфейсов обоих
координаторов) следует изменить значение параметра:
registerall= on

Рис. 7.15. Параметры регистрации ip-пакетов

• После редактирования конфигурационного файла следует вновь


запустить службу iplir командой iplir start.
После этого следует проверить доступность узлов сети (трафики 1-4 на рис.
7.13) путем отправки icmp-пакетов с помощью команды inet ping), а также
с помощью установки соединений по протоколу ssh с последующим
разбором ситуации с помощью журнала ip-пакетов (iplir view).

Примечание. При изучении фильтров по умолчанию следует уделить


особое внимание проверке трафиков 1 и 2 на предмет работоспособности
т. н. «бумеранга», режима инициативных соединений.

7.4. Фильтрация незащищенного локального трафика


Цель задания - разрешение прохождения в обоих направлениях локального
незащищенного трафика (трафики 1 и 2 на рис. 7.13) между компьютерами
(незащищенными узлами) PC1+PC3, PC2+PC4 и координаторами K1 и K2
(ПАК HW VA).
На K1 следует выполнить команду enable для входа в режим
администратора и далее:
firewall local add src 10.10.10.3-10.10.10.9 dst 10.10.10.1
icmp pass
firewall local add src 10.10.10.3-10.10.10.9 dst 10.10.10.1
tcp dport 22 pass
или
firewall local add src 10.10.10.3-10.10.10.9 dst 10.10.10.1
service @SSH pass
firewall local add src 10.10.10.3-10.10.10.9 dst @local tcp
dport 8080 pass

Внимание! tcp dport 22 = service @SSH 10.10.10.1 (локальный


ip-адрес Server1) = @local
Выполнить аналогичную настройку и на K2.

Рис. 7.16. Задание правил фильтрации локального трафика на K2

После вышеуказанных настроек следует проверить прохождение трафиков


1 и 2 (рис. 7.14.) по протоколу icmp (команда inet ping):
• Доступность PC1+PC3 ←→ K1 и PC2+PC4 ←→ K2
• Доступность друг другу узлов PC1+PC3 ←→ PC2+PC4 (трафик 4).

Рис. 7.17. Проверка доступности координаторов

Просмотр пакетов в журнале ip-пакетов: iplir view


Сделать выводы.

Дополнительное задание
Проверить доступность ПАК с локальных компьютеров по протоколу ssh.
Для этого на компьютере следует установить какой-нибудь ssh-клиент
(например, putty).
Рис. 7.18. Доступ по протоколу ssh к координатору K1 с узла PC3

Просмотреть журнал IP-пакетов: iplir view

Рис. 7.19. Просмотр журнала регистрации IP-пакетов на ПАК ViPNet HW VA

who - посмотреть, кто и каким способом подключен к консоли Координатора.

Рис. 7.20. Просмотр подключенных к консоли пользователей


admin kick [LINE] – «сбросить» пользователя командной строки
координатора, подключенного к нему удаленно по протоколу ssh.
Значение LINE выясняется по выводу в консоли после выполнения команды
who.
Рис. 7.21. Отключение пользователя командной строки ПАК
Результат выполнения команды kick на локальной машине выглядит

следующим образом:

Рис. 7.22. Результат выполнения команды kick

Попробовать подсоединиться к ПАК по веб-интерфейсу для изучения


последнего. Для этого на локальном компьютере (PC1+PC3, PC2+PC4) в
адресной строке браузера следует ввести локальный ip-адрес Координатора и
порт 8080:
10.10.10.1:8080

Рис. 7.23. Просмотр свойств dhcp-сервера через веб-интерфейс


Рис. 7.24. Просмотр системной информации в веб-интерфейсе ПАК

7.5. Фильтрация незащищенного транзитного трафика


Цель задания - разрешение прохождения в обоих направлениях транзитного
незащищенного трафика между удаленными компьютерами –
незащищенными узлами (PC1+PC3) и (PC2+PC4) (трафик 4).
Проверить доступность удаленных друг от друга сетей (транзитный трафик).
В командном интерпретаторе vipnet shell:
firewall forward show - просмотр умолчательных правил транзитного
трафика.
Создание собственных ip-объектов для своих и удаленных незащищенных
узлов:
firewall ip-object add name @myhosts 10.10.10.3-10.10.10.9
firewall ip-object add name @others 10.10.20.3-10.10.20.5

firewall ip-object show - просмотр созданных объектов.


Рис. 7.25. Создание и просмотр ip-объектов для незащищенных узлов
Разрешить «свой» и «чужой» незащищенный транзитный трафик:

firewall forward add src @myhosts dst @any pass firewall


forward add src @others dst @myhosts pass

firewall forward show - просмотр созданных правил транзитного


незащищенного трафика.

Выполнить аналогичную настройку и на K2.


Проверить сетевую доступность (PC1+PC3) и (PC2+PC4) при помощи
отправки icmp-пакетов (ping).

Рис. 7.26. Проверка сетевой доступности PC2+PC4

С помощью журнала ip-пакетов iplir view следует убедиться, что между


удаленными друг от друга незащищенными узлами разрешен именно
транзитный незащищенный трафик (трафик 4).
Рис. 7.27. Просмотр журнала IP-пакетов

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

Рис. 7.28. Просмотр подробной информации о записи в журнале IP-пакетов

7.6. Включение антиспуфинга

Цель задания - включение и проверка фильтра антиспуфинга (о том, что


такое антиспуфинг, и как это работает в ПАК 4 – см. стр. 56).

В командном интерпретаторе:
iplir option get antispoofing - просмотр состояния антиспуфинга
по умолчанию.
iplir option set antispoofing on - включение.
iplir option get antispoofing - проверка.
Выполнить аналогичную настройку и на K2
Проверить доступность Linux1 ↔ Linux2 (трафик 4, рис. 7.14).
Проанализировать данные журнала ip-пакетов: iplir view.
Сделать выводы.

Рис. 7.29. Включение антиспуфинга

7.7. Настройка трансляции сетевых адресов

Цель задания - настройка трансляции сетевых адресов (NAT), а точнее, PAT4.


В командной строке K1 (Server 1) следует выполнить команду:

firewall nat add 1 src @myhosts dst @any change src 30.30.30.1

Выполнить аналогичную настройку и на Server2.

Рис. 7.30. Добавление правила трансляции сетевых адресов

Проверить доступность незащищенных узлов из разных сетей друг другу и


выяснить, повлияла ли настройка PAT на трафик 4 и каким образом.
Если трафик 4 перестал ходить, то для выяснения причин его отсутствия
следует обратиться к журналу ip-пакетов и получить ответы на следующие
вопросы:
 На каком координаторе блокируются пакеты трафика 4?
 На каком интерфейсе координатора блокируются пакеты трафика 4?
 Какое направление движения трафика на интерфейсе координатора, где
блокируется трафик 4?
 Какие именно ip-пакеты блокируются?
 Какое событие (event) описывает в журнале блокировку пакетов трафика
4?
Рис. 7.31. Просмотр информации о блокированных IP-пакетах

На основании анализа ответов на вышеперечисленные пункты следует


ответить на главный вопрос:
 В какое правило какого фильтра следует внести изменения для
возобновления трафика 4?
Совет. Для внесения изменений в правила фильтрации существует
специальная субкоманда change append.

firewall forward change append [номер изменяемого правила или


объекта] [изменяемая часть правила или объекта]

Например, команда
firewall forward change append 1 src 30.30.30.2

внесет в правило фильтрации за номером 1 изменение – добавит к


существующим источникам (src, source) еще один.
Данные настройки также можно выполнить, подключившись к ПАК через веб-
интерфейс:
Рис. 7.32. Редактирование группы объектов «IP-адреса» в веб-интерфейсе ПАК

Для этого нужно зайти в группу настроек «Firewall», раздел «Object Groups»,
подраздел «IP addresses». Затем двойным щелчком раскрыть конкретную
группу адресов и внести изменения:

Рис. 7.33. Добавление IP-адреса

После внесения изменений необходимо нажать «Apply all» для сохранения


изменений.
Рис. 7.34. Применение изменений

7.8. Фильтрация защищенного трафика

Цель задания - изучение некоторых возможностей драйвера iplir по


фильтрации т. н. «защищенного» трафика 3 (рис. 7.13) между ViPNet-узлами,
которыми в лабораторной схеме на данном этапе являются координаторы K1
и K2.

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


взаимодействуют между собой (шифрованный трафик 3, см. рис. 7.4 стр. 108)
тремя способами (K1 ←→ K2):
1. inet ping X.X.X.X
2. iplir ping [ID], где ID – уникальный идентификатор СУ.

Рис. 7.35. Проверка взаимодействия координаторов между собой


3. inet ssh host X.X.X.X

где X.X.X.X – сетевой адрес ПАК.

Рис. 7.36. Проверка взаимодействия координаторов по протоколу ssh

Требуется запретить координатору K2 удаленно «заходить» по ssh на


координатор K1. При этом K1 должен иметь право заходить на K2
посредством ssh, а также разрешается любой другой защищенный трафик
между этими СУ.

Для этого в командном интерпретаторе следует выполнить:

firewall vpn add src [ID Server2] dst @local tcp dport 22
drop
firewall vpn show – проверка создания правила фильтрации защищенного
трафика.

Рис. 7.37. Созданное правило фильтрации для защищённого трафика


Проверить исполнение этого правила можно командой, запущенной с
соседнего координатора K2, чей ssh-трафик был запрещен выше:

inet ssh host [ip-адрес координатора K1]

inet ssh host 30.30.30.1

Совет. Если какое-либо правило разрешения/запрета соединения не


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

firewall vpn move rule 20 to 13

Рис. 7.38. Просмотр блокированных IP-пакетов

7.9. Туннелирование незащищенных узлов

Цель задания - создать защищенное туннельное соединение на участке


центральной сети «Интернет» (K1 ←→ K2, см. рис. 7.38) между
незащищенными узлами PC1 и PC2. Трафик между двумя другими
незащищенными компьютерами (PC3 ←→ PC4) пока останется
незашифрованным на всем протяжении пути.
Рис. 7.39. Схема туннельных соединений

Следует проверить, существует ли по умолчанию правило фильтрации,


разрешающее весь туннельный трафик:

firewall tunnel show

Затем необходимо уточнить ip-адреса компьютеров PC1 и PC2 (так как адреса
им раздаются по dhcp координаторами).
Далее следует приступить к редактированию файла iplir.conf (команда iplir
config).
Сперва на обоих координаторах в секции [misc] меняем значение параметра
tunnel_virt_assignment :

tunnel_virt_assignment= manual

Рис. 7.40. Установка ручного режима назначения виртуальных ip-адресов


Настройки же туннелируемых ресурсов PC1 и PC2 будут выглядеть
следующим образом:

В файле iplir.conf (на K1)

[id] - своя секция, первая


tunnel= 10.10.10.3-10.10.10.3 to 10.10.10.3-10.10.10.3

Рис. 7.41. Назначение адресов туннелирования для К1

[id] - секция для соседнего Server 2


tunnel= 10.10.20.3-10.10.20.3 to 10.10.20.3-10.10.20.3

В файле iplir.conf (на K2)

[id] - своя секция, первая:


tunnel= 10.10.20.3-10.10.20.3 to 10.10.20.3-10.10.20.3

[id] - секция для соседнего Server 1


tunnel= 10.10.10.3-10.10.10.3 to 10.10.10.3-10.10.10.3

Рис. 7.42. Наcтройка адресов туннелирования для K2

Одновременно с этим следует проверить доступность узлов PC3 ←→ PC4


(незащищенный трафик) и проанализировать трафик в журнале ip-пакетов
iplir view и по выводу команды iplir info.
Убедиться, что на участке между координаторами проходят оба типа трафика
одновременно.

Рис. 7.43. Журнал IP-пакетов

Проверить доступность узлов PC1 (туннелируемый ресурс) → PC4


(незащищенный узел), а затем наоборот: PC4 → PC1.
Туннелируемый узел будет «пинговать» обычную незащищенную машину, а
та, в свою очередь, туннелируемую - нет. Почему?

7.10. Фильтрация туннельного трафика


Цель задания - выполнить фильтрацию туннельного трафика таким образом,
чтобы работало только защищенное соединение с узла PC1 на PC2 по
протоколу rdp (Удаленный Рабочий стол, tcp:3389). Любое другое
взаимодействие между этими туннелируемыми ресурсами должно быть
запрещено.
PC1 → PC2 по rdp (tcp:3389)

Рис. 7.44. Принцип создания правил фильтрации туннельного трафика между PC1 ↔ PC2
Примечание. Для выполнения этого задания на обоих координаторах
необходимо удалить, либо на время отключить правила фильтрации в разделе
firewall tunnel, разрешающие весь туннельный трафик. Временное
отключение правил фильтрации осуществляется только через веб-интерфейс
Координатора HW4.

Пример.
firewall tunnel delete 1, где 1 - номер правила фильтрации в цепочке
tunnel.

Рис. 7.45. Временное отключение правил фильтрации

Для выполнения этого задания достаточно осуществить следующие настройки


на K1 и K2:
На К1 (Server 1, id=0x1a120017) описывается трафик от PC1 до K2 (первая
«часть пути» от PC1 до PC2):

firewall tunnel add src 10.10.10.3 dst 0x1a120018 tcp dport


3389 pass или

firewall tunnel add src @tunneledip dst 0x1a120018 service


@RDP pass

На K2 (Server 2, id=0x1a120018) описывается трафик от K1 до PC2 (вторая


«часть пути» от PC1 до PC2):

firewall tunnel add src 0x1a120017 dst 10.10.20.3 tcp dport


3389 pass или
firewall tunnel add src 0x1a120017 dst @tunneledip service
@RDP pass

В том случае, если помимо частного правила фильтрации не будет указано


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

Иными словами, что явно не разрешено конкретными правилами – будет


запрещено.

После этого для проверки фильтрации на узле PC2 необходимо настроить


Удаленный доступ к рабочему столу.
Проверить доступность:

PC1 → PC2 rdp

PC2 → PC1 rdp

PC1 ←→ PC2 ping

PC3 ←→ PC4 ping, rdp

С помощью журнала ip-пакетов iplir view убедиться в том, что


существующими правилами фильтрации в firewall tunnel запрещен
любой туннельный трафик, кроме соединения туннелируемых ресурсов PC1 c
PC2 по прикладному протоколу rdp. Незащищенный транзитный трафик при
этом будет проходить через координаторы K1 и K2 беспрепятственно.

По итогам работы сделать соответствующие выводы.

Дополнительное задание
В firewall tunnel правила фильтрации по умолчанию, отключенные
ранее – включить на обоих координаторах. Собственные правила фильтрации
туннельного rdp-трафика из предыдущего задания – отключить.
Сделать оставшиеся незащищенные машины (PC3 и PC4) туннелируемыми
ресурсами.
С помощью журнала ip-пакетов iplir view убедиться в том, что теперь
любой трафик, проходящий на центральном участке схемы (между
Координаторами), является зашифрованным.
Сделать выводы.

7.11. Настройка Автономного режима


Цель задания – сменить режим работы ПАК «МСЭ со статической
трансляцией адресов» на Автономный режим (без межсетевого экрана).
iplir stop
iplir config – редактирование файла iplir.conf

[id] - своя секция


· · ·
id= 0x1a120017
ip= 30.30.30.1
ip= 10.10.10.1
usefirewall= off
firewallip= 30.30.30.1
port= 55777
proxyid= 0x1a120017 - СВОЙ уникальный ID
[adapter]
name= eth0
type= internal
[adapter]
name= eth1
type= internal
[dynamic]
dynamic_proxy= off

Для применения внесенных изменений следует выполнить команду:


iplir start
После настройки Автономного режима следует проверить работоспособность
лабораторной сети и сделать соответствующие выводы.

Самостоятельное задание

Цель задания – выполнить фильтрацию трафика на координаторах K1 и K2. В


лабораторной схеме узлы должны взаимодействовать между собой только
согласно пунктам 1-7. Весь остальной трафик должен быть запрещен.
Проверить результаты.

1. PC3 → PC2 - rdp+telnet rdp = tcp:3389


2. PC4 → PC1 - rdp+telnet ssh = tcp:22
3. PC2+PC4 K1 – ssh telnet = tcp:23
4. PC1+PC3 K2 – ssh ping = icmp
5. PC1+PC3 → K1 – http http = tcp:80, 8080
6. PC2+PC4 → K2 – http
7. ping разрешить везде.
Примечание. Стрелочка → указывает на направление соединения – от кого к
кому. Перечеркнутая стрелочка символизирует запрет соединения в
указанном направлении.

Примечание. Если на компьютерах установлена ОС Windows 7, то там, где


это потребуется заданием, нужно установить сервер Telnet (Панель
управления → Установка и удаление программ → Компоненты Windows).
После установки необходимо включить автозапуск службы Telnet server и
запустить её.

7.12. Настройка полутуннеля

Цель задания - установка защищенных соединений на участке сети Интернет


между подсетями сети ViPNet, в одной из которых находятся ViPNet-клиент
Client1 (PC1) и туннелируемый ресурс PC3, в другой - ViPNet-клиент Client2
(PC2) и туннелируемый ресурс PC4.

Рис. 7.46. Полутуннели между Client1 (PC1) ↔ PC4 и Client2 (PC2) ↔ PC3

Ниже приведен алгоритм необходимых действий для создания двух


полутуннелей согласно рис. 7.46.

1. Вернуть на обоих координаторах правила фильтрации туннельного


трафика по умолчанию (firewall tunnel).
2. Исключить из настроек туннелируемых ресурсов ip-адреса узлов PC1 и
PC2 (параметр tunnel в iplir.conf).
Примечание. Проверить, подходят ли для этого следующие параметры:
exclude_from_tunnels и usetunnel. Воспользоваться справочным
руководством к актуальной версии прошивки ПАК HW 4.

3. На PC1 и PC2 необходимо установить ViPNet Client 4.х.


4. Произвести для ViPNet Client на PC1 первичную инициализацию с dst-
файлом Client1.
5. Произвести для ViPNet Client на PC2 первичную инициализацию с dst-
файлом Client2.
6. В Client Monitor АП Client1 в списке защищенной сети выделить
Координатор K2 (Server2) и двойным щелчком запустить его настройки.
Во вкладке Туннель прописываем сетевой адрес туннелируемого
ресурса PC4.

Рис. 7.47. Настройка адресов туннелирования в программе ViPNet Client

7. В Client Monitor АП Client2 в списке защищенной сети выделить


Координатор K1 (Server1) и двойным щелчком запустить его настройки.
Во вкладке Туннель прописываем сетевой адрес туннелируемого
ресурса PC3.
8. Проверить на ViPNet-клиентах доступность узлов, связанных с ними
согласно схеме сети ViPNet в ЦУС (удаленный клиент и оба
координатора) (Например, выделением нужного СУ в списке
Защищенная Сеть Клиент-Монитора и нажатием клавиши F5).

9. Пустить icmp-трафик между клиентами и туннелируемыми ресурсами.


10.Изучить выводы журнала ip-пакетов iplir view на обоих
координаторах (результаты отфильтровать по интерфейсу eth0).
Убедиться, что трафик между клиентскими узлами и туннелируемыми
ресурсами – зашифрованный.

Рис. 7.48. Просмотр событий в журнале IP-пакетов

11.Отправка/получение файлов по Файловому обмену и одновременный


просмотр очереди mftp-конвертов на координаторах с помощью
команды mftp info.

Рис. 7.49. Отправка файла по файловому обмену в ViPNet Client


12. Просмотр журнала mftp-конвертов (команда mftp view).

Рис. 7.50. Просмотр журнала mftp-конвертов на ПАК ViPNet HW VA

7.13. Сохранение настроек ПАК

Целью задания является сохранение настроек координатора ПАК HWVA


двумя способами:

1. Созданием т. н. «снимка» настроек системы (конфигурационных файлов),


к которому, в случае необходимости, можно откатить состояние
координатора;
2. Cозданием полноценного backup-файла с расширением *.vbe, который
включает в себя ключевую информацию, адресные справочники,
настройки конфигурационных файлов координатора, сетевые параметры и
т. д.

Примечание. vbe-файл может использоваться вместо dst-файла при


первичной инициализации координатора, например, в том случае, когда
требуется обновить прошивку ПАК.

Перед созданием «снимка» настроек ПАК в ознакомительных рекомендуется


зайти в т. н. «режим чистого Linux» – командную строку ОС Linux,
установленной в ПАК. Сделать это можно командой:

admin escape
После предупреждения и ввода пароля администратора сетевого узла
произойдет вход в командную оболочку Linux.

После этого следует просмотреть содержимое каталога, в котором находятся


конфигурационные файлы координатора:

ls -l /opt/vipnet/user

Посмотреть дату создания/изменения и размер файла storage.db, в котором


хранятся снапшоты (снимки) настроек координатора. После этого следует
выйти из режима «чистого» Linux – exit.

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


следующие действия:
1. Сохранить «снимок» настроек системы при помощи команд группы
admin:
admin config save ИМЯ
2. Команда не сработает, так как дополнительно потребуется, соблюдая
очередность, остановить службы iplir, failover и mftp.

Не рекомендуется использовать для этой цели команду vpn stop.

3. Убедиться, появился ли сохраненный «снимок» настроек в списке


сохраненных конфигураций координатора при помощи команд группы
admin:

admin config list

Рис. 7.51. Сохранение настроек ПАК

4. Изменить какие-нибудь некритичные настройки (например, в


firewall.conf)
Рис. 7.52. Удаление правила фильтрации защищённого трафика №14

и «откатиться» на сохраненный «снимок» системы (от предложения


сохранить текущую конфигурацию следует отказаться, действуя согласно
инструкциям в командной строке):

admin config load ИМЯ

Рис. 7.53. Загрузка сохранённого «снимка» системы

5. Убедиться, что настройки из сохраненного ранее «снимка» состояния


системы восстановились.
6. Снова зайти в режим командной строки Linux и посмотреть дату
создания/изменения и размер файла storage.db, в котором хранятся
конфигурации настроек HWVA. Сравнить с предыдущими значениями.
Вторая часть задания состоит в сохранении на usb-носитель информации
полный набор настроек системы (файл *.vbe), а также журналы событий служб
координатора, при помощи команд из группы admin:

admin export keys binary-encrypted usb

admin export logs usb

Рис. 7.54. Сохранение настроек системы на usb-носитель

Рис. 7.55. Сохранение журналов событий служб координатора на usb-носитель

Чтобы проверить работоспособность получившегося vbe-файла, следует


имитировать удаление ключевой информации c координатора, а затем
восстановить ключи, данные, настройки.

admin remove keys – удаление ключевой информации

После этого нужно восстановить заново все настройки и т. д. координатора,


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

В дальнейшем, при создании лабораторной схемы с применением


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

7.14. Настройка расписания в правилах фильтрации

Целью задания является включения расписания для правил фильтрации


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

daily <время>-<время> — фильтр будет действовать ежедневно в течение


указанного промежутка времени. Время указывается в 24-часовом формате
hh:mm.

weekly [mo] [tu] [we] [th] [fr] [sa] [su] [at <время>-<время>]
— фильтр будет действовать еженедельно в указанные дни недели и
промежуток времени.

calendar <дата>-<дата> [at <время>-<время>] — фильтр будет


действовать в указанные даты и промежуток времени.
Дата указывается в формате DD.MM.YYYY.
schedule <название группы объектов> — чтобы указать вместо
расписания группу объектов. Расписание может быть задано с помощью
группы объектов соответствующего типа, если она была создана ранее.

Предлагается самостоятельно выбрать или написать правило фильтрации


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

Совет. Рекомендуется использовать как прямое указание времени


срабатывания того или иного правила фильтрации, так и создание
пользовательского объекта расписания, и его дальнейшее применение в
правиле фильтрации.

В рамках лабораторной работы в качестве времени срабатывания правила


фильтрации следует выбрать любое удобное значение.

Пример. Правило фильтрации


firewall forward add 1 src @myhosts dst @any weekly su at
00:01-23:59 drop
– означает, что весь исходящий незащищенный транзитный трафик в каждое
воскресенье будет заблокирован в указанный промежуток времени. В
остальное время правило работать не будет. 1 – номер правила в цепочке
firewall forward.

7.15. Агрегация каналов

Целью задания является создание агрегированного канала на базе свободных


сетевых интерфейсов координатора HW 4.

Требуется создать агрегированный канал (Etherchannel) между ко-


ординаторами K1 (Server1) и K2 (Server2).

Для этого следует должным образом подготовить интерфейсы eth0, eth2, eth3,
которые будут входить в состав будущего агрегированного интерфейса bond0.

Если во время первоначальных настроек ПАК (после первого запуска)


интерфейсы eth2 и eth3 не были активированы, то следует сделать это сейчас:

inet ifconfig eth2 up


inet ifconfig eth3 up
Рис. 7.57. Агрегированный канал между K1 (Server1) и K2 (Server2)

Далее необходимо присвоить класс slave всем сетевым интерфейсам,


входящим в состав будущего агрегированного интерфейса:

inet ifconfig eth0 class slave


inet ifconfig eth2 class slave
inet ifconfig eth3 class slave

Рис. 7.58. Присвоение класса slave сетевым интерфейсам координатора

После этого соответствующей командой создается сетевой интерфейс bond0:

inet bonding add 0 mode balance-rr slaves eth0 eth2 eth3

или

inet bonding add 0 mode 802.3ad slaves eth0 eth2 eth3

где 0 – номер интерфейса bond, balance-rr и 802.3ad – некоторые из


режимов агрегирования (см. стр. 47).
Рис. 7.59. Выбор режима агрегирования сетевого интерфейса

Назначение ip-адреса агрегированному интерфейсу bond0:

inet ifconfig bond0 address 30.30.30.1 netmask


255.255.255.252

Если в iplir.conf не появится секция [adapter] для bond0 – для


полноценной работы требуется создать ее вручную по аналогии с секцией
интерфейса eth1 (у которого class access), а также включить для интерфейса
bond0 регистрацию всех типов пакетов в журнале (параметр registerall):

iplir stop
iplir config – для создания секции [adapter].
iplir start

Рис. 7.60. Создание секции [adapter] для сетевого интерфейса bond0

iplir stop
iplir config bond0 – включение регистрации пакетов.
iplir start

Рис. 7.61. Включение регистрации IP-пакетов на интерфейсе bond0


В завершение остается лишь активировать интерфейс bond0:

inet ifconfig bond0 up

Просмотр настроек сетевых интерфейсов, маршрутов и прочего:

inet show interface bond0


inet show routing
iplir info

Рис. 7.62. Просмотр настроек сетевого интерфейса bond0

Аналогичные настройки следует повторить на втором координаторе K2


(Server2).

Внимание! Режим агрегации (mode) должен быть одинаковым на обоих


координаторах.

Далее следует убедиться в работоспособности агрегированного канала, пустив


по нему транзитный или иной трафик;
Рис. 7.63. Поиск IP-пакетов, проходящих через интерфейс bond0

определить пропускную способность интерфейсов bond, составляющих канал


(хотя бы по команде inet show interface); проверить надежность,
отключив один из физических интерфейсов, находящихся в составе канала.

7.16. Включение и настройка OSPF

Целью задания является включение и демонстрация работы протокола


динамической маршрутизации OSPF (IP:89) на Координаторах HW 4.

Для демонстрации эффекта работы протокола OSPF предварительно следует:

 Увеличить сеть 30.30.30.0 между координаторами с префикса /30 (2


адреса на узлы) до /28 (14 адресов на узлы).
 Удалить на обоих координаторах существующие дефолтные и
статические маршруты до сетей друг друга

Рис. 7.64. Просмотр таблиц маршрутизации на ПАК и удаление маршрутов по


умолчанию
и добавить новые статические маршруты по умолчанию со значениями next-
hop из сети 30.30.30.0/28, не принадлежащими реальным сетевым узлам,
например, для K1 – 30.30.30.12, а для K2 – 30.30.30.13.

Рис. 7.65. Создание новых статических маршрутов и просмотр таблиц маршрутизации

Рис. 7.66. Просмотр созданного статического маршрута

Включение собственно OSPF – протокола динамической маршрутизации –


выглядит следующим образом (на примере K1 (Server1)):

inet ospf mode on – непосредственно включение режима OSPF.

Добавление «своих» (directly connected) для K1 сетей в OSPF:

inet ospf network add 10.10.10.0 netmask 255.255.255.240 area 1


inet ospf network add 30.30.30.0 netmask 255.255.255.240 area 1
inet show ospf configuration – просмотр конфигурации OSPF.
Рис. 7.67. Добавление «своих» для К1 сетей в OSPF

Для работоспособности протокола OSPF необходимо разрешить входящие


unicast и специальный multicast трафики по протоколу OSPF от соседей по
OSPF (маршрутизаторов, координаторов) к координатору K1 (Server1):

firewall local add 1 rule ”My_OSPF” src @any dst @local service
@OSPF pass
firewall local add 1 rule ”My_OSPF” src @any dst @multicast service
@OSPF pass

Разрешить исходящий ospf-трафик с координатора K1 (Server1):


firewall local add 1 rule ”My_OSPF” src @local dst @any service
@OSPF pass

Рис. 7.68. Добавление правил фильтрации по протоколу OSPF. Просмотр базы данных
маршрутов
Аналогичную настройку следует произвести на K2 (Server2), естественно, с
учетом его собственного сетевого окружения.
Рекомендуется после этого перезагрузить оба координатора командой
machine reboot.
После загрузки устройств командой
inet show ospf neighbours

нужно убедиться, что соседний координатор появился в списке «соседей по


OSPF».
После этого в таблицах маршрутизации друг друга должны появиться ospf-
маршруты до сетей друг друга, и взаимодействие двух сетей 10.10.10.0 и
10.10.20.0 должно возобновиться.

Рис. 7.69. Просмотр журнала IP-пакетов – трафик по протоколу OSPF проходит


inet show ospf database – просмотр базы данных маршрутов OSPF.

7.17. Настройка кластера горячего резервирования

Рис. 7.70. Физическая схема с кластерами горячего резервирования


Целью задания является базовая настройка и изучение особенностей работы
Кластера горячего резервирования на базе координаторов ПАК HWVA Q2/Q3.
Следует помнить, что на координаторах, входящих в состав Кластера, должен
быть развернут один и тот же ключевой дистрибутив (т. н. dst-файл), кабель
перемычки – т. н. канал синхронизации – должен представлять собой crossover
cable.

Рис. 7.71. Сетевая схема с кластерами горячего резервирования

В том случае, если будет принято решение настраивать кластеры горячего


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

inet ifconfig bond0 bonding delete eth2


– освободить интерфейс eth2 из-под bond0 для создания перемычки между
элементами кластера;
Рис. 7.72. Освободить интерфейс eth2 из-под bond0

inet ifconfig eth2 class access – назначить интерфейсу eth2 класс


access;

inet ifconfig eth2 address X.X.X.X netmask X.X.X.X – назначить


ip-адрес на eth2 согласно схеме на рис. 7.70.

Рис. 7.73. Назначение адресов согласно сетевой схеме

Алгоритм действий и команд по созданию кластера горячего резервирования


выглядит следующим образом:

1. Отключить службу dhcp-сервера на координаторах, т. к. эта служба не


работает в кластерном режиме failover:
inet dhcp server mode off
inet dhcp server stop
2. Остановка службы failover на обоих координаторах:
failover stop

3. На K1-K4 – правка конфигурационного файла failover.ini:


failover config edit
4. Включение режима кластера на обоих координаторах:
failover config mode cluster

5. На K1 (K2) – Назначение активного координатора:


failover start active

6. На K3 (K4) – Назначение пассивного координатора:


failover start passive

7. Просмотр состояния службы failover на обоих координаторах:


failover show info

Рис. 7.74. Просмотр состояния службы failover

Таблица 7.1. Настройки необходимых параметров failover.ini на обоих координаторах


Кластера горячего резервирования

Координатор К1 Координатор К3

[network] [network]
checktime= 10 checktime= 10
[channel] [channel]
device= eth0 device= eth0
activeip= 30.30.30.1 activeip= 30.30.30.1
passiveip= 30.30.30.4 passiveip= 30.30.30.3
testip= 30.30.30.7 testip = 30.30.30.7
ident= external ident= external
checkonlyidle= yes checkonlyidle= yes
[channel] [channel]
device= eth1 device= eth1
activeip= 10.10.10.1 activeip= 10.10.10.1
passiveip= 10.10.10.2 passiveip= 10.10.10.3
testip= 10.10.10.5 testip = 10.10.10.5
ident= internal ident= internal
checkonlyidle= yes checkonlyidle= yes
[sendconfig] [sendconfig]
device= eth2 device= eth2
activeip= 10.10.50.2 activeip= 10.10.50.1
(IP-адрес интерфейса «перемычки»(IP-адрес интерфейса «перемычки»
соседнего координатора K3) соседнего координатора K1)

Аналогичным образом настраивается и правый (рис. 7.70) Кластер горячего


резервирования на координаторах К2 и К4.

Для имитации потери активным координатором связи с одной из сетей


достаточно отключить сетевой кабель из разъема eth0 или eth1 активного
координатора (в виртуальной среде Oracle VM Virtual Box для этого
достаточно отключить данный сетевой интерфейс в меню «Настройки»>
«Сеть» данной виртуальной машины) и понаблюдать за поведением обоих
координаторов кластера, а также за трафиком, проходящим в этот момент
через кластер из одной подсети ViPNet в другую.

Рис. 7.75. Прохождение трафика при отключении активного координатора кластера

Самостоятельное задание
Изучить принцип работы т. н. альтернативной схемы кластера горячего
резервирования (см. стр. 93) настоящего учебного пособия и перенастроить
существующие кластеры на альтернативную схему.