🥇1.5 схеми на вітчизняному IPsec VPN. Тестую демоверсії

Ситуація

Я одержав демоверсію продуктів С-Терра 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, навпаки:

Виправити список доступу для шифрування – цільовий трафік з 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:

Висновок: IPsec-over-GRE працює коректно.

Підсумки

Однієї чашки кави вистачило. Накидав інструкцію щодо отримання демоверсії. Налаштував GRE-over-IPsec та розгорнув навпаки.

Карта інтерфейсів у версії 4.3 автоматична! Тестую далі.

Анонімний інженер
t.me/anonimous_engineer

Джерело: habr.com

1.5 схеми на вітчизняному IPsec VPN. Тестую демоверсії

Ситуація

Як отримати демоверсію

Розгортаю образ

Карта інтерфейсів мережі. Стало легше

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

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

Підсумки

Додати коментар або відгук Скасувати відповідь