Русский
Русский
English
Статистика
Реклама

Gre

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

07.08.2020 12:20:56 | Автор: admin


Ситуация


Я получил демоверсию продуктов С-Терра 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
Подробнее..

Туннель под безопасностью и брокеры сетевых пакетов

25.08.2020 20:14:31 | Автор: admin
В современных сетях с виртуализацией и автоматизацией широкое применение получило туннелирование трафика. Однако, туннелирование ориентировано на построение сети и обеспечение надежной передачи данных, а вопросы информационной безопасности и мониторинга обычно остаются за скобками. Проблема невидимости туннелированного трафика для систем информационной безопасности давно известная проблема уже в 2011 году было опубликовано RFC 6169 Security Concerns with IP Tunneling, указывающее на потенциальные риски применения туннелей. Непосредственно средства DPI не отстают от инфраструктуры и уже давно разбирают туннели и смотрят пользовательский трафик (когда это в целом технически возможно), однако, остается узкое место передача данных из инфраструктуры на эти системы.

image


Туннелирование и передача трафика в системы мониторинга и информаицонной безопасности


GTP, GRE, L2TP, PPPoE, VXLAN и другие аббревиатуры туннелей знакомы любому сетевому инженеру. Туннелирование трафика позволяет:

  • Обеспечить управление потоками данных за счёт построения сети на 3 уровне модели OSI
  • Связывать удаленные офисы в единую сеть с общими ресурсами
  • Упрощать администрирование сети за счёт разделения на уровень инфраструктуры и уровень пользователей
  • Строить единые сети на базе различных технологий
  • Обеспечивать мобильность пользователей (мобильные сети, миграция виртуальных машин в дата-центрах)

Но применение туннелей накладывает дополнительные требования и в части обеспечения информационной безопасности.

Большая часть систем информационной безопасности и системы мониторинга работают с копией трафика. При этом передача данных из инфраструктуры обеспечивается одним из трех способов:

  1. Пакеты дублируются посредством дополнительных функций сетевого оборудования и отправляются в выделенные (SPAN) порты
  2. В оптическую линию устанавливаются пассивные ответвители трафика (TAP), разделяющие оптическую мощность на две линии изначальному получателю и в систему DPI
  3. В инфраструктуру добавляется брокер сетевых пакетов, выполняющий функцию зеркалирвания пакетов, как и в случае с TAP изначальному получателю и в систему DPI

Как мы уже писали раннее в современной инфраструктуре SPAN-порты практически не используются: они не обеспечивают ни требуемую пропускную способность, ни гарантию передачи данных. Туннели только усугубляют проблему: критерием передачи в порт мониторинга может быть только поля внешнего заголовка (заголовка туннелей) и таким образом предварительная фильтрация по полям пользовательских пакетов (вложенным заголовкам) становится невозможной.

Чаще всего применяется комбинация из пассивных оптических ответвителей и брокеров сетевых пакетов.

image


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

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


Без возможности анализа брокером сетевых пакетов вложенных заголовков туннелированных пакетов бессмысленно говорить об оптимизации средств DPI. Фильтрация и классификация, позволяющие снизить нагрузку на системы DPI и уменьшить их количество, должны работать именно по полям пользовательского трафика (вложенных заголовков). Иначе отделить IP-адреса конкретных пользователей, требуемые протоколы или шифрованный трафик невозможно по внешним полям это будет просто туннель. Попытка очистить трафик на системы DPI от нецелевого по внешним полям только создаст дыру в безопасности целевой трафик проскользнет мимо информационной безопасности и мониторинга в туннеле.

image


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

Балансировка туннелированного трафика


Еще более многогранна проблема балансировки туннелированного трафика. Во-первых, при распределении пользовательских пакетов между разными туннелями (в мобильных сетях, при резервировании с балансировкой нагрузки, да и просто при передаче прямого и обратного потока по разным туннелям) без анализа вложенных заголовков невозможно обеспечить целостность сессий пользовательского обмена.

image


Возьмём 2 сессии (AB-ВА и CD-DC) и передадим их через туннелированные каналы T1, T2 и T3. Допустим, речь идёт об абонентах мобильного оператора, гуляющих между базовыми станциями. Пакеты этих сессий окажутся в разных туннелях и при попадании туннелированного трафика на брокер сетевых пакетов есть 2 варианта их балансировки с сохранением целостности сессий:

  1. Балансировка по внешним заголовкам. Фактически брокер сетевых пакетов при этом разделит разные туннели между системами DPI: Т1 и Т3 в DPI 1, а Т2 в DPI 2. При этом пакеты запросов (AB) информационного потока AB-BA, инкапсулированные в туннели Т1 и Т2 для обеспечения мобильности абонента, оказываются в разных системах DPI, а пакеты ответов (BA) в туннелях Т2 и Т3, соответственно, попадут в DPI 1 и DPI 2. Аналогичная ситуация произойдет и с информационным потоком CD-DC. Большинство систем DPI для корректной работы требуют все данные информационного обмена. Декапсулируя трафик, каждая из систем DPI увидит обрывки информационного обмена, посчитает его не требующим обработки (как несостоявшегося) или обработает некорректно. Данная балансировка может быть интересна для мониторинга состояния отдельных участков инфраструктуры (когда в систему анализа на самом деле должны прийти именно все пакеты заданного туннеля), но для этого обычно используется фильтрация.
  2. Балансировка по вложенным заголовкам. Брокер сетевых пакетов для балансировки игнорирует внешние заголовки и распределяет пакеты между системами DPI с сохранением целостности сессий AB-BA и CD-DC. При этом для мониторинга состояния отдельных участков инфраструктуры можно настроить фильтрацию по внешним заголовкам. Таким образом каждое средство DPI получит цельный поток информационного обмена пользователей, а средства мониторинга все пакеты заданного туннеля.


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

image


То есть, если сессии AB и CD по 10 Гбит/с каждая инкапсулированы в туннель T1, то получается 20 Гбит/с трафика (которые могут передаваться по интерфейсу 40GbE/100GbE или через агрегированные каналы LAG 10GbE). После копирования и попадания данного потока в брокер сетевых пакетов возникает необходимость разбалансировать этот трафик на несколько систем DPI по интерфейсам 10 GbE. Сделать это с сохранением целостности сессий используя внешние заголовки невозможно поток превысит пропускную способность выходного интерфейса и пакеты начнут теряться.

Балансировка по вложенным заголовкам обеспечивает возможность разделить поток на более мелкие без ущерба для целостности информационного обмена и качества работы систем DPI.

Балансировка фрагментированного туннелированного трафика


Отдельной проблемой при балансировке является фрагментация трафика, вызванная туннелированием: добавление туннельных заголовков приводит к превышению MTU и фрагментации пакетов.

image


Когда на вход туннелирующего устройства приходит пакет с размером равным MTU, то после добавления туннельных заголовков пакет начинает MTU превышать (на количество байт туннельного заголовка) и делится на фрагменты. Причём вложенный заголовок содержится только в первом фрагменте. В результате два пакета одной сессии (AB1 и AB2), попавшие в разные туннели (T1 с заголовком XY и T2 с заголовком XZ) превращаются в четыре пакета:

  • с внешним заголовком XY и вложенным заголовком AB
  • с внешним заголовком XY без признаков туннелирования
  • с внешним заголовком XZ и вложенным заголовком AB
  • с внешним заголовком XZ без признаков туннелирования

В данном случае без функции отслеживания фрагментов выбор будет между нарушением целостности информационного потока из-за распределения разных туннелей между разными системами DPI и нарушением целостности информационного потока из-за распределения разных фрагментов между разными системами DPI. Отслеживание фрагментов с балансировкой по вложенным заголовкам обеспечивает сохранение целостности даже в таких случаях.

Столкнувшиеся с указанными проблемами в большой части трафика понимают их и решают. Как обычно хуже всего, когда проблема касается менее 10% трафика она может быть незаметна и создается иллюзия, что всё в безопасности. А под безопасностью туннель.
Подробнее..

Настройка IPsec GRE туннель между FortiOS 6.4.5 и RouterOS 6.48.1

10.03.2021 14:15:34 | Автор: admin

Стояла задача объединить филиалы с головным офисом предприятия, где находилась серверная. Fortigate 60E организовывал доступ в интернет и выполнял роль межсетевого экрана в головном офисе, в филиалах выполняли роль доступа в интернет Микротик разных моделей. Также было необходимо настроить динамическую маршрутизацию OSPF и поднять IPsec VPN туннели с GRE. Порыскав на просторах интернета, нашел пару разрозненных статей о соединении Fortigate c микротик через IPsec VPN и GRE туннель. Решил объединить эту информацию в одной своей статье, чтобы в дальнейшем самому использовать как шпаргалку. О динамической маршрутизации OSPF напишу в следующей статье.

Итак, входные данные:

1.Головной офис предприятия HQ FortiOS 6.4.5:

  • Публичный IP X.X.X.X (сетевой интерфейс port1)

  • Внутренняя сеть 192.168.111.0/24 (сетевой интерфейс port2)

2.Филиал предприятия Branch Mikrotik RouterOS 6.48.1:

  • Публичный IP Y.Y.Y.Y сетевой интерфейс ether1

  • Внутренняя сеть 192.168.112.0/24 (сетевой интерфейс ether2)

На рис. схематично показано подключение главного офиса и филиала.

Опущу основный настройки Fortigate и mikrotik, эта информация есть в интернете, сразу приступим к настройкам IPsec и GRE. Начнем настройку с mikrotik . Начнем с GRE, заходим утилитой Winbox на mikrotik в меню Interfaces->GRE Tunnel->+(нажимаем плюс, чтобы добавить туннель), за тем : - Local Address Y.Y.Y.Y - Remote Address X.X.X.X Укажем параметр "keepalive", который определяет находится ли туннель в рабочем состоянии. Если параметр не включен, то даже, если второй маршрутизатор будет выключен интерфейс все равно будет показывать рабочее состояние, что не удобно для диагностики. Использовать будем значение 10 попыток по 10 секунд. т. е., если в течении 100 секунд не будет никаких сигналов с противоположной стороны туннель перейдет в нерабочее состояние. При этом он автоматически включится, если противоположная сторона попытается установить соединение. В отличии от настройки GRE без IPsec в этой конфигурации должна быть отключена опция "Allow Fast Path", а параметр "Local Address:" является обязательным потому что без него не получится создать автоматические настройки IPsec. Если указать параметр IPsec Secret, то автоматически создадутся необходимые настройки IPsec. Но их поменять будет уже не возможно, поэтому не задаю параметр IPsec Secret.

Назначим IP адрес GRE-туннелю. Зайдем IP->Addresses->+

Команды консоли :

/interface greadd name=gre-tunnel1 keepalive=10s,10 local-address=Y.Y.Y.Y remote-address=X.X.X.X allow-fast-path=no/ip addressadd address=10.10.10.2/30 interface= gre-tunnel1

Настраиваем IPsec . Начнем с phase-1, идентификация устройств между собой, по заранее определенному IP адресу и ключу , настройки в IP->IPsec->Profiles.

Создаем Peer для phase-1, в IP->IPsec->Peers. Указываем имя name Branch-HQ, адрес удаленного FortiGate HQ, локальный адрес и profile1, который соответствует phase-1.

Теперь определяем ключ IPsec phase-1.

Настройка параметров phase-2, он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Идем IP->IPsec->Proposals

И создаем политики IPsec , IP->IPsec->Policies->General. Указываем имя Peer Branch-HQ, мы его настраивали выше. Src. Address внешний адрес нашего mikrotik Y.Y.Y.Y, Dst. Address внешний адрес FortiGate HQ X.X.X.X, и указываем протокол GRE в параметре Protocol - 47.

На вкладке Action выбираем Proposal porposal1, который мы тоже настраивали выше.

Настройка в консоли :

 /ip ipsec profileadd dh-group=modp1536,modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=24h name=profile1/ip ipsec peeradd address=X.X.X.X local-address=Y.Y.Y.Y name=Branch-HQ profile=profile1/ip ipsec proposaladd auth-algorithms=sha256 enc-algorithms= aes-256-cbc lifetime=30m name=proposal1 pfs-group=modp1536/ip ipsec policyadd peer=Branch-HQ src-address= Y.Y.Y.Y dst-address= X.X.X.X protocol=47 proposal=proposal1/ip ipsec identityadd peer=Branch-HQ secret=#!@BRaNCH@!#

Прописываем правила в файерволе IP->Firewall->Filter Rules:

В терминале :

/ip firewall filteradd chain=input protocol=17 dst-port=500,4500 in-interface=ether1 action=accept

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

/ip routeadd dst-address=192.168.111.0/24 gateway=10.10.10.1

На этом настройка mikrotik окончена , перейдем к настройки FortiGate.

На FortiGate настроим IPsec phase-1 в командной строке:

config vpn ipsec phase1-interface edit HQA-Branch set peertype any set proposal aes256-sha256 set dpd on-idle set dhgrp 5 14 set auto-discovery-sender enable set remote-gw Y.Y.Y.Y set psksecret #!@BRaNCH@!# set dpd-retryinterval 5 nextend

Phase-2 , не забываем указать protocol 47 и указать transport-mode (транспортный режим) для туннеля GRE:

config vpn ipsec phase2-interface edit "HQA-Branch" set phase1name "HQA-Branch" set proposal aes256-sha256 set dhgrp 5 14 set auto-negotiate enable set encapsulation transport-mode set protocol 47 nextend

Настроим GRE tunnel:

config system gre-tunnel edit "HQ-Branch" set interface "HQA-Branch" set remote-gw Y.Y.Y.Y set local-gw X.X.X.X nextend

Настроим локальный IP адрес туннельного интерфейса и укажем IP удаленного интерфейса:

config system interface edit "HQ-Branch" set ip 10.10.10.1 255.255.255.255 set remote-ip 10.10.10.2 255.255.255.252 set interface "HQA-Branch" nextend

Трафик GRE, который должен быть защищен IPsec, создается самостоятельно, он не принимается на интерфейсе. Следовательно, не требуется политика форвардинга, чтобы разрешить трафику GRE входить или выходить из интерфейса IPsec. Однако по замыслу FortiOS для согласования IPsec требуется политика форвардинга. Поэтому для активации IPsec используется произвольная политика форвардинга (например, от самого интерфейса IPsec и обратно).

config firewall policy edit 2 set name "Enable IPsec" set srcintf "HQA-Branch" set dstintf "HQA-Branch" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" next

Разрешим трафик из локальной сети головного офиса port2 в туннель GRE и наоборот:

config firewall policy     edit 3        set name "GRE HQ->Branch"        set srcintf "port2"        set dstintf "HQ-Branch"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    next    edit 4        set name "GRE Branch->HQ"        set srcintf "HQ-Branch"        set dstintf "port2"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    nextend

После туннелирования GRE, пакеты GRE должны быть защищены IPsec. Следовательно, remote-gw gre-tunnel должен указывать на интерфейс IPsec. Настраиваем статический маршрут:

config router static edit 1 set dst Y.Y.Y.Y/30 set device "HQA-Branch" next

Создадим статический маршрут до локальной сети филиала

edit 2        set dst 192.168.112.0 255.255.255.0        set device "HQ-Branch"    nextend

И теперь поднялся IPsec и GRE , трафик из локальной сети головного офиса попадает в локальную сеть филиала и наоборот.

Использовал следующие статьи:

1.Fortinet

2.Wiki Микротика

Это мой второй труд , прошу сильно не пинать.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru