Построение L2 VPN туннеля при помощи программного модуля «С-Терра L2»
Настоящий документ содержит описание способа совместного использования Продуктов компании ООО «С-Терра СиЭсПи» и Продуктов третьих производителей.
ООО «С-Терра СиЭсПи» осуществляет сопровождение настоящего сценария в части настроек Продуктов Компании. Упоминание наименований, продуктов, торговых марок третьих организаций исключительно неформально и не является поддержкой, рекомендацией либо рекламой. ООО «С-Терра СиЭсПи» не несет какой-либо ответственности в отношении работоспособности и использования этих Продуктов. Документ имеет статус вспомогательного материала, который может быть использован технологическими партнерами, компаниями-интеграторами, при разработке собственных решений.
Решения, разработанные на базе данного сценария, могут применяться в действующих сетях/системах только после тестовой и/или опытной эксплуатации.
Архив с установочным файлом "С-Терра L2":
sterra_l2_4.3.23255.amd64.rarДанный сценарий описывает настройку безопасного взаимодействия между центральным офисом и филиалом на уровне 2 модели OSI (L2 VPN).
Обеспечение безопасного взаимодействия достигается путем шифрования и туннелирования трафика с применением отечественных отраслевых стандартов ГОСТ и протокола IPsec.
Все остальные соединения разрешены, но защищаться при помощи IPsec не будут.
В рамках данного сценария для аутентификации партнеры будут использовать сертификаты. В качестве криптопровайдера будет использована криптографическая библиотека, разработанная компанией «С-Терра СиЭсПи». Шлюзы безопасности (или криптошлюзы) - «С-Терра Шлюз» версии 4.3.
Для переноса запросов и сертификатов между криптошлюзами и центром выпуска сертификатов требуется USB Flash накопитель.
Требования к квалификации администратора
Администратор должен обладать обширными знаниями в области сетевой информационной безопасности, иметь опыт работы с аналогичным оборудованием/программным обеспечением, знать и понимать следующие технологии и протоколы: PKI, IPsec, NAT, Firewall, routing, switching.
1. Требования к устройствам.
1.1. С-Терра Шлюз.
1.1.1 Устройства С-Терра Шлюз должны быть инициализированы (подробнее на http://doc.s-terra.ru раздел С-Терра Шлюз -> С-Терра Шлюз 4.3 -> «Подключение ПАК и инициализация С-Терра Шлюз на вычислительных системах архитектуры Intel x86-64»).
1.2. Центр выпуска сертификатов.
1.2.1 Должен быть настроен центр выпуска сертификатов (удостоверяющий центр, далее УЦ) для IPsec. Устройство с именем Certification_authority на схеме.
1.2.2 Для выпуска цифровых сертификатов допускается использование встроенного в OC Windows Server 2008R2 (или новее) удостоверяющего центра совместно с сертифицированным СКЗИ «КриптоПро» CSP 4.0 (или новее).
1.2.3 Для тестовых целей можно использовать тестовый УЦ от «КриптоПро» (веб-интерфейс: https://www.cryptopro.ru/certsrv/certrqxt.asp).
Категорически запрещено использование тестового УЦ от «КриптоПро» в производственной (боевой) эксплуатации, так как в данном случае отсутствует возможность контролировать процесс выпуска сертификатов и, соответственно, процедуру аутентификации.
1.3. HTTP сервер для распространения списка отозванных сертификатов.
1.3.1 Функционирующий HTTP сервер для распространения списка отозванных сертификатов (СОС). Устройство с именем CRL_distribution_point на схеме. Если по объективным причинам использование СОС не представляется возможным или не требуется, то проверку СОС можно отключить в CLI.
Доставка нового списка отозванных сертификатов с удостоверяющего центра на HTTP сервер должна происходить заблаговременно, до истечения срока действия предыдущего списка.
2. Требования к сетевому взаимодействию.
2.1. Между криптошлюзами должна быть обеспечена IP связность.
Рисунок 1. Схема взаимодействия
1. Размещение устройств.
1.1. В центральном офисе размещаются: центр выпуска сертификатов (Certification_authority), криптошлюз С-Терра Шлюз (Hub1), управляемый коммутатор (Int_switch1_Hub1) и персональные компьютеры (host0-behind-hub1 и host1-behind-hub1).
1.2. В филиале размещаются: криптошлюз С-Терра Шлюз (Spoke1), управляемый коммутатор (Int_switch1_Spoke1) и персональные компьютеры (host0-behind-spoke1 и host1-behind-spoke1).
1.3. В неконтролируемом сегменте (синее облако на схеме) размещаются: HTTP сервер для распространения списка отозванных сертификатов (CRL_distribution_point), маршрутизатор (Router1).
2. Подключение к сети Интернет.
2.В данном сценарии для эмуляции сети Интернет используются маршрутизатор Router1.
Подключение к сети Интернет на устройствах С-Терра Шлюз будет считаться успешным, если по протоколу ICMP (или «ping») будет доступен HTTP сервер для распространения списка отозванных сертификатов (устройство CRL_distribution_point на схеме).
2.1. Криптошлюз Hub1 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Router1).
2.2. Криптошлюз Spoke1 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Router1).
3. L2 VPN.
Общие сведения
L2 VPN реализуется при помощи модуля «С-Терра L2», который требует отдельной лицензии.
Основная задача данного модуля - перехват фреймов и упаковка их в пакеты UDP для последующего шифрования при помощи С-Терра VPN. После перехвата и инкапсуляции фреймов в UDP модулем «С-Терра L2» получившиеся пакеты маршрутизируются в соответствии с глобальной таблицей маршрутизации. Соответственно, чтобы инкапсулированные пакеты были зашифрованы (помимо наличия правил шифрования на WAN интерфейсе) в таблице маршрутизации должен быть соответствующий маршрут (достаточно одного маршрута по умолчанию) через нужный WAN интерфейс, к которому прикреплена крипто-карта.
За работу модуля «С-Терра L2» отвечает сервис l2svc. По умолчанию данный сервис выключен и не добавлен в автозапуск:
root@sterragate:~# systemctl status l2svc
● l2svc.service - S-Terra L2 Tunneling Service
Loaded: loaded (/lib/systemd/system/l2svc.service; disabled; vendor preset: e
Active: inactive (dead)
Конфигурационные файлы и файл с лицензией должны располагаться в директории /opt/l2svc/etc/. Конфигурационные файлы обязательно должны иметь расширение .conf (например to_spoke1.conf). Файл с лицензией должен обязательно называться l2.lic.
Принцип работы модуля «С-Терра L2»
Рассмотрим принцип работы модуля на примере конфигурационного файла:
vif tap0
local 172.16.100.2
remote 172.16.1.2
port 50000
capture eth1
bridge br0
bridge_ip 192.168.100.1/24
mssfix 1400
passtos
· vif <NAME> - параметр определяет имя виртуального туннельного интерфейса, который будет создан. Имя должно быть уникальным во всех конфигурационных файлах. Длина имени должна быть не более 15 символов. Фреймы с данного интерфейса инкапсулируются в UDP.
· local <IP> - параметр определяет локальный IP адрес для инкапсулированных пакетов. Как правило, локальный IP адрес указывается такой же, как IP адрес на WAN интерфейсе С-Терра Шлюз, но если WAN интерфейсов несколько, то нужно создать loopback интерфейс и назначить на него какой-то третий произвольный IP адрес, который будет использоваться в качестве локального IP адреса (процедура создания loopback интерфейсов описана на сайте doc.s-terra.ru -> С-Терра Шлюз > С-Терра Шлюз 4.3 > Настройка шлюза > Общие настройки шлюза > Работа с интерфейсами > Добавление и удаление сетевых интерфейсов > Добавление и удаление виртуальных сетевых интерфейсов > Loopback интерфейсы).
· remote <IP> - параметр определяет IP адрес партнера по L2 туннелю. Данный IP адрес будет является адресом назначения для инкапсулированных пакетов.
· port <PORT> - параметр одновременно определяет номер UDP порта источника (src) и назначения (dst) инкапсулированных пакетов.
· capture <NAME> - параметр определяет имя существующего интерфейса, на котором будет происходить захват фреймов.
· bridge <NAME> - параметр определяет имя интерфейса виртуального коммутатора (linux kernel bridge). Имя может быть одинаковым в нескольких конфигурационных файлах. Длина имени должна быть не более 15 символов. Виртуальный коммутатор используется для объединения в L2 мост виртуального туннельного интерфейса (определяется параметром vif <NAME>) и сетевого интерфейса, с которого происходит захват фреймов (определяется параметром capture <NAME>).
· bridge_ip <IP/MASK> - параметр определяет локальный IP адрес для интерфейса виртуального коммутатора, который задается параметром bridge <NAME>. Используется для L3 связности между устройствами в LAN сегменте и С-Терра Шлюз через интерфейс захвата фреймов (например, применимо для цели управления С-Терра Шлюз).
· mssfix <VALUE> - параметр выставляет значение MSS в TCP пакетах. При включении данной опции поле MSS всех проходящих через туннель TCP пакетов будет выставлено в <VALUE>, если текущее значение MSS в пакете больше <VALUE>. Применимо для пакетов протокола IPv4, которые вкладываются в Ethernet/802.1Q/QinQ. Для MPLS не работает.
· passtos - параметр включает копирование ToS байта из исходного пакета в инкапсулированный. Применимо для пакетов протокола IPv4, которые вкладываются в Ethernet/802.1Q/QinQ. Для MPLS копирование не работает.
После того, как сервис l2svc будет запущен с данным конфигурационным файлом, будут созданы интерфейсы vif <NAME> и bridge <NAME>, далее интерфейсы vif <NAME> и capture <NAME> будут добавлены в виртуальный коммутатор bridge <NAME>. На интерфейсе bridge <NAME> будет назначен IP адрес, указанный в параметре bridge_ip, например:
root@Hub1:~# ip address show
...
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff
14: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether ca:f5:a9:b7:e5:35 brd ff:ff:ff:ff:ff:ff
15: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 scope global br0
valid_lft forever preferred_lft forever
root@Hub1:~# brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.0050569e674d no eth1
tap0
Накладные расходы (overhead) L2 VPN
Так как оригинальный фрейм инкапсулируется в UDP, то минимальные накладные расходы инкапсуляции L2 - это 28 (20 IP+ 8 UDP) байт. Если используется параметр fragment <N> в конфигурационном файле модуля «С-Терра L2», то добавляется еще 4 байта. Не стоит забывать про накладные расходы инкапсуляции IPsec, которые для туннельного режима могут составлять от 50 до 60 байт (зависит от алгоритма шифрования и наличия NAT).
Рисунок 2. Накладные расходы (overhead) L2 + IPsec
Рисунок (см. рисунок 2) показывает минимальный и максимальный размер накладных расходов при организации L2 VPN для оригинального нетегированного, 802.1 Q и QinQ фрейма. Если шифруется MPLS, то размер оригинального фрейма может варьироваться в зависимости от количества меток в стеке, учитывайте это.
Из рисунка (см. рисунок 2) видно, что с учетом размера оригинального фрейма, а также L2 и IPsec инкапсуляций результирующий пакет может иметь размер от 1592 до 1614 байт. Если MTU на WAN интерфейсе С-Терра Шлюз имеет значение в 1500 байт (по умолчанию), то инкапсулированные пакеты будут фрагментированы, что в свою очередь приведет к снижению производительности (до 15 %). Соответственно, при наличии возможности, заказывайте нужный вам MTU у вашего провайдера на каналообразующем оборудовании, чтобы избежать фрагментации и снижения производительности.
Фрагментация, MTU и DF бит
По умолчанию размер MTU для всех интерфейсов модуля «С-Терра L2» - 1500 байт. Размер MTU можно увеличить при помощи параметра tun_mtu <N> в конфигурационном файле модуля «С-Терра L2». Например, увеличение tun_mtu используется для случая, когда MTU устройств в LAN сегменте - 9000 байт, а MTU интерфейса WAN С-Терра Шлюз - 1500 байт. В этом случае большие пакеты будут фрагментированы драйвером С-Терра VPN (фрагментация пакетов происходит после зашифрования).
DF (don’t fragment) бит с исходных пакетов на инкапсулированные не переносится (не настраивается). Используется для того, чтобы большие пакеты могли быть фрагментированы драйвером С-Терра VPN.
Если требуется выполнять фрагментацию в самом модуле «С-Терра L2» до зашифрования (используется в случае, если каналообразующее оборудование блокирует фрагментированные пакеты), то нужно использовать параметр fragment <N> в конфигурационном файле (все пакеты, большие N байт будут фрагментированы). Данный параметр добавляет дополнительные 4 байта и должен быть включен на обеих сторонах туннеля.
Защита 802.1Q трафика
Если нужно зашифровать тегированный 802.1Q трафик, то рекомендуется на каждый VLAN ID создавать отдельный конфигурационный файл модуля «С-Терра L2» и логический 802.1Q интерфейс, а с точки зрения политики безопасности IPsec туннель, - такой подход позволяет лучше контролировать защищаемый трафик (маппирование VLAN ID в IPsec туннель). Но, если топология точка-точка и трафика с различными VLAN ID больше 10, то рекомендуется настраивать один конфигурационный файл и не создавать 802.1Q интерфейсы - это позволит увеличить производительность шифрования (общее правило - чем меньше конфигурационных файлов модуля «С-Терра L2» и IPsec туннелей, тем выше производительность).
Управление С-Терра Шлюз через интерфейс захвата пакетов
Управление С-Терра Шлюз, начиная с версии 4.3, возможно через тот интерфейс, на котором происходит захват фреймов, для этого нужно задать параметр bridge_ip <IP>/<MASK> в конфигурационном файле модуля «С-Терра L2». Если данный вариант по какой-то причине не подходит - используйте выделенный сетевой интерфейс.
Пропуск фреймов протоколов LACP/LLDP
По умолчанию фреймы протоколов LACP/LLDP будут уничтожены. Чтобы они могли пройти через С-Терра Шлюз (требуется в сценарии балансировки нагрузки и резервировании при помощи внешнего коммутатора) нужно в соответствующем файле конфигурации модуля «С-Терра L2» добавить параметр group_fwd_mask со значением 16388, пример:
group_fwd_mask 16388
Копирование ToS байта из оригинального пакета в инкапсулированный
Копирование ToS байта из оригинального пакета в инкапсулированный (и, соответственно, в ESP/NAT-Т пакеты - поведение С-Терра VPN по умолчанию) включается при помощи параметра passtos в конфигурационном файле модуля «С-Терра L2». Применимо для пакетов протокола IPv4, которые вкладываются в Ethernet/802.1Q/QinQ. Для MPLS копирование не работает.
Производительность
В модуле «С-Терра L2» есть возможность выделить определенное количество ядер под инкапсуляцию фреймов в UDP, настраивается при помощи параметра L2VPN_CORE_COUNT в файле /opt/l2svc/etc/global.cfg. По умолчанию используется только одно последнее ядро. Подробнее смотрите на сайте doc.s-terra.com -> С-Терра L2 -> С-Терра L2 4.3-> Руководство администратора -> Настройка Продукта -> Общие настройки.
4. Параметры безопасного взаимодействия.
Весь трафик (на уровне 2 модели OSI) подсетей 192.168.100.0/24 и 192.168.101.0/24, который передается между центром и филиалом, защищается с использованием алгоритмов ГОСТ и протокола IPsec в туннельном режиме.
Инициировать защищенное соединение может как трафик из филиала в центр, так и наоборот, из центра в филиал.
4.1. Параметры протокола IKE:
· Аутентификация при помощи цифровых сертификатов, алгоритм подписи - ГОСТ Р 34.10-2012 (ключ 256 бит);
· Алгоритм шифрования - ГОСТ 28147-89 (ключ 256 бит);
· Алгоритм вычисления хеш-функции - ГОСТ Р 34.11-2012 ТК26 (ключ 256 бит);
· Алгоритм выработки общего ключа (аналог алгоритма Диффи-Хеллмана) - VKO_GOSTR3410_2012_256 (ключ 256 бит).
4.2. Параметры протокола ESP:
· Комбинированный алгоритм шифрования и имитозащиты (контроль целостности) - ESP_GOST-4M-IMIT (ключ 256 бит).
1. Настройте IP адрес - 172.16.1.1 и маску - 255.255.255.0 на сетевом интерфейсе ens160.
2. Настройте IP адрес - 172.16.100.1 и маску - 255.255.255.0 на сетевом интерфейсе ens192.
3. Разрешите прохождение IP трафика.
1. Интерфейс gi0/0 должен быть в trunk режиме. Должно быть разрешено прохождения фреймов с VLAN ID 0 и 10.
2. Интерфейс gi0/1 должен быть в access режиме c VLAN ID 0.
3. Интерфейс gi0/2 должен быть в access режиме c VLAN ID 10.
1. Интерфейс gi0/0 должен быть в trunk режиме. Должно быть разрешено прохождения фреймов с VLAN ID 0 и 10.
2. Интерфейс gi0/1 должен быть в access режиме c VLAN ID 0.
3. Интерфейс gi0/2 должен быть в access режиме c VLAN ID 10.
1. Настройте IP адрес - 192.168.100.100 и маску - 255.255.255.0 на сетевом интерфейсе.
2. Разрешите прием и отправку ICMP пакетов.
1. Настройте IP адрес - 192.168.101.100 и маску - 255.255.255.0 на сетевом интерфейсе.
2. Разрешите прием и отправку ICMP пакетов.
1. Настройте IP адрес - 192.168.100.101 и маску - 255.255.255.0 на сетевом интерфейсе.
2. Разрешите прием и отправку ICMP пакетов.
1. Настройте IP адрес - 192.168.101.101 и маску - 255.255.255.0 на сетевом интерфейсе.
2. Разрешите прием и отправку ICMP пакетов.
Настройка будет происходить локально при помощи консольного подключения.
Настройка может осуществляться и удаленно (по SSH), но исключительно по доверенному каналу связи. Доверенным каналом связи может считаться канал в пределах контролируемой зоны в случае отсутствия в нем нарушителя (в нашем примере это подсети 192.168.100.0/24, 192.168.101.0/24. Доверенным каналом связи также считается канал, защищенный при помощи протокола IPsec (например, после настройки шифрования разрешается выполнять настройку критошлюза Spoke1 из центрального офиса).
Дата и время на всех криптошлюзах и УЦ должны быть одинаковы, так как для аутентификации используются цифровые сертификаты, в которых зафиксированы дата и время начала их действия и окончания. Также одинаковые дата и время на всей инфраструктуре облегчают поиск неисправностей по лог-файлам.
1. Войдите в CLI разграничения доступа. Для этого, после появления сообщения:
S-Terra administrative console
введите логин и пароль для CLI разграничения доступа:
Пользователь и пароль по умолчанию: administrator, s-terra. Обязательно смените пароль для пользователя administrator при помощи команды change user password.
login as: administrator
administrator's password:
administrator@sterragate]
2. Установите правильный тип терминала (для putty тип терминала xterm) и требуемую ширину (для удобства работы), например:
administrator@sterragate] terminal terminal-type xterm
administrator@sterragate] terminal width 150
3. Установите нужную временную зону и правильные дату и время на криптошлюзе, используя консоль linux bash. Для этого выполните следующие команды.
3.1. Войдите в linux bash.
administrator@sterragate] system
Entering system shell...
3.2. Установите нужную временную зону:
root@sterragate:~# dpkg-reconfigure tzdata
3.3. Установите правильное время и дату (формат - месяц/день/год часы:минуты):
root@sterragate:~# date -s "07/04/2019 12:32"
Thu Jul 4 12:32:00 MSK 2019
4. Установите надежный пароль для пользователя root (под данным пользователем осуществляется доступ по SSH в linux bash):
root@sterragate:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
5. Выйдите из linux bash обратно в CLI разграничения доступа:
root@sterragate:~# exit
logout
Leaving system shell...
administrator@sterragate]
Начальные настройки завершены.
Продукт не поддерживает разностные (delta) списки отзыва сертификатов, только базовые. Учитывайте это при выборе или развертывании УЦ.
Для аутентификации партнеров по IPsec можно использовать только цифровые сертификаты, выпущенные при помощи сертифицированного СКЗИ.
Аутентификация по предопределенным ключам запрещена и возможна только в тестовых целях.
Закрытый ключ для сертификата криптошлюза будет сгенерирован при помощи утилиты cert_mgr с использованием биологического датчика случайных чисел (БИО ДСЧ). Если на криптошлюзе установлен аппаратный датчик случайных чисел, то для выработки случайных чисел по умолчанию будет использоваться аппаратный датчик. Закрытый ключ может храниться либо на файловой системе устройства, либо на защищенном ключевом носителе (токен). В данном сценарии закрытый ключ будет располагаться в специальном контейнере на файловой системе устройства. Если требуется, чтобы контейнер располагался на токене, то смотрите описание параметра create утилиты cert_mgr на портале документации http://doc.s-terra.ru.
В момент генерации ключевой пары будет также сгенерирован запрос на локальный сертификат криптошлюза. Данный запрос для его последующей доставки на УЦ будет сохранен на USB Flash накопитель.
Настройка осуществляется в CLI разграничения доступа.
При выполнении сторонних команд в CLI разграничения доступа/консоли cisco-like перед командой нужно указывать ключевое слово run. Автодополнение для команд, указываемых после run не поддерживается.
1. Генерация закрытого ключа и запроса на сертификат криптошлюза.
1.1. Вставьте USB Flash накопитель в свободный USB порт криптошлюза (накопитель будет автоматически примонтирован).
1.2. Определите имя (идентификатор) USB Flash накопителя на криптошлюзе:
administrator@sterragate] dir media:
1 dr-x 4096 Thu Jul 4 10:40:32 2019 1482-7CB1
Имя (идентификатор) USB Flash накопителя - 1482-7CB1.
1.3. Запустите процесс генерации закрытого ключа и запроса на сертификат криптошлюза с сохранением файла запроса на USB Flash накопителе (закрытый ключ остается на криптошлюзе):
administrator@sterragate] run cert_mgr create -subj "C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1" -GOST_R341012_256 -fb64 media:1482-7CB1/hub1.request
· ключ -subj задает отличительное имя сертификата (Distinguished Name, DN);
Отличительное имя сертификата должно быть уникальным для каждого устройства.
· ключ -GOST_R341012_256 задает использование алгоритма подписи - ГОСТ Р 34.10-2012 (ключ 256 бит).
На УЦ для поддержки алгоритма ГОСТ Р 34.10-2012 (ключ 256 бит) должно быть установлено СКЗИ «КриптоПро CSP» версии 4.0 или новее.
· ключ -fb64 задает месторасположение и формат представления запроса на сертификат; будет использован формат представления BASE64 с сохранением файла запроса в корень USB Flash накопителя под именем hub1.request.
Нажимайте предлагаемые клавиши на клавиатуре для инициализации БИО ДСЧ:
Progress: [********* ]
Press key: U
После завершения работы БИО ДСЧ файл запроса будет сохранен в корне USB Flash накопителя:
administrator@sterragate] dir media:1482-7CB1/
1 -rwx 473 Thu Jul 4 10:40:32 2019 hub1.request
Настоятельно рекомендуется сохранить контейнер закрытого ключа при помощи утилиты cont_mgr. Контейнер может понадобиться в случае восстановления криптошлюза при отказе HDD/SSD диска. Носитель с файлом контейнера нужно хранить в защищенном и недоступном для третьих лиц месте.
1.4. Отмонтируйте и извлеките USB Flash накопитель (посмотреть точки монтирования можно при помощи команды run mount):
administrator@sterragate] run umount /media/1482-7CB1
2. Выпуск сертификата криптошлюза на УЦ и импортирование сертификатов УЦ и криптошлюза в базу Продукта.
2.1. Доставьте файл запроса на УЦ и выпустите по нему сертификат криптошлюза.
2.2. Скопируйте выпущенный сертификат для криптошлюза под именем hub1.cer и сертификат УЦ под именем ca.cer в корень USB Flash накопителя.
2.3. Вновь вставьте USB Flash накопитель, содержащий файлы сертификатов, в свободный порт USB на криптошлюзе.
2.4. Убедитесь в наличии сертификатов на USB Flash накопителе:
administrator@sterragate] dir media:1482-7CB1/
1 -rwx 592 Thu Jul 4 10:40:32 2019 ca.cer
2 -rwx 804 Thu Jul 4 10:40:32 2019 hub1.cer
3 -rwx 473 Thu Jul 4 10:40:32 2019 hub1.request
Сохраняйте сертификаты. Они могу понадобиться в случае восстановления криптошлюза при отказе HDD/SSD диска.
2.5. Импортируйте сертификат УЦ в базу Продукта:
administrator@sterragate] run cert_mgr import -f media:1482-7CB1/ca.cer -t
· ключ -f задает месторасположение файла сертификата;
· ключ -t используется для импортирования доверенного (trusted) сертификата УЦ.
2.6. Импортируйте сертификат криптошлюза в базу Продукта:
administrator@sterragate] run cert_mgr import -f media:1482-7CB1/hub1.cer
2.7. Убедитесь, что сертификаты успешно импортированы в базу Продукта:
administrator@sterragate] run cert_mgr show
Found 2 certificates. No CRLs found.
1 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1
Видно, что сертификат УЦ импортирован как trusted, а сертификат криптошлюза как local (local означает, что для данного сертификата есть соответствующий ключевой контейнер).
2.8. Выполните проверку статуса сертификатов в базе Продукта:
administrator@sterragate] run cert_mgr check
1 State: Inactive C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Certificate can not be verified.
2 State: Inactive C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1
Certificate can not be verified.
Видно, что все сертификаты имеют статус Inactive (неактивный) с пометкой: «Certificate can not be verified» (сертификат не может быть проверен). Причиной этому является включенный по умолчанию в консоли cisco-like механизм проверки списка отозванных сертификатов (далее СОС или CRL). Так как в базе Продукта СОС отсутствует, поэтому проверка не может быть осуществлена. Далее будет описан процесс настройки автоматической загрузки СОС и импортирование его в базу Продукта. Загрузка СОС осуществляется по протоколу HTTP с заданной периодичностью.
1. Войдите в cisco-like консоль из CLI разграничения доступа:
Пользователь и пароль по умолчанию cscons, csp. Обязательно смените пароль для пользователя cscons, так как под этим пользователем осуществляется доступ по SSH в cisco-like консоль. Также не забудьте сменить enable пароль.
administrator@sterragate] configure
sterragate login: cscons
Password:
S-Terra Gate 4.3.XXXXX (amd64)
sterragate#
2. Смените пароль для пользователя cscons и на enable:
sterragate#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
sterragate(config)#username cscons secret 0 ПАРОЛЬ
sterragate(config)#enable secret 0 ПАРОЛЬ
Настройка сетевых параметров проходит в два эта. Первый - создание 802.1Q интерфейса в linux bash. Второй - настройка IP адресов и маршрутизации в cisco-like консоли.
Первый этап.
1. Перейдите в linux bash:
sterragate(config)#end
sterragate#exit
administrator@sterragate] system
Entering system shell...
2. Создайте 802.1Q интерфейс eth1.10 (VLAN ID 10). Процедура создания 802.1Q интерфейсов описана на сайте doc.s-terra.ru, С-Терра Шлюз > С-Терра Шлюз 4.3 > Настройка шлюза > Общие настройки шлюза > Работа с интерфейсами > Добавление и удаление сетевых интерфейсов > Добавление и удаление виртуальных сетевых интерфейсов > 802.1Q (VLAN) интерфейсы.
Второй этап.
Изменение состояния интерфейсов и назначение IP адресов в cisco-like консоли применяются сразу после ввода соответствующих команд. Политика безопасности применяются после выхода из режима конфигурирования.
1. Перейдите в cisco-like консоль из linux bash:
root@sterragate:~# exit
logout
Leaving system shell...
administrator@sterragate] configure
sterragate login: cscons
Password:
Last login: Mon Mar 2 15:00:48 MSK 2020 on pts/0
S-Terra Gate 4.3.XXXXX (amd64)
sterragate#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
2. Задайте имя устройства:
sterragate(config)#hostname Hub1
3. Включите внешний GigabitEthernet0/0 и внутренний GigabitEthernet0/1 интерфейсы:
Hub1(config)#interface range GigabitEthernet 0/0 - 1
Hub1(config-if-range)#no shutdown
Hub1(config-if-range)#exit
4. Убедитесь, что интерфейсы административно включены и line protocol (способность интерфейса передавать пакеты в данный момент) находится в состоянии up:
Hub1(config)#do show interfaces
GigabitEthernet0/0 is up, line protocol is up
Hardware address is 0050.569e.b06d
MTU 1500 bytes
GigabitEthernet0/1 is up, line protocol is up
Hardware address is 0050.569e.d3c3
MTU 1500 bytes
...
Если line protocol находится в состоянии down, то проверьте подключение сетевого интерфейса криптошлюза к коммутационному или прочему оборудованию.
5. Задайте IP адрес в соответствии со схемой стенда на внешнем GigabitEthernet0/0 интерфейсе:
Hub1(config)#interface GigabitEthernet 0/0
Hub1(config-if)#ip address 172.16.100.2 255.255.255.0
Hub1(config-if)#exit
6. Задайте маршрут по умолчанию через устройство Router1:
Hub1(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.1
7. Проверьте доступность устройства Router1 и выйдите из cisco-like консоли:
Hub1(config)#do ping 172.16.100.1
PING 172.16.100.1 (172.16.100.1) 100(128) bytes of data.
108 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1.13 ms
108 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=0.237 ms
108 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=0.192 ms
108 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=0.200 ms
108 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=0.299 ms
--- 172.16.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4078ms
rtt min/avg/max/mdev = 0.192/0.411/1.131/0.362 ms
Hub1(config)#end
Hub1#exit
administrator@Hub1]
1. Перейдите в linux bash:
administrator@Hub1] system
Entering system shell...
root@Hub1:~#
2. Скопируйте Вашу лицензию на «С-Терра L2» в файл /opt/l2svc/etc/l2.lic:
root@Hub1:~# vim.tiny /opt/l2svc/etc/l2.lic
[license]
CustomerCode=XXXXX
ProductCode=L2VPN
LicenseNumber=XXXXX
LicenseCode=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
3. Создание конфигурационных файлов «С-Терра L2» для перехвата и инкапсуляции нетегированных и тегированных (VLAN ID 10) фреймов.
3.1. Создайте конфигурационный файл /opt/l2svc/etc/to_spoke1_nvlan.conf для нетегированных фреймов (native VLAN):
Если в качестве capture интерфейса указать физический интерфейс (например eth0), то все фреймы, пришедшие на данный интерфейс, будут перехвачены вне зависимости от их VLAN ID. Контролируйте поступающие фреймы в capture интерфейс на trunk порту коммутатора настройками VLAN фильтрации.
root@Hub1:~# vim.tiny /opt/l2svc/etc/to_spoke1_nvlan.conf
vif tap0
bridge br0
bridge_ip 192.168.100.1/24
capture eth1
local 172.16.100.2
remote 172.16.1.2
port 50000
mssfix 1400
passtos
Описание параметров представлено в главе «Общая логика работы».
3.2. Создайте конфигурационный файл /opt/l2svc/etc/to_spoke1_vlan10.conf для тегированных фреймов VLAN ID 10:
Если в качестве capture интерфейса указать логический 802.1Q интерфейс (например eth0.10), то только фреймы с соответствующим VLAN ID, пришедшие на данный интерфейс, будут перехвачены.
root@Hub1:~# vim.tiny /opt/l2svc/etc/to_spoke1_vlan10.conf
vif tap1
bridge br1
bridge_ip 192.168.101.1/24
capture eth1.10
local 172.16.100.2
remote 172.16.1.2
port 50001
mssfix 1400
passtos
Описание параметров представлено в главе «Общая логика работы».
4. Запустите сервис l2svc и добавьте его в автозапуск:
root@Hub1:~# systemctl start l2svc.service
root@Hub1:~# systemctl enable l2svc.service
Created symlink /etc/systemd/system/default.target.wants/l2svc.service → /lib/systemd/system/l2svc.service.
root@Hub1:~# systemctl status l2svc.service
● l2svc.service - S-Terra L2 Tunneling Service
Loaded: loaded (/lib/systemd/system/l2svc.service; enabled; vendor preset: en
Active: active (exited) since Wed 2020-03-04 04:43:23 MSK; 18s ago
Main PID: 1688 (code=exited, status=0/SUCCESS)
Mar 04 04:43:23 Hub1 systemd[1]: Starting S-Terra L2 Tunneling Service...
Mar 04 04:43:23 Hub1 systemd[1]: Started S-Terra L2 Tunneling Service.
5. Убедитесь, что необходимые виртуальные сетевые интерфейсы (tap0/tap1/br0/br1) созданы; capture и vif интерфейсы (tap0/tap1/eth1/eth1.10) переведены в promisc режим; выставлены IP адреса на интерфейсах br0/br1:
root@Hub1:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:9e:fb:29 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.2/24 brd 172.16.100.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:50:56:9e:0a:06 brd ff:ff:ff:ff:ff:ff
5: eth1.10@eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1 state UP group default qlen 1000
link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff
6: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether 16:64:ab:2d:4a:87 brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 scope global br0
valid_lft forever preferred_lft forever
8: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN group default qlen 1000
link/ether 8e:f7:a6:06:f7:c9 brd ff:ff:ff:ff:ff:ff
9: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:50:56:9e:67:4d brd ff:ff:ff:ff:ff:ff
inet 192.168.101.1/24 scope global br1
valid_lft forever preferred_lft forever
Если по какой-то причине интерфейсы на создались или произошли другие ошибки, то можно посмотреть информацию о проблеме при помощи команды:
root@Hub1:~# journalctl -xe -u l2svc_s@<L2_CONIG_NAME>.service
где <L2_CONIG_NAME> - имя конфигурационного файла L2 без «.conf», например to_spoke1_nvlan:
root@Hub1:~# journalctl -xe -u l2svc_s@to_spoke1_nvlan.service
-- Logs begin at Tue 2020-03-10 22:49:42 MSK, end at Wed 2020-03-11 19:27:27 MSK. --
Mar 10 22:54:24 Hub1 systemd[1]: Starting S-Terra L2 Tunneling Service for to_spoke1_nvlan...
-- Subject: Unit l2svc_s@to_spoke1_nvlan.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit l2svc_s@to_spoke1_nvlan.service has begun starting up.
Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: License OK
Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: S-Terra L2 for Linux 4.3.20285
Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: TAP device tap0 opened
Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: tunnel local (bound): 172.16.100.2:50000
Mar 10 22:54:24 Hub1 l2svc[2073]: Tue Mar 10 22:54:24 2020 l2svc: tunnel remote: 172.16.1.2:50000
Mar 10 22:54:24 Hub1 systemd[1]: Started S-Terra L2 Tunneling Service for to_spoke1_nvlan.
-- Subject: Unit l2svc_s@to_spoke1_nvlan.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit l2svc_s@to_spoke1_nvlan.service has finished starting up.
--
-- The start-up result is done.
Mar 10 22:55:42 Hub1 l2svc[2073]: Tue Mar 10 22:55:42 2020 l2svc: Peer Connection Initiated with 172.16.1.2:50000
Mar 10 22:55:43 Hub1 l2svc[2073]: Tue Mar 10 22:55:43 2020 l2svc: Initialization Sequence Completed
6. Перейдите в CLI разграничения доступа из linux bash и далее в режим конфигурирования cisco-like консоли:
root@Hub1:~# exit
logout
Leaving system shell...
administrator@Hub1] configure
Hub1 login: cscons
Password:
Last login: Mon Mar 2 15:00:48 MSK 2020 on pts/0
S-Terra Gate 4.3.XXXXX (amd64)
Hub1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
1. Параметры IKE.
1.1. Укажите в качестве типа идентификатора, используемого в рамках протокола IKE, отличительное имя (Distinguished Name, DN):
Hub1(config)#crypto isakmp identity dn
По умолчанию отличительное имя будет взято из сертификата устройства, например, для Hub1 это «C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1».
1.2. Настройте параметры DPD (deep peer detection):
Hub1(config)#crypto isakmp keepalive 3 2
Hub1(config)#crypto isakmp keepalive retry-count 5
Пояснение:
Если в течение 3 секунд отсутствует входящий трафик в IPsec туннеле, то с интервалом в 2 секунды посылается 5 keepalive пакетов в рамках IKE туннеля, чтобы удостовериться в работоспособности туннеля. Если партнер не отвечает на keepalive пакеты, то соответствующий IKE туннель и связанные с ним IPsec туннели уничтожаются. В случае наличия исходящего защищаемого трафика происходит попытка создания новых IKE/IPsec туннелей.
1.3. Включите фрагментацию IKE пакетов:
Hub1(config)#crypto isakmp fragmentation
1.4. Включите случайный разброс времени жизни IKE и IPsec SA, чтобы снизить нагрузку на шлюз (позволяет избежать единовременное массовое пересоздания SA):
Hub1(config)#crypto isakmp security-association lifetime delta 50
1.5. Увеличьте допустимое количество одновременно инициируемых IKE сессий (не путать с общим количеством IKE сессий) для всех партнёров (значение по умолчанию 30):
Hub1(config)#crypto isakmp initiator-sessions-max 100
1.6. Увеличьте допустимое количество одновременных IKE обменов, проводимых шлюзом со всеми партнерами в качестве ответчика (не путать с общим количеством IKE сессий; значение по умолчанию 20):
Hub1(config)#crypto isakmp responder-sessions-max 100
1.7. Создайте политику, описывающую параметры IKE туннеля:
Hub1(config)#crypto isakmp policy 1
Hub1(config-isakmp)# encryption gost
Hub1(config-isakmp)# hash gost341112-256-tc26
Hub1(config-isakmp)# authentication gost-sig
Hub1(config-isakmp)# group vko2
Hub1(config-isakmp)# exit
Рекомендуется использовать одну политику для IKE туннелей. Несколько политик может потребоваться в том случае, если необходимо обеспечить совместимость со старыми версиями Продуктов, в которых нет поддержки новых алгоритмов.
2. Параметры IPsec.
2.1. Задайте комбинированный алгоритм шифрования и имитозащиты (набор преобразований) для трафика:
Hub1(config)# crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit
Hub1(cfg-crypto-trans)#exit
2.2. Создайте список доступа (ACL) для трафика, который нужно защищать между центральным офисом и филиалом (в данном сценарии это инкапсулированный модулем «С-Терра L2» трафик):
Hub1(config)#ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1
Hub1(config-ext-nacl)#remark VLAN ID 0
Hub1(config-ext-nacl)#permit udp host 172.16.100.2 eq 50000 host 172.16.1.2 eq 50000
Hub1(config-ext-nacl)#remark VLAN ID 10
Hub1(config-ext-nacl)#permit udp host 172.16.100.2 eq 50001 host 172.16.1.2 eq 50001
Hub1(config-ext-nacl)#exit
Hub1(config)#
2.3. Создайте крипто-карту (имя VPN, раздел 1):
Hub1(config)#crypto map VPN 1 ipsec-isakmp
2.3.1 Укажите список доступа для защищаемого трафика:
Hub1(config-crypto-map)# match address IPSEC_ACl_HUB1_AND_SPOKE1
2.3.2 Укажите при помощи какого набора алгоритмов нужно защищать трафик:
Hub1(config-crypto-map)# set transform-set GOST_ENCRYPT_AND_INTEGRITY
2.3.3 Укажите IP адрес партнера по IPsec, в данном сценарии это внешний IP адрес устройства Spoke1:
Hub1(config-crypto-map)# set peer 172.16.1.2
2.3.4 Увеличьте лимит по трафику до максимального значения для IPsec SA:
Hub1(config-crypto-map)#set security-association lifetime kilobytes 4294967295
2.3.5 Обязательно отключите историю удаленных туннелей (если не отключить, то могут быть проблемы с построением IPsec туннелей с устройствами, которые находятся за NAT):
Hub1(config-crypto-map)# set dead-connection history off
Hub1(config-crypto-map)#exit
2.4. Прикрепите созданную крипто-карту VPN к внешнему интерфейсу GigabitEthernet0/0:
Hub1(config)#interface GigabitEthernet0/0
Hub1(config-if)# crypto map VPN
2.5. Примените настройки:
Hub1(config-if)#end
В целях безопасности настоятельно рекомендуется включать проверку списков отзыва сертификатов. Разностные списки отозванных сертификатов (delta CRL) не поддерживаются.
1. Включите проверку СОС:
Hub1#configure terminal
Hub1(config)# crypto pki trustpoint s-terra_technological_trustpoint
Hub1(ca-trustpoint)# revocation-check crl
Если по обоснованным причинам использование СОС невозможно, то выключите проверку СОС и не включайте автоматическую загрузку СОС:
Hub1(ca-trustpoint)# revocation-check none
2. Включите автоматическую загрузку и импортирование в базу Продукта списка отозванных сертификатов с HTTP сервера CRL_distribution_point:
Hub1(ca-trustpoint)# crl download group ROOTCA http://172.16.101.15/certcrl.crl
3. Настройте периодичность загрузки СОС в 60 минут (по умолчанию 24 часа):
Hub1(ca-trustpoint)# crl download time 60
4. Примените настройки:
Hub1(ca-trustpoint)#end
5. Проверьте загружен ли СОС в базу Продукта:
Hub1#run cert_mgr show
Found 2 certificates. Found 1 CRL.
1 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1
3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Если СОС не загрузился, то проверьте файл журнала, например:
Hub1#run grep getcrls_daemon /var/log/cspvpngate.log
Примечание: чтобы не ждать следующего периода загрузки СОС можно перезапустить сервис getcrls вручную:
Hub1#run systemctl restart getcrls.service
6. Выполните проверку статуса сертификатов в базе Продукта:
Hub1#run cert_mgr check
1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1
Настройка криптошлюза Hub1 завершена.
В Приложении представлены тексты конфигураций для криптошлюза Hub1:
· текст консоли cisco-like;
· текст LSP;
· конфигурация «С-Терра L2».
Настройка криптошлюза Spoke1 происходит аналогично настройке Hub1.
В Приложении представлены тексты конфигураций для криптошлюза Spoke1:
· текст консоли cisco-like;
· текст LSP;
· конфигурация «С-Терра L2».
Проверку работоспособности нужно выполнять после завершения настройки всех устройств стенда.
1. Проверьте, что с криптошлюзов Hub1 и Spoke1 по ICMP доступен шлюз по умолчанию (Router1). Для этого выполните команду ping из cisco-like консоли криптошлюзов.
Hub1#ping 172.16.100.1
PING 172.16.100.1 (172.16.100.1) 100(128) bytes of data.
108 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=0.918 ms
108 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=0.250 ms
108 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=0.306 ms
108 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=0.225 ms
108 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=0.238 ms
--- 172.16.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4081ms
rtt min/avg/max/mdev = 0.225/0.387/0.918/0.267 ms
Spoke1#ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 100(128) bytes of data.
108 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=0.771 ms
108 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=0.282 ms
108 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=0.276 ms
108 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=0.268 ms
108 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=0.244 ms
--- 172.16.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4096ms
rtt min/avg/max/mdev = 0.244/0.368/0.771/0.202 ms
Видно, что устройство Router1 доступно по ICMP как с Hub1, так и со Spoke1.
2. Проверьте, что с криптошлюза Hub1 доступен по ICMP криптошлюз Spoke1 (по внешним интерфейсам). Для этого выполните команду ping из cisco-like консоли криптошлюзов.
Hub1#ping 172.16.1.2
PING 172.16.1.2 (172.16.1.2) 100(128) bytes of data.
108 bytes from 172.16.1.2: icmp_seq=1 ttl=63 time=0.802 ms
108 bytes from 172.16.1.2: icmp_seq=2 ttl=63 time=0.416 ms
108 bytes from 172.16.1.2: icmp_seq=3 ttl=63 time=0.449 ms
108 bytes from 172.16.1.2: icmp_seq=4 ttl=63 time=0.393 ms
108 bytes from 172.16.1.2: icmp_seq=5 ttl=63 time=0.485 ms
--- 172.16.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4083ms
rtt min/avg/max/mdev = 0.393/0.509/0.802/0.149 ms
Видно, что с криптошлюза Hub1 доступен по ICMP криптошлюз Spoke1.
3. Проверьте, что с защищаемых устройств host0-behind-hub1, host1-behind-hub1 доступны по ICMP IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Hub1. Для этого выполните команду ping из linux bash консоли защищаемых устройств.
root@host0-behind-hub1:~# ping 192.168.100.1 -c 5
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=2.78 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.685 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.667 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=0.648 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=0.720 ms
--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 0.648/1.100/2.783/0.842 ms
root@host1-behind-hub1:~# ping 192.168.101.1 -c 5
PING 192.168.101.1 (192.168.101.1) 56(84) bytes of data.
64 bytes from 192.168.101.1: icmp_seq=1 ttl=64 time=1.90 ms
64 bytes from 192.168.101.1: icmp_seq=2 ttl=64 time=0.419 ms
64 bytes from 192.168.101.1: icmp_seq=3 ttl=64 time=0.403 ms
64 bytes from 192.168.101.1: icmp_seq=4 ttl=64 time=0.663 ms
64 bytes from 192.168.101.1: icmp_seq=5 ttl=64 time=0.608 ms
--- 192.168.101.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 0.403/0.799/1.902/0.560 ms
Видно, что с устройств host0-behind-hub1, host1-behind-hub1 доступны по ICMP соответствующие IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Hub1.
4. Проверьте, что с защищаемых устройств host0-behind-spoke1, host1-behind-spoke1 доступны по ICMP IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Spoke1. Для этого выполните команду ping из linux bash консоли защищаемых устройств.
root@host0-behind-spoke1:~# ping 192.168.100.2 -c 5
PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data.
64 bytes from 192.168.100.2: icmp_seq=1 ttl=64 time=1.55 ms
64 bytes from 192.168.100.2: icmp_seq=2 ttl=64 time=0.558 ms
64 bytes from 192.168.100.2: icmp_seq=3 ttl=64 time=0.585 ms
64 bytes from 192.168.100.2: icmp_seq=4 ttl=64 time=0.544 ms
64 bytes from 192.168.100.2: icmp_seq=5 ttl=64 time=0.546 ms
--- 192.168.100.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 0.544/0.755/1.546/0.396 ms
root@host1-behind-spoke1:~# ping 192.168.101.2 -c 5
PING 192.168.101.2 (192.168.101.2) 56(84) bytes of data.
64 bytes from 192.168.101.2: icmp_seq=1 ttl=64 time=0.628 ms
64 bytes from 192.168.101.2: icmp_seq=2 ttl=64 time=0.501 ms
64 bytes from 192.168.101.2: icmp_seq=3 ttl=64 time=0.583 ms
64 bytes from 192.168.101.2: icmp_seq=4 ttl=64 time=0.719 ms
64 bytes from 192.168.101.2: icmp_seq=5 ttl=64 time=0.674 ms
--- 192.168.101.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 0.501/0.621/0.719/0.075 ms
Видно, что с устройств host0-behind-spoke1, host1-behind-spoke1 доступны по ICMP соответствующие IP адреса, заданные на интерфейсах коммутаторов (br0 и br1) криптошлюза Spoke1.
1. Проверьте, что на криптошлюзах Hub1 и Spoke1 СОС импортирован в базу Продукта. Для этого выполните команду run cert_mgr show из cisco-like консоли криптошлюзов.
Hub1#run cert_mgr show
Found 2 certificates. Found 1 CRL.
1 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1
2 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Spoke1#run cert_mgr show
Found 2 certificates. Found 1 CRL.
1 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Spoke1
3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Видно, что на криптошлюзах Hub1 и Spoke1 СОС импортирован в базу Продукта. Если этого не произошло, то проверьте файл журнала (команда run grep getcrls_daemon /var/log/cspvpngate.log) и, при необходимости, перезапустите сервис автоматической загрузки СОС (команда run systemctl restart getcrls.service).
2. Проверьте, что на криптошлюзах Hub1 и Spoke1 статус всех сертификатов Active. Для этого выполните команду run cert_mgr check из cisco-like консоли криптошлюзов.
Hub1#run cert_mgr check
1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Hub1
2 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Spoke1#run cert_mgr check
1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=Spoke1
Видно, что на криптошлюзах Hub1 и Spoke1 статус всех сертификатов Active. Если статус Inactive, то проверьте загружен ли СОС в базу Продукта и правильность установки даты и времени.
IPsec туннели могут быть построены автоматически при наличии трафика, например широковещательного.
1. Инициируйте построение защищенного соединения между криптошлюзами Hub1 и Spoke1 для Native VLAN при помощи ICMP трафика, посылаемого с устройства host0-behind-spoke1 на host0-behind-hub1 (можно и наоборот). Для этого выполните команду ping из linux bash консоли защищаемого устройства host0-behind-spoke1.
root@host0-behind-spoke1:~# ping 192.168.100.100 -c 5
PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data.
64 bytes from 192.168.100.100: icmp_seq=1 ttl=64 time=6.70 ms
64 bytes from 192.168.100.100: icmp_seq=2 ttl=64 time=3.97 ms
64 bytes from 192.168.100.100: icmp_seq=3 ttl=64 time=3.69 ms
64 bytes from 192.168.100.100: icmp_seq=4 ttl=64 time=2.44 ms
64 bytes from 192.168.100.100: icmp_seq=5 ttl=64 time=2.61 ms
--- 192.168.100.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 2.442/3.882/6.700/1.529 ms
2. Инициируйте построение защищенного соединения между криптошлюзами Hub1 и Spoke1 для VLAN ID 10 при помощи ICMP трафика, посылаемого с устройства host1-behind-spoke1 на host1-behind-hub1 (можно и наоборот). Для этого выполните команду ping из linux bash консоли защищаемого устройства host1-behind-spoke1.
root@host1-behind-spoke1:~# ping 192.168.101.100 -c 5
PING 192.168.101.100 (192.168.101.100) 56(84) bytes of data.
64 bytes from 192.168.101.100: icmp_seq=1 ttl=64 time=4.43 ms
64 bytes from 192.168.101.100: icmp_seq=2 ttl=64 time=3.70 ms
64 bytes from 192.168.101.100: icmp_seq=3 ttl=64 time=3.45 ms
64 bytes from 192.168.101.100: icmp_seq=4 ttl=64 time=2.47 ms
64 bytes from 192.168.101.100: icmp_seq=5 ttl=64 time=2.63 ms
--- 192.168.101.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 2.473/3.336/4.428/0.719 ms
3. Проверьте, что на криптошлюзах Hub1 и Spoke1 установлены защищенные IPsec соединения. Для этого выполните команду run sa_mgr show из cisco-like консоли криптошлюзов.
Hub1#run sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 2 (172.16.100.2,500)-(172.16.1.2,500) active 2292 2500
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.100.2,50000)-(172.16.1.2,50000) 17 ESP tunn 904 880
2 4 (172.16.100.2,50001)-(172.16.1.2,50001) 17 ESP tunn 904 984
Spoke1#run sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 2 (172.16.1.2,500)-(172.16.100.2,500) active 2500 2292
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.1.2,50000)-(172.16.100.2,50000) 17 ESP tunn 880 904
2 4 (172.16.1.2,50001)-(172.16.100.2,50001) 17 ESP tunn 984 904
Видно, что на криптошлюзах Hub1 и Spoke1 установлены защищенные IPsec соединения. Если этого не произошло, то проверьте файл журнала (команда run less /var/log/cspvpngate.log). При необходимости увеличьте уровень логирования (команда logging trap debugging в консоли cisco-like) и заново инициируйте защищенное соединение.
Для дополнительной диагностики можно воспользоваться утилитой tcpdump на нужных интерфейсах (например tcpdump -i tap0 -n -e -vvv).
1. Консоль cisco-like:
!
version 12.4
no service password-encryption
!
crypto ipsec df-bit copy
crypto isakmp identity dn
crypto isakmp fragmentation
crypto isakmp security-association lifetime delta 50
crypto isakmp initiator-sessions-max 100
crypto isakmp responder-sessions-max 100
crypto isakmp keepalive 3
crypto isakmp keepalive retry-count 5
username cscons privilege 15 secret 5 $6$S5mhfJOq$ytq22Q8uIXimGTo6HjkDRQIo/9NR3
P/Uf0zx3eyPHSHky2ITEhSlFyHQtqixnnJxQtHDzVU9PBuC0Svb.kGAb0
aaa new-model
!
!
hostname Hub1
enable secret 5 X03MO1qnZdYdgyfeuILPmQ==
!
!
!
!
!
crypto isakmp policy 1
encr gost
hash gost341112-256-tc26
authentication gost-sig
group vko2
!
crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit
!
ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1
remark VLAN ID 0
permit udp host 172.16.100.2 eq 50000 host 172.16.1.2 eq 50000
remark VLAN ID 10
permit udp host 172.16.100.2 eq 50001 host 172.16.1.2 eq 50001
!
!
crypto map VPN 1 ipsec-isakmp
match address IPSEC_ACl_HUB1_AND_SPOKE1
set transform-set GOST_ENCRYPT_AND_INTEGRITY
set security-association lifetime kilobytes 4294967295
set peer 172.16.1.2
set dead-connection history off
!
interface GigabitEthernet0/0
ip address 172.16.100.2 255.255.255.0
crypto map VPN
!
interface GigabitEthernet0/1
no ip address
!
interface GigabitEthernet0/1.10
no ip address
!
interface GigabitEthernet0/2
no ip address
shutdown
!
!
ip route 0.0.0.0 0.0.0.0 172.16.100.1
!
crypto pki trustpoint s-terra_technological_trustpoint
revocation-check crl
crl download group ROOTCA http://172.16.101.15/certcrl.crl
crl download time 60
crypto pki certificate chain s-terra_technological_trustpoint
certificate 58E026BFD6D625BE4582C16C6189C183
...
AD4F8901771632E0A0AF83
quit
!
end
2. Конфигурация LSP:
# This is automatically generated LSP
#
# Conversion Date/Time: Wed Mar 4 04:31:58 2020
GlobalParameters(
Title = "This LSP was automatically generated by CSP Converter at Wed Mar 4 04:31:58 2020 (user: cscons)"
Version = LSP_4_3
CRLHandlingMode = ENABLE
PreserveIPsecSA = FALSE
)
RoutingTable(
Routes =
Route(
Destination = 0.0.0.0/0
Gateway = 172.16.100.1
)
)
FirewallParameters(
TCPSynSentTimeout = 30
TCPFinTimeout = 5
TCPClosedTimeout = 30
TCPSynRcvdTimeout = 30
TCPEstablishedTimeout = 3600
TCPHalfOpenLow = 400
TCPHalfOpenMax = 500
TCPSessionRateLow = 400
TCPSessionRateMax = 500
)
IKETransform crypto:isakmp:policy:1
(
CipherAlg = "G2814789CPRO1-K256-CBC-65534"
HashAlg = "GR341112_256TC26-65128"
GroupID = VKO2_1B
RestrictAuthenticationTo = GOST_SIGN
LifetimeSeconds = 86400
)
ESPProposal GOST_ENCRYPT_AND_INTEGRITY:ESP
(
Transform* = ESPTransform
(
CipherAlg* = "G2814789CPRO2-K288-CNTMAC-253"
LifetimeSeconds = 3600
LifetimeKilobytes = 4294967295
)
)
IKEParameters(
FragmentSize = 576
SALifetimeDelta = 50
InitiatorSessionsMax = 100
ResponderSessionsMax = 100
)
AuthMethodGOSTSign GOST:Sign
(
LocalID = IdentityEntry( DistinguishedName* = USER_SPECIFIC_DATA )
SendRequestMode = ALWAYS
SendCertMode = ALWAYS
)
IKERule IKERule:VPN:1
(
IKEPeerIPFilter = 172.16.1.2
Transform = crypto:isakmp:policy:1
AggrModeAuthMethod = GOST:Sign
MainModeAuthMethod = GOST:Sign
DPDIdleDuration = 3
DPDResponseDuration = 2
DPDRetries = 5
Priority = 10
)
IPsecAction IPsecAction:VPN:1
(
TunnelingParameters = TunnelEntry(
PeerAddress = 172.16.1.2
DFHandling=COPY
Assemble=TRUE
)
ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )
NoDeadConnectionHistory = TRUE
IKERule = IKERule:VPN:1
)
FilterChain IPsecPolicy:VPN (
Filters = Filter (
ProtocolID = 17
SourcePort = 500, 4500
Action = PASS
PacketType = LOCAL_UNICAST, LOCAL_MISDIRECTED
),
Filter (
SourceIP = 172.16.100.2
DestinationIP = 172.16.1.2
ProtocolID = 17
SourcePort = 50000
DestinationPort = 50000
Action = PASS
ExtendedAction = ipsec< sa = IPsecAction:VPN:1 >
LogEventID = "IPsec:Protect:VPN:1:IPSEC_ACl_HUB1_AND_SPOKE1"
),
Filter (
SourceIP = 172.16.100.2
DestinationIP = 172.16.1.2
ProtocolID = 17
SourcePort = 50001
DestinationPort = 50001
Action = PASS
ExtendedAction = ipsec< sa = IPsecAction:VPN:1 >
LogEventID = "IPsec:Protect:VPN:1:IPSEC_ACl_HUB1_AND_SPOKE1"
)
)
NetworkInterface (
LogicalName = "GigabitEthernet0/0"
IPsecPolicy = IPsecPolicy:VPN
)
3. Конфигурация «С-Терра L2».
3.1. Файл /opt/l2svc/etc/to_spoke1_nvlan.conf:
vif tap0
bridge br0
bridge_ip 192.168.100.1/24
capture eth1
local 172.16.100.2
remote 172.16.1.2
port 50000
mssfix 1400
passtos
3.2. Файл /opt/l2svc/etc/to_spoke1_vlan10.conf:
vif tap1
bridge br1
bridge_ip 192.168.101.1/24
capture eth1.10
local 172.16.100.2
remote 172.16.1.2
port 50001
mssfix 1400
passtos
1. Консоль cisco-like:
!
version 12.4
no service password-encryption
!
crypto ipsec df-bit copy
crypto isakmp identity dn
crypto isakmp fragmentation
crypto isakmp security-association lifetime delta 50
crypto isakmp initiator-sessions-max 100
crypto isakmp responder-sessions-max 100
crypto isakmp keepalive 3
crypto isakmp keepalive retry-count 5
username cscons privilege 15 secret 5 $6$ERU2T4tE$pkBMDQv/riN3PMxYrd6qksnU2inW9
a.drmpKw8Nh27qsbq/WE4VwZK46v56yFTtZ490gvX4HjdAkvGzGmomqr1
aaa new-model
!
!
hostname Spoke1
enable secret 5 X03MO1qnZdYdgyfeuILPmQ==
!
!
!
!
!
crypto isakmp policy 1
encr gost
hash gost341112-256-tc26
authentication gost-sig
group vko2
!
crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit
!
ip access-list extended IPSEC_ACl_HUB1_AND_SPOKE1
remark VLAN ID 0
permit udp host 172.16.1.2 eq 50000 host 172.16.100.2 eq 50000
remark VLAN ID 10
permit udp host 172.16.1.2 eq 50001 host 172.16.100.2 eq 50001
!
!
crypto map VPN 1 ipsec-isakmp
match address IPSEC_ACl_HUB1_AND_SPOKE1
set transform-set GOST_ENCRYPT_AND_INTEGRITY
set security-association lifetime kilobytes 4294967295
set peer 172.16.100.2
set dead-connection history off
!
interface GigabitEthernet0/0
ip address 172.16.1.2 255.255.255.0
crypto map VPN
!
interface GigabitEthernet0/1
no ip address
!
interface GigabitEthernet0/1.10
no ip address
!
interface GigabitEthernet0/2
no ip address
shutdown
!
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
crypto pki trustpoint s-terra_technological_trustpoint
revocation-check crl
crl download group ROOTCA http://172.16.101.15/certcrl.crl
crl download time 60
crypto pki certificate chain s-terra_technological_trustpoint
certificate 58E026BFD6D625BE4582C16C6189C183
...
AD4F8901771632E0A0AF83
quit
!
end
2. Конфигурация LSP:
# This is automatically generated LSP
#
# Conversion Date/Time: Wed Mar 4 14:41:21 2020
GlobalParameters(
Title = "This LSP was automatically generated by CSP Converter at Wed Mar 4 14:41:21 2020 (user: cscons)"
Version = LSP_4_3
CRLHandlingMode = ENABLE
PreserveIPsecSA = FALSE
)
RoutingTable(
Routes =
Route(
Destination = 0.0.0.0/0
Gateway = 172.16.1.1
)
)
FirewallParameters(
TCPSynSentTimeout = 30
TCPFinTimeout = 5
TCPClosedTimeout = 30
TCPSynRcvdTimeout = 30
TCPEstablishedTimeout = 3600
TCPHalfOpenLow = 400
TCPHalfOpenMax = 500
TCPSessionRateLow = 400
TCPSessionRateMax = 500
)
IKETransform crypto:isakmp:policy:1
(
CipherAlg = "G2814789CPRO1-K256-CBC-65534"
HashAlg = "GR341112_256TC26-65128"
GroupID = VKO2_1B
RestrictAuthenticationTo = GOST_SIGN
LifetimeSeconds = 86400
)
ESPProposal GOST_ENCRYPT_AND_INTEGRITY:ESP
(
Transform* = ESPTransform
(
CipherAlg* = "G2814789CPRO2-K288-CNTMAC-253"
LifetimeSeconds = 3600
LifetimeKilobytes = 4294967295
)
)
IKEParameters(
FragmentSize = 576
SALifetimeDelta = 50
InitiatorSessionsMax = 100
ResponderSessionsMax = 100
)
AuthMethodGOSTSign GOST:Sign
(
LocalID = IdentityEntry( DistinguishedName* = USER_SPECIFIC_DATA )
SendRequestMode = ALWAYS
SendCertMode = ALWAYS
)
IKERule IKERule:VPN:1
(
IKEPeerIPFilter = 172.16.100.2
Transform = crypto:isakmp:policy:1
AggrModeAuthMethod = GOST:Sign
MainModeAuthMethod = GOST:Sign
DPDIdleDuration = 3
DPDResponseDuration = 2
DPDRetries = 5
Priority = 10
)
IPsecAction IPsecAction:VPN:1
(
TunnelingParameters = TunnelEntry(
PeerAddress = 172.16.100.2
DFHandling=COPY
Assemble=TRUE
)
ContainedProposals = ( GOST_ENCRYPT_AND_INTEGRITY:ESP )
NoDeadConnectionHistory = TRUE
IKERule = IKERule:VPN:1
)
FilterChain IPsecPolicy:VPN (
Filters = Filter (
ProtocolID = 17
SourcePort = 500, 4500
Action = PASS
PacketType = LOCAL_UNICAST, LOCAL_MISDIRECTED
),
Filter (
SourceIP = 172.16.1.2
DestinationIP = 172.16.100.2
ProtocolID = 17
SourcePort = 50000
DestinationPort = 50000
Action = PASS
ExtendedAction = ipsec< sa = IPsecAction:VPN:1 >
LogEventID = "IPsec:Protect:VPN:1:IPSEC_ACl_HUB1_AND_SPOKE1"
),
Filter (
SourceIP = 172.16.1.2
DestinationIP = 172.16.100.2
ProtocolID = 17
SourcePort = 50001
DestinationPort = 50001
Action = PASS
ExtendedAction = ipsec< sa = IPsecAction:VPN:1 >
LogEventID = "IPsec:Protect:VPN:1:IPSEC_ACl_HUB1_AND_SPOKE1"
)
)
NetworkInterface (
LogicalName = "GigabitEthernet0/0"
IPsecPolicy = IPsecPolicy:VPN
)
3. Конфигурация «С-Терра L2».
3.1. Файл /opt/l2svc/etc/to_hub1_nvlan.conf:
vif tap0
bridge br0
bridge_ip 192.168.100.2/24
capture eth1
local 172.16.1.2
remote 172.16.100.2
port 50000
mssfix 1400
passtos
3.2. Файл /opt/l2svc/etc/to_hub1_vlan10.conf:
vif tap1
bridge br1
bridge_ip 192.168.101.2/24
capture eth1.10
local 172.16.1.2
remote 172.16.100.2
port 50001
mssfix 1400
passtos