Поиск по этому блогу

понедельник, 16 декабря 2019 г.

GRE over IPSec и конфуз с keepalive

Продолжая развитие туннельного соединения между компаниями А и Б (предыдущий пост здесь), защитим передаваемые данные применив шифрование. Наша топология:

Существует два термина которые часто ставят в тупик и заставляют проверять порядок формирования пакета - GRE over IPSec или IPSec over GRE. Чтобы запомнить следует читать over как внутри. Таким образом IPSec over GRE пакет выглядит так:
| New IP | | GRE | | IPSec | | Original IP | | DATA |

После применения шифрования, при перехвате трафика в транзитной сети (ISP 1 и 2)  доступны для просмотра только данные New IP и GRE. Все остальное будет показано как ESP.

Для шифрования будет использовать ipsec профиль как наиболее гибкое решение.
Рекомендую создать настройки сначала в блокноте для каждого устройства, а затем закинуть сразу на каждое устройство. 


Сначала создадим политику IKE фазы 1 (одинаково для обоих устройств):

crypto isakmp policy 10        #порядковый номер, политик может несколько
 encr aes 256                          #алгоритм шифрования с указание длины ключа
 authentication pre-share       #первичный ключ
 group 2                                 # DH группа для генерации секретного ключа

Можно создать набор таких политик, и тогда при установлении соединения они будут перебираться по очереди начиная с наименьшего.

Далее указываем первичный ключ для нашего туннеля:
COMPANY-A:
crypto isakmp key SECRET address 201.0.0.2
COMPANY-B:
crypto isakmp key SECRET address 101.0.0.2

Здесь мы указываем адреса WAN потому что именно они являются tunnel source для туннеля.
Первая фаза необходима для выработки защищенного соединения передачи служебного трафика второй фазы. 
Далее прописываем настройки второй фазы IKE при помощи которой и будут шифроваться передаваемые данные (одинаково для обоих устройств):

crypto ipsec transform-set TransformGRE esp-aes 256 esp-sha-hmac
 mode transport

Алгоритмы шифрования esp-aes 256 и хеширования esp-sha-hmac должны совпадать с первой фазой. Транспортный режим означает, что мы не добавляем новый заголовок IP, а шифруем блок данных.

Теперь создадим IPSec профиль с именем, где укажем данные второй фазы (одинаково для обоих устройств):
crypto ipsec profile TUN_A-B
 set transform-set TransformGRE

И последний шаг применение политики шифрования на интерфейсе (одинаково для обоих устройств):
interface Tunnel0
tunnel protection ipsec profile TUN_A-B

Как видите все настройки кроме указания ключа для шифрования идентичные. А если планируете использовать один ключ для всех соединений (0.0.0.0) то тогда все настройки будут идентичны.
После этого можно проверять соединение. На маршрутизаторах установление защищенного соединения можно проверить командами:
show crypto isakmp sa    # для первой фазы
show crypto ipsec sa   # для второй фазы

COMPANY-A#sh crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 101.0.0.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (101.0.0.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (201.0.0.2/255.255.255.255/47/0)
   current_peer 201.0.0.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

Счетчики показывают что пакеты шифруются и дешифруются. При этом обмен данными происходит по двум симплексным соединениям, это называется SA (Security Associations).

В процессе настройки у меня возникла следующая проблема, не очевидная на первый взгляд. После применения IPSec профиля на стороне COMPANY-A, интерфейс Tunnel 0  перешел в состояние DOWN, ведь теперь он пытается установить защищенное соединение про которое сторона COMPANY-B еще ничего не знает, и следую настройке keepalive 2 3 после 6 секунд его состояние изменилось(тоже самое произошло и на стороне B).
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
Я ожидал, что он поднимется когда настройки шифрования будут одинаковые, но этого не произошло. 
После включения дебаггинга стало видно, что данные передаваемые между пользовательскими сетями не попадают в туннель. Т.к. сам туннель не поднят:
COMPANY-A# sh ip route
S*    0.0.0.0/0 [1/0] via 101.0.0.1
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.0.0/24 is directly connected, Ethernet0/1
L        10.0.0.254/32 is directly connected, Ethernet0/1
      101.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        101.0.0.0/24 is directly connected, Ethernet0/0
L        101.0.0.2/32 is directly connected, Ethernet0/0

Поэтому туннельный трафик уходит в физический интерфейс и триггер для установления IPSec не срабатывает. На это время необходимо отключить keepalive на туннеле, тогда интерфейс поднимется, маршрут установится в GRT (global routing table), и будет триггерить установку IPSec. Таким образом все настройки для шифрованного GRE туннеля:
COMPANY A:
COMPANY-A#sh run | s Tunnel|ip route|crypto
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 2
crypto isakmp key CISCO address 201.0.0.2
crypto ipsec transform-set TransformGRE esp-aes 256 esp-sha-hmac
 mode transport
crypto ipsec profile TUN_A-B
 set transform-set TransformGRE
interface Tunnel0
 description TUNNEL to COMPANY B
 ip address 172.16.0.1 255.255.255.0
 ip mtu 1420
 ip tcp adjust-mss 1360
 tunnel source Ethernet0/0
 tunnel destination 201.0.0.2
 tunnel protection ipsec profile TUN_A-B
ip route 0.0.0.0 0.0.0.0 101.0.0.1
ip route 192.168.0.0 255.255.255.0 Tunnel0

COMPANY B:
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 2
crypto isakmp key CISCO address 101.0.0.2
crypto ipsec transform-set TransformGRE esp-aes 256 esp-sha-hmac
 mode transport
crypto ipsec profile TUN_A-B
 set transform-set TransformGRE
interface Tunnel0
 description TUNNEL to COMPANY A
 ip address 172.16.0.2 255.255.255.0
 ip mtu 1420
 ip tcp adjust-mss 1360
 tunnel source 201.0.0.2
 tunnel destination 101.0.0.2
 tunnel protection ipsec profile TUN_A-B
ip route 0.0.0.0 0.0.0.0 201.0.0.1
ip route 10.0.0.0 255.255.255.0 172.16.0.1









2 комментария:

Ограничение количества MAC адресов на порту коммутатора Cisco

Для того чтобы ограничить количество MAC адресов ( количество подключенных узлов) на порту коммутатора Cisco необходимо использовать функци...