Static VTI

Virtual Tunnel Interface - это новая реализация Site-to-Site IPsec VPN. В отличает от крипто карт (crypto map), здесь мы можем использовать протоколы динамической маршрутизации.

После GRE over IPsec надо упомянуть и о Static VTI.
Конфигурация меняется всего лишь в одну строчку от предыдущего конфига (Путь к DMVPN - часть 2 (GRE + IPsec)), но это позволяет убрать заголовок GRE и уменьшить пакет на 24 байта.

R1(config)#inteface tunnel 1
R1(config-if)# tunnel mode ipsec ipv4

R2(config)#inteface tunnel 1
R2(config-if)# tunnel mode ipsec ipv4

Примечание:
VPN туннель построенный на Static VTI поддерживает только IP-unicast и IP-multicast трафик. GRE over IPsec поддерживает гораздо больше протоколов.

GRE over IPsec vs Static VTI

Путь к DMVPN - часть 2 (GRE + IPsec)

Требуется защитить p2p GRE туннель. Настройка IPsec достаточно простая, необходимо:

1. Настроить ISAKMP политику. Здесь указываются параметры для защиты Management соединения (ISAKMP фаза 1)

R1(config)#crypto isakmp policy 5

R1(config-isakmp)#encr aes

R1(config-isakmp)#hash sha256

R1(config-isakmp)#authentication pre-share

R1(config-isakmp)#group 14

2. В данном примере IPsec будет на PSK (Pre-Shared Key), так что настройка PSK)

R1(config)#crypto isakmp key super_secret_psk address 7.7.7.2

3. Настройка Transform Set. Здесь указываются криптографические параметры для защиты уже Data соединения, т.е. IPsec туннеля, который будет защищать пользовательские данные.

R1(config)#crypto ipsec transform-set TRANS esp-aes esp-sha-hmac

R1(cfg-crypto-trans)#mode transport

Отступление:
IPsec реализован на симметричных алгоритмах шифрования, основная проблема данных алгоритмов, это как безопасно пирам обменяться ключами. Ключ должен быть с обеих сторон одинаковый. Реализация в IPsec:
Процесс начинается с первой фазы ISAKMP, пиры обмениваются криптографическими параметрами, аутентифицируются и на выходе получается Management Туннель. Этот туннель нужен, чтобы пиры безопасно обменялись криптографической информацией для построения уже Data туннеля. Этот процесс называется второй фазой ISAKMP.
Management туннель: show crypto isakmp sa
Data туннель: show crypto ipsec sa

4. Настроить IPsec профиль

R1(config)#cryptо ipsec profile IPSEC_PROF

R1(ipsec-profile)#set transform-set TRANS

5. Применить IPsec профиль к VTI

R1(config)#interface tunnel 1

R1(config-if)#tunnel protection ipsec profile IPSEC_PROF

R1(config-if)#ip mtu 1400

R1(config-if)#ip tcp adjust-mss 1360 

Пример: продолжаем конфиг с DMVPN - часть 1 (Обзор GRE)
Конфиг для двух устройств
!

R1(config)#crypto isakmp policy 5

R1(config-isakmp)#encr aes

R1(config-isakmp)#hash sha256

R1(config-isakmp)#authentication pre-share

R1(config-isakmp)#group 14

!

R1(config)#crypto isakmp key super_secret_psk address 7.7.7.2

!

R1(config)#crypto ipsec transform-set TRANS esp-aes esp-sha-hmac

R1(cfg-crypto-trans)#mode transport

!

R1(config)#cryptо ipsec profile IPSEC_PROF

R1(ipsec-profile)#set transform-set TRANS

!

R1(config)#interface tunnel 1

R1(config-if)#tunnel protection ipsec profile IPSEC_PROF

R1(config-if)#ip mtu 1400

R1(config-if)#ip tcp adjust-mss 1360 

R2(config)#crypto isakmp policy 5

R2(config-isakmp)#encr aes

R2(config-isakmp)#hash sha256

R2(config-isakmp)#authentication pre-share

R2(config-isakmp)#group 14

!

R2(config)#crypto isakmp key super_secret_psk address 7.7.7.1

!

R2(config)#crypto ipsec transform-set TRANS esp-aes esp-sha-hmac

R2(cfg-crypto-trans)#mode transport

!

R2(config)#crypto ipsec profile IPSEC_PROF

R2(ipsec-profile)#set transform-set TRANS

!

R2(config)#interface tunnel 1

R2(config-if)#tunnel protection ipsec profile IPSEC PROF

R2(config-if)#ip mtu 1400

R2(config-if)#ip tcp adjust-mss 1360

Тот же самый пакет (TFTP), но уже зашифрованный IPsec

Примечание: 

1. На туннельных интерфейсах установлено значение MTU 1400, TCP MSS 1360. Мы уменьшаем размер исходного пакета, чтобы добавление GRE + IPsec заголовков не привело к фрагментированию.

2. Механизм Keepalive не работает совместно с IPsec.

Путь к DMVPN - часть 1 (Обзор GRE)

Протокол GRE (Generic Routing Encapsulation) описывается в нескольких RFC: 1701, 1702, 2784.

Основная цель - это передавать различные протоколы через различную среду. Одно из общих применений - это передавать IP multicast через среду IP.

Пример:

У системы есть пакет и ей надо его отправить удаленному получателю. Назовем этот пакет Payload packet (или Passenger protocol). Данный пакет мы инкапсулируем в GRE (Carrier protocol - перевозчик), затем то что получилось мы снова инкапсулируем в еще один IP (Transport protocol) и затем отправляем удаленному получателю.

GRE - протокол третьего уровня. GRE пакеты инкапсулированные в IP используют номер IP 47.

В Cisco IOS GRE реализованы как VTI (Virtual Tunnel Interface). Туннельный интерфейс регулирует процесс инкапсуляции. Когда мы указываем в VTI адрес источника (tunnel source) и адрес получателя (tunnel destination), именно она буду в новом IP заголовке (Transport protocol). Это должны быть реальные/маршрутизируемые адреса. Когда удаленный маршрутизатор получает пакет, он ищет соответствеющий VTI, снимает (декапсулирует) внешний IP заголовок и отправляет GRE пакет на него.

GRE туннели могут быть так же двух типов:

- Point-to-Point
- Point-to-Multipoint

Примеры:
1) Point-to-Point GRE

R1(config)#interface tunnel 1

R1(config-if)#ip address 10.0.0.1 255.255.255.0

R1(config-if)#tunnel source 7.7.7.1

R1(config-if)#tunnel destination 7.7.7.2

R2(config)#interface tunnel 1

R2(config-if)#ip address 10.0.0.2 255.255.255.0

R2(confiq-if)#tunnel source 7.7.7.2

R2(config-if)#tunnel destination 7.7.7.1

Примечание: по умолчанию в VTI инкапсуляция стоит GRE.

2) Point-to-Multipoint (Hub and Spokes) GRE

Hub(config)#interface tunnel 1

Hub(config-if)#tunnel mode gre multipoint

Hub(config-if)#tunnel source 7.7.7.1

Hub(config-if)#ip address 10.0.0.1 255.255.255.0

!

Spoke(config)#interface tunnel 1

Spoke(config-if)#tunnel source 7.7.7.2

Spoke(config-if)#tunnel destination 7.7.7.1

Spoke(config-if)#ip address 10.0.0.2 255.255.255.0

Примечание: Без протокола NHRP (Next Hop Resolution Protocol) второй пример работать не будет. Hub не знает как маршрутизировать GRE пакеты, т.к. он не знает реальных IP адресов удаленных получателей (Spokes).

GRE туннели по умолчанию stateless, т.е. локальный хост не проверяет состояние туннеля удаленного хоста. А это значит, что если по каким-то причинам удаленный туннель не поднялся (состояние Down), локальный хост будет отправлять трафик в этот самый туннель.
Чтобы этого избежать у Cisco реализован механизм Keepalive. Раз в отрезок времени отправляются Keepalive пакеты до удаленного хоста. Если ответ получен, то у туннеля состояние Up, если нет, то Down.
Когда у туннеля состояние Down все маршруты имеющие Next Hop этот туннельный интерфейс пропадают из таблицы маршрутизации.

Router(config-if)#keepalive 10 3