🥇1.5 схеми на роден IPsec VPN. Тестувам демоверсиите

Ситуация

Получих демоверсия на продуктите на С-Терра VPN версия 4.3 за три месеца. Искам да разбера дали моят инженерен живот ще стане по-лесен след преминаването на новата версия.

Днес не е трудно, един пакет разтворимо кафе 3 в 1 би трябвало да е достатъчен. Ще разкажа как да получа демоверсии. Ще опитам да събера GRE-over-IPsec и IPsec-over-GRE схеми.

Как да получа демоверсия

От изображението следва, че за да получите демоверсия, е необходимо:

Да напишете имейл на presale@s-terra.ru от корпоративния адрес;
В имейла да посочите ЕИК на вашата организация;
Да изброите продуктите и тяхното количество.

Демоверсиите са валидни три месеца. Вендорът не ограничава тяхната функционалност.

Разгръщам образа

Демоверсията на защитния шлюз е образ на виртуална машина. Използвам VMWare Workstation. Пълен списък на поддържаните хипервизори и виртуализационни среди е публикуван на сайта на вендора.

Преди да започнете активни действия, обърнете внимание, че образът на виртуалната машина по подразбиране няма мрежови интерфейси:

Логиката е ясна, потребителят трябва да добави толкова интерфейси, колкото му трябват. Ще добавя веднага четири:

Сега стартирам виртуалната машина. Незабавно след старта, шлюзът иска логин и парола.

В С-Терра Шлюз има няколко конзоли с различни акаунти. Ще преброя техния брой в отделна статия. А засега:
Влезте като: администратор Парола: s-terra

Инициализиране на шлюза. Инициализация – това е последователност от действия: въвеждане на лицензия, настройка на биологичен генератор на произволни числа (тренажор за клавиатура – моят рекорд е 27 секунди) и създаване на карта на мрежовите интерфейси.

Карта на мрежовите интерфейси. Стане ли по-лесно

Версия 4.2 поздравяваше активния потребител с съобщения:

Стартиране на IPsec демона... неуспешно ГРЕШКА: Не можа да се установи връзка с демона

Активен потребител (по версия на анонимен инженер) – потребител, способен да настрои всичко бързо и без документация.

Нещата не вървяха наред, още преди опитите за настройка на IP адрес на интерфейса. Всичко бе в картата на мрежовите интерфейси. Трябваше да се извърши:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map услуга мрежа рестартиране

В резултат се създава карта на мрежовите интерфейси, която съдържа мапинга на имената на физическите интерфейси (0000:02:03.0) и техните логически обозначения в операционната система (eth0) и Cisco-подобната конзола (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:  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 Фаза I:

VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2

Настройвам параметрите на IPsec Фаза 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) байта данни.
64 байта от 1.1.1.2: icmp_seq=1 ttl=64 време=1128 ms
64 байта от 1.1.1.2: icmp_seq=2 ttl=64 време=126 ms
64 байта от 1.1.1.2: icmp_seq=3 ttl=64 време=1.07 ms
64 байта от 1.1.1.2: icmp_seq=4 ttl=64 време=1.12 ms

--- статистика на ping за 1.1.1.2 ---
4 пакета изпратени, 4 получени, 0% загуба на пакети, време 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 сесии: 0 инициирани, 0 отговорени

ISAKMP връзки:
Num Conn-id (Локален адрес, Порт)-(Отдалечен адрес, Порт) Състояние Изпратени Получени
1 1 (172.16.1.253,500)-(172.16.1.254,500) активна 1086 1014

IPsec връзки:
Num Conn-id (Локален адрес, Порт)-(Отдалечен адрес, Порт) Протокол Действие Тип Изпратени Получени
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP тунел 480 480

В дампа на трафика няма GRE пакети:

Извод: схемата GRE-over-IPsec работи правилно.

Схема 1.5: IPsec-over-GRE

Не планирам да използвам IPsec-over-GRE в мрежата. Събирам, защото ми харесва.

За да развърна схемата GRE-over-IPsec в обратната посока, трябва:

Да коригирам списъка за достъп за криптиране – целевият трафик от LAN1 към LAN2 и обратно;
Да настроя маршрутизацията през GRE;
Да свържа криптокартата към GRE интерфейса.

По подразбиране в Cisco-подобната конзола на шлюза няма GRE интерфейс. Той съществува само в операционната система.

Добавям GRE интерфейс в Cisco-подобната конзола. За целта редактирам файла /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-подобната конзола.

Пресмятам хеша на файла:

root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf

УСПЕХ: Операцията беше успешна.

Сега интерфейс Tunnel0 се появи в Cisco-подобната конзола:

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) от 192.168.1.253 : 56(84) байта данни.
64 байта от 192.168.2.254: icmp_seq=1 ttl=64 време=492 ms
64 байта от 192.168.2.254: icmp_seq=2 ttl=64 време=1.08 ms
64 байта от 192.168.2.254: icmp_seq=3 ttl=64 време=1.06 ms
64 байта от 192.168.2.254: icmp_seq=4 ttl=64 време=1.07 ms

--- 192.168.2.254 ping статистика ---
4 пакета предадени, 4 получени, 0% загуба на пакети, време 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

Статистика на ISAKMP/IPsec:

root@VG1:~# sa_mgr show
ISAKMP сесии: 0 инициирани, 0 отговорени

ISAKMP връзки:
Num Conn-id (Локален Адрес,Порт)-(Отдалечен Адрес,Порт) Състояние Изпратени Получени
1 2 (172.16.1.253,500)-(172.16.1.254,500) активно 1094 1022

IPsec връзки:
Num Conn-id (Локален Адрес,Порт)-(Отдалечен Адрес,Порт) Протокол Действие Тип Изпратени Получени
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP тунел 352 352

В дампа на трафика ESP пакети, инкапсулирани в GRE:

Изход: IPsec-over-GRE работи коректно.