[Информационная безопасность, Сетевые технологии, Сетевое оборудование] 1.5 схемы на отечественном IPsec VPN. Тестирую демоверсии
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Ситуация
Я получил демоверсию продуктов С-Терра VPN версии 4.3 на три месяца. Хочу разобраться, станет ли моя инженерная жизнь легче, после перехода на новую версию.
Сегодня не сложно, одного пакетика растворимого кофе 3 в 1 должно хватить. Расскажу, как получить демоверсии. Попробую собрать схемы GRE-over-IPsec и IPsec-over-GRE.
Как получить демоверсию
Из рисунка следует, чтобы получить демоверсию нужно:
- Написать письмо на presale@s-terra.ru с корпоративного адреса;
- В письме указать ИНН вашей организации;
- Перечислить продукты и их количество.
Демоверсии действуют три месяца. Вендор не ограничивает их функциональность.
Разворачиваю образ
Демоверсия шлюза безопасности – это образ виртуальной машины. Я использую VMWare Workstation. Полный список поддерживаемых гипервизоров и сред виртуализации размещен на сайте вендора.
Перед началом активных действий, обратите внимание, что в образе виртуальной машины по умолчанию нет сетевых интерфейсов:
Логика ясна, пользователь должен добавить столько интерфейсов, сколько ему нужно. Добавлю сразу четыре:
Теперь запускаю виртуальную машину. Сразу после запуска шлюз требует логин и пароль.
В С-Терра Шлюз несколько консолей с разными учетными записями. Посчитаю их количество в отдельной статье. А пока:
Login as: administrator
Password: s-terra
Инициализирую шлюз. Инициализация – это последовательность действий: ввод лицензии, настройка биологического генератора случайных чисел (клавиатурный тренажер – мой рекорд 27 секунд) и создание карты сетевых интерфейсов.
Карта сетевых интерфейсов. Стало легче
Версия 4.2 приветствовала активного пользователя сообщениями:
Starting IPsec daemon….. failed
ERROR: Could not establish connection with daemon
Активный пользователь (по версии анонимного инженера) – пользователь, способный настроить что угодно быстро и без документации.
Что-то шло не так, еще до попыток настроить IP адрес на интерфейсе. Все дело в карте сетевых интерфейсов. Нужно было выполнять:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
service networking restart
В результате создается карта сетевых интерфейсов, которая содержит маппинг имен физических интерфейсов (0000:02:03.0) и их логических обозначений в операционной системе (eth0) и Cisco-like консоли (FastEthernet0/0):
#Unique ID iface type OS name Cisco-like name
0000:02:03.0 phye eth0 FastEthernet0/0
Логические обозначения интерфейсов называются алиасами. Алиасы хранятся в файле /etc/ifaliases.cf.
В версии 4.3 при первом запуске виртуальной машины карта интерфейсов создается автоматически. Если вы меняете количество сетевых интерфейсов в виртуалке, то будьте добры создать карту интерфейсов заново:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl restart networking
Схема 1: GRE-over-IPsec
Разворачиваю два виртуальных шлюза, коммутирую так, как показано на рисунке:
Шаг 1. Настраиваю IP адреса и маршруты
VG1(config) #
interface fa0/0
ip address 172.16.1.253 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.1.253 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.254
VG2(config) #
interface fa0/0
ip address 172.16.1.254 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.2.254 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.253
Проверяю IP связность:
root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.545 ms
64 bytes from 172.16.1.254: icmp_seq=2 ttl=64 time=0.657 ms
64 bytes from 172.16.1.254: icmp_seq=3 ttl=64 time=0.687 ms
64 bytes from 172.16.1.254: icmp_seq=4 ttl=64 time=0.273 ms
--- 172.16.1.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms
Шаг 2. Настраиваю GRE
Пример настройки GRE беру из официальных сценариев. Создаю файл gre1 в директории /etc/network/interfaces.d с содержимым:
Для VG1:
auto gre1
iface gre1 inet static
address 1.1.1.1
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.254 local 172.16.1.253 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1
Для VG2:
auto gre1
iface gre1 inet static
address 1.1.1.2
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.253 local 172.16.1.254 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1
Поднимаю интерфейс в системе:
root@VG1:~# ifup gre1
root@VG2:~# ifup gre1
Проверяю:
root@VG1:~# ip address show
8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1
link/gre 172.16.1.253 peer 172.16.1.254
inet 1.1.1.1/30 brd 1.1.1.3 scope global gre1
valid_lft forever preferred_lft forever
root@VG1:~# ip tunnel show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre1: gre/ip remote 172.16.1.254 local 172.16.1.253 ttl 64 tos inherit key 1
В С-Терра Шлюз есть встроенный пакетный сниффер — tcpdump. Запишу дамп трафика в pcap файл:
root@VG2:~# tcpdump -i eth0 -w /home/dump.pcap
Запускаю ping между GRE интерфейсами:
root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms
GRE туннель активен и работает:
Шаг 3. Шифруем ГОСТом GRE
Задаю тип идентификации – по адресу. Аутентификация по предопределенному ключу (по Правилам Пользования нужно использовать цифровые сертификаты):
VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254
Задаю параметры IPsec Phase I:
VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2
Задаю параметры IPsec Phase II:
VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnel
Создаю список доступа для шифрования. Целевой трафик — GRE:
VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254
Создаю криптокарту и привязываю ее к WAN интерфейсу:
VG1(config)#
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 172.16.1.253
interface fa0/0
crypto map CMAP
Для VG2 конфигурация зеркальная, отличия:
VG2(config)#
crypto isakmp key KEY address 172.16.1.253
ip access-list extended LIST
permit gre host 172.16.1.254 host 172.16.1.253
crypto map CMAP 1 ipsec-isakmp
set peer 172.16.1.254
Проверяю:
root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcap
root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=1128 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=126 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.07 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.12 ms
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2
Статистика ISAKMP/IPsec:
root@VG1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 1 (172.16.1.253,500)-(172.16.1.254,500) active 1086 1014
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480
В дампе трафика GRE пакетов нет:
Вывод: схема GRE-over-IPsec корректно работает.
Схема 1.5: IPsec-over-GRE
Использовать IPsec-over-GRE в сети я не планирую. Собираю, потому что хочется.
Чтобы развернуть схему GRE-over-IPsec наоборот нужно:
- Исправить список доступа для шифрования – целевой трафик из LAN1 в LAN2 и наоборот;
- Настроить маршрутизацию через GRE;
- Повесить криптокарту на GRE интерфейс.
По умолчанию в Cisco-like консоли шлюза нет GRE интерфейса. Он существует только в операционной системе.
Добавляю GRE интерфейс в Cisco-like консоль. Для этого редактирую файл /etc/ifaliases.cf:
interface (name="FastEthernet0/0" pattern="eth0")
interface (name="FastEthernet0/1" pattern="eth1")
interface (name="FastEthernet0/2" pattern="eth2")
interface (name="FastEthernet0/3" pattern="eth3")
interface (name="Tunnel0" pattern="gre1")
interface (name="default" pattern="*")
где gre1 – обозначение интерфейса в операционной системе, Tunnel0 – обозначение интерфейса в Cisco-like консоли.
Пересчитываю хэш файла:
root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf
SUCCESS: Operation was successful.
Теперь интерфейс Tunnel0 появился в Cisco-like консоли:
VG1# show run
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
mtu 1400
Корректирую список доступа для шифрования:
VG1(config)#
ip access-list extended LIST
permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
Настраиваю маршрутизацию через GRE:
VG1(config)#
no ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 192.168.3.0 255.255.255.0 1.1.1.2
Снимаю криптокарту с Fa0/0 и привязываю к GRE интерфейсу:
VG1(config)#
interface Tunnel0
crypto map CMAP
Для VG2 аналогично.
Проверяю:
root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcap
root@VG1:~# ping 192.168.2.254 -I 192.168.1.253 -c 4
PING 192.168.2.254 (192.168.2.254) from 192.168.1.253 : 56(84) bytes of data.
64 bytes from 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms
64 bytes from 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms
64 bytes from 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms
--- 192.168.2.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms
Статистика ISAKMP/IPsec:
root@VG1:~# 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.253,500)-(172.16.1.254,500) active 1094 1022
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352
В дампе трафика ESP пакеты, инкапсулированные в GRE:
Вывод: Psec-over-GRE работает корректно.
Итоги
Одной чашки кофе хватило. Набросал инструкцию по получению демоверсии. Настроил GRE-over-IPsec и развернул наоборот.
Карта сетевых интерфейсов в версии 4.3 автоматическая! Тестирую дальше.
Анонимный инженер
t.me/anonimous_engineer
===========
Источник:
habr.com
===========
Похожие новости:
- [PostgreSQL] Павел Труханов. Мониторинг Postgres по USE и RED. Расшифровка с PGConf.Russia
- [Информационная безопасность] Удобные пароли для полиглотов
- [Информационная безопасность, Системы обмена сообщениями, Законодательство в IT, Социальные сети и сообщества] Трамп запретил жителям США «иметь какие-либо дела» с TikTok и WeChat
- [Информационная безопасность, Социальные сети и сообщества] Немного про кибербезопасность и «кожаных человеков» (с), т.е. нас с вами
- [Информационная безопасность, Антивирусная защита] Лечение или профилактика: как справиться с пандемией COVID-брендированных кибератак
- [Информационная безопасность, Разработка мобильных приложений] Защищаемся от трекеров на мобильных платформах
- [Информационная безопасность, Программирование, Администрирование баз данных, Хранение данных] Firebase снова стала предметом исследований
- [Информационная безопасность, IT-компании] Canon подверглась атаке вируса-вымогателя, сервисы компании частично восстановлены, потеряна часть архивов пользователей
- [Информационная безопасность, C, Реверс-инжиниринг, CTF] Работаем с Cutter — основы реверса. Решение задач на реверсинг с r0от-мi. Часть 3
- [IT-инфраструктура, Сетевые технологии, Asterisk, Сетевое оборудование] Микростота «Наше Всё» или DECT-мобильность на рабочем месте от Snom
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_setevye_tehnologii (Сетевые технологии), #_setevoe_oborudovanie (Сетевое оборудование), #_vpn, #_ipsec_vpn, #_gost_shifrovanie (ГОСТ шифрование), #_gre, #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_setevye_tehnologii (
Сетевые технологии
), #_setevoe_oborudovanie (
Сетевое оборудование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 16-Май 13:05
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
 Ситуация Я получил демоверсию продуктов С-Терра VPN версии 4.3 на три месяца. Хочу разобраться, станет ли моя инженерная жизнь легче, после перехода на новую версию. Сегодня не сложно, одного пакетика растворимого кофе 3 в 1 должно хватить. Расскажу, как получить демоверсии. Попробую собрать схемы GRE-over-IPsec и IPsec-over-GRE. Как получить демоверсию  Из рисунка следует, чтобы получить демоверсию нужно:
Демоверсии действуют три месяца. Вендор не ограничивает их функциональность. Разворачиваю образ Демоверсия шлюза безопасности – это образ виртуальной машины. Я использую VMWare Workstation. Полный список поддерживаемых гипервизоров и сред виртуализации размещен на сайте вендора. Перед началом активных действий, обратите внимание, что в образе виртуальной машины по умолчанию нет сетевых интерфейсов:  Логика ясна, пользователь должен добавить столько интерфейсов, сколько ему нужно. Добавлю сразу четыре:  Теперь запускаю виртуальную машину. Сразу после запуска шлюз требует логин и пароль. В С-Терра Шлюз несколько консолей с разными учетными записями. Посчитаю их количество в отдельной статье. А пока:
Login as: administrator Password: s-terra Инициализирую шлюз. Инициализация – это последовательность действий: ввод лицензии, настройка биологического генератора случайных чисел (клавиатурный тренажер – мой рекорд 27 секунд) и создание карты сетевых интерфейсов. Карта сетевых интерфейсов. Стало легче Версия 4.2 приветствовала активного пользователя сообщениями: Starting IPsec daemon….. failed ERROR: Could not establish connection with daemon Активный пользователь (по версии анонимного инженера) – пользователь, способный настроить что угодно быстро и без документации. Что-то шло не так, еще до попыток настроить IP адрес на интерфейсе. Все дело в карте сетевых интерфейсов. Нужно было выполнять: /bin/netifcfg enum > /home/map /bin/netifcfg map /home/map service networking restart В результате создается карта сетевых интерфейсов, которая содержит маппинг имен физических интерфейсов (0000:02:03.0) и их логических обозначений в операционной системе (eth0) и Cisco-like консоли (FastEthernet0/0): #Unique ID iface type OS name Cisco-like name 0000:02:03.0 phye eth0 FastEthernet0/0 Логические обозначения интерфейсов называются алиасами. Алиасы хранятся в файле /etc/ifaliases.cf. В версии 4.3 при первом запуске виртуальной машины карта интерфейсов создается автоматически. Если вы меняете количество сетевых интерфейсов в виртуалке, то будьте добры создать карту интерфейсов заново: /bin/netifcfg enum > /home/map /bin/netifcfg map /home/map systemctl restart networking Схема 1: GRE-over-IPsec Разворачиваю два виртуальных шлюза, коммутирую так, как показано на рисунке:  Шаг 1. Настраиваю IP адреса и маршруты VG1(config) # interface fa0/0 ip address 172.16.1.253 255.255.255.0 no shutdown interface fa0/1 ip address 192.168.1.253 255.255.255.0 no shutdown ip route 0.0.0.0 0.0.0.0 172.16.1.254 VG2(config) # interface fa0/0 ip address 172.16.1.254 255.255.255.0 no shutdown interface fa0/1 ip address 192.168.2.254 255.255.255.0 no shutdown ip route 0.0.0.0 0.0.0.0 172.16.1.253 Проверяю IP связность: root@VG1:~# ping 172.16.1.254 -c 4 PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data. 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.545 ms 64 bytes from 172.16.1.254: icmp_seq=2 ttl=64 time=0.657 ms 64 bytes from 172.16.1.254: icmp_seq=3 ttl=64 time=0.687 ms 64 bytes from 172.16.1.254: icmp_seq=4 ttl=64 time=0.273 ms --- 172.16.1.254 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms Шаг 2. Настраиваю GRE Пример настройки GRE беру из официальных сценариев. Создаю файл gre1 в директории /etc/network/interfaces.d с содержимым: Для VG1: auto gre1 iface gre1 inet static address 1.1.1.1 netmask 255.255.255.252 pre-up ip tunnel add gre1 mode gre remote 172.16.1.254 local 172.16.1.253 key 1 ttl 64 tos inherit pre-up ethtool -K gre1 tx off > /dev/null pre-up ip link set gre1 mtu 1400 post-down ip link del gre1 Для VG2: auto gre1 iface gre1 inet static address 1.1.1.2 netmask 255.255.255.252 pre-up ip tunnel add gre1 mode gre remote 172.16.1.253 local 172.16.1.254 key 1 ttl 64 tos inherit pre-up ethtool -K gre1 tx off > /dev/null pre-up ip link set gre1 mtu 1400 post-down ip link del gre1 Поднимаю интерфейс в системе: root@VG1:~# ifup gre1 root@VG2:~# ifup gre1 Проверяю: root@VG1:~# ip address show 8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1 link/gre 172.16.1.253 peer 172.16.1.254 inet 1.1.1.1/30 brd 1.1.1.3 scope global gre1 valid_lft forever preferred_lft forever root@VG1:~# ip tunnel show gre0: gre/ip remote any local any ttl inherit nopmtudisc gre1: gre/ip remote 172.16.1.254 local 172.16.1.253 ttl 64 tos inherit key 1 В С-Терра Шлюз есть встроенный пакетный сниффер — tcpdump. Запишу дамп трафика в pcap файл: root@VG2:~# tcpdump -i eth0 -w /home/dump.pcap Запускаю ping между GRE интерфейсами: root@VG1:~# ping 1.1.1.2 -c 4 PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data. 64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms 64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms 64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms 64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms --- 1.1.1.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3006ms rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms GRE туннель активен и работает:  Шаг 3. Шифруем ГОСТом GRE Задаю тип идентификации – по адресу. Аутентификация по предопределенному ключу (по Правилам Пользования нужно использовать цифровые сертификаты): VG1(config)# crypto isakmp identity address crypto isakmp key KEY address 172.16.1.254 Задаю параметры IPsec Phase I: VG1(config)# crypto isakmp policy 1 encr gost hash gost3411-256-tc26 auth pre-share group vko2 Задаю параметры IPsec Phase II: VG1(config)# crypto ipsec transform-set TSET esp-gost28147-4m-imit mode tunnel Создаю список доступа для шифрования. Целевой трафик — GRE: VG1(config)# ip access-list extended LIST permit gre host 172.16.1.253 host 172.16.1.254 Создаю криптокарту и привязываю ее к WAN интерфейсу: VG1(config)# crypto map CMAP 1 ipsec-isakmp match address LIST set transform-set TSET set peer 172.16.1.253 interface fa0/0 crypto map CMAP Для VG2 конфигурация зеркальная, отличия: VG2(config)# crypto isakmp key KEY address 172.16.1.253 ip access-list extended LIST permit gre host 172.16.1.254 host 172.16.1.253 crypto map CMAP 1 ipsec-isakmp set peer 172.16.1.254 Проверяю: root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcap root@VG1:~# ping 1.1.1.2 -c 4 PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data. 64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=1128 ms 64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=126 ms 64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.07 ms 64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.12 ms --- 1.1.1.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3006ms rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2 Статистика ISAKMP/IPsec: root@VG1:~# sa_mgr show ISAKMP sessions: 0 initiated, 0 responded ISAKMP connections: Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd 1 1 (172.16.1.253,500)-(172.16.1.254,500) active 1086 1014 IPsec connections: Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd 1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480 В дампе трафика GRE пакетов нет:  Вывод: схема GRE-over-IPsec корректно работает. Схема 1.5: IPsec-over-GRE Использовать IPsec-over-GRE в сети я не планирую. Собираю, потому что хочется.  Чтобы развернуть схему GRE-over-IPsec наоборот нужно:
По умолчанию в Cisco-like консоли шлюза нет GRE интерфейса. Он существует только в операционной системе. Добавляю GRE интерфейс в Cisco-like консоль. Для этого редактирую файл /etc/ifaliases.cf: interface (name="FastEthernet0/0" pattern="eth0") interface (name="FastEthernet0/1" pattern="eth1") interface (name="FastEthernet0/2" pattern="eth2") interface (name="FastEthernet0/3" pattern="eth3") interface (name="Tunnel0" pattern="gre1") interface (name="default" pattern="*") где gre1 – обозначение интерфейса в операционной системе, Tunnel0 – обозначение интерфейса в Cisco-like консоли. Пересчитываю хэш файла: root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf SUCCESS: Operation was successful. Теперь интерфейс Tunnel0 появился в Cisco-like консоли: VG1# show run interface Tunnel0 ip address 1.1.1.1 255.255.255.252 mtu 1400 Корректирую список доступа для шифрования: VG1(config)# ip access-list extended LIST permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255 Настраиваю маршрутизацию через GRE: VG1(config)# no ip route 0.0.0.0 0.0.0.0 172.16.1.254 ip route 192.168.3.0 255.255.255.0 1.1.1.2 Снимаю криптокарту с Fa0/0 и привязываю к GRE интерфейсу: VG1(config)# interface Tunnel0 crypto map CMAP Для VG2 аналогично. Проверяю: root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcap root@VG1:~# ping 192.168.2.254 -I 192.168.1.253 -c 4 PING 192.168.2.254 (192.168.2.254) from 192.168.1.253 : 56(84) bytes of data. 64 bytes from 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms 64 bytes from 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms 64 bytes from 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms 64 bytes from 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms --- 192.168.2.254 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3006ms rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms Статистика ISAKMP/IPsec: root@VG1:~# 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.253,500)-(172.16.1.254,500) active 1094 1022 IPsec connections: Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd 1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352 В дампе трафика ESP пакеты, инкапсулированные в GRE:  Вывод: Psec-over-GRE работает корректно. Итоги Одной чашки кофе хватило. Набросал инструкцию по получению демоверсии. Настроил GRE-over-IPsec и развернул наоборот. Карта сетевых интерфейсов в версии 4.3 автоматическая! Тестирую дальше. Анонимный инженер t.me/anonimous_engineer =========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ), #_setevye_tehnologii ( Сетевые технологии ), #_setevoe_oborudovanie ( Сетевое оборудование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 16-Май 13:05
Часовой пояс: UTC + 5