GrabDuck

Варианты реализации IPSec VPN тунелей на оборудовании Cisco | Kickself.com

:

В этой статье посмотрим на разные технологии реализации статических site-to-site IPSec туннелей на оборудовании Cisco с позиции того, как та или иная технология инкапсулирует исходный пакет в новые заголовки и как это сказывается на конечном размере и структуре пакета.

Использовать будем вот эту простую, собранную в GNS3 топологию:

Топология IPSec GRE GNS3

На транзитном роутере будем наблюдать за ICMP-пакетами между лупбеками маршрутизаторов Site A и Site B. Команды, которые нужно ввести на транзитном роутере для того, чтобы иметь возможность наблюдать за проходящим через него интересующим нас трафиком, представлены на рисунке.

Для начала просто выполним ICMP ping с роутера Site A, чтобы посмотреть, как выглядит пакет до начала разного рода извращений над ним:

SiteA# ping 192.168.3.3 source lo0 size 100

В дебаге на транзитном роутере видим:

*Sep 2 12:20:06.715: IP: s=192.168.1.1 (FastEthernet1/0), d=192.168.3.3, len 100, input feature…..

Ну, это, собственно понятно – послали ICMP-пакет размером 100 байт – таким он и дошел до транзитного роутера. Т.е. сейчас он (пакет), если не учитывать заголовок и трейлер канального уровня, выглядит так:

Заголовок ICMP

Теперь будем экспериментировать.

1. IPSec с «классическими» crypto-map

Сразу приведу конфигурацию для SiteA и SiteB маршрутизаторов. Выглядеть она будет так (все в самом простом виде, все лишнее успешно удалено, дабы не загружать ненужной в рамках статьи информацией):

hostname SiteA
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.23.3
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode tunnel
!
crypto map CRYPTOMAP 10 ipsec-isakmp
set peer 10.1.23.3
set transform-set TS
match address CRYPTOACL
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet1/0
ip address 10.1.12.1 255.255.255.0
crypto map CRYPTOMAP
!
ip route 0.0.0.0 0.0.0.0 10.1.12.2
!
ip access-list extended CRYPTOACL
permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
hostname SiteB
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.12.1
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode tunnel
!
crypto map CRYPTOMAP 10 ipsec-isakmp
set peer 10.1.12.1
set transform-set TS
match address CRYPTOACL
!
interface Loopback0
ip address 192.168.3.3 255.255.255.0
!
interface FastEthernet1/0
ip address 10.1.23.3 255.255.255.0
crypto map CRYPTOMAP
!
ip route 0.0.0.0 0.0.0.0 10.1.23.2
!
ip access-list extended CRYPTOACL
permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255

Выполним icmp-ping:

SiteA# ping 192.168.3.3 source lo0 size 100

В дебаге на транзитном роутере теперь видим вот что:

*Sep 2 12:44:15.579: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), len 168….

Пакет теперь «весит» аж на 68 байт больше. Из чего состоит этот дополнительный overhead? Посмотрим на следующий рисунок:

ESP Заголовок

Во-первых, добавился новый IP заголовок, самый обычный, размером 20 байт. Это обусловлено тем, что в данном случае используется туннельный режим ESP (tunnel mode), благодаря чему и становится возможным передача IPSec –трафика через публичные сети. Src IP и Dst IP в новом заголовке — это уже не адреса источника и получателя пакета, а адреса внешних интерфейсов VPN-шлюзов.

Во вторых, добавились поля протокола ESP — заголовок, трейлер и поле аутентификации. Длина полей, имеющих отношение к ESP зависит от выбранных алгоритмов шифрования/хеширования. В нашем случае был взят IPSec transform set с алгоритмами aes и sha соответственно (этот выбор мы и оставим для последующих экспериментов). Если бы, например, вместо aes использовался des – размер полей пакета, имеющих отношение к ESP был бы меньше. В нашем случае он равен 168(общая длина пакета) – 100(размер оригинального пакета) – 20 (размер нового IP заголовка) = 48 байт.

2. GRE over IPSec

GRE over IPSec предполагает создание GRE-туннеля между VPN-шлюзами и последующее шифрование GRE-трафика.

Для начала, давайте сначала просто настроим GRE-тунель между SiteA и SiteB без навешивания на него IPSec:

   hostname SiteA
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.23.3
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode tunnel
!
crypto map CRYPTOMAP 10 ipsec-isakmp
    set peer 10.1.23.3
    set transform-set TS
    match address CRYPTOACL
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
  interface Tunnel0
    ip unnumbered FastEthernet1/0
    tunnel source FastEthernet1/0
    tunnel destination 10.1.23.3
!
interface FastEthernet1/0
ip address 10.1.12.1 255.255.255.0
crypto map CRYPTOMAP
!
ip route 0.0.0.0 0.0.0.0 10.1.12.2
  ip route 192.168.3.0 255.255.255.0 Tunnel0
!
ip access-list extended CRYPTOACL
    permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
   hostname SiteB
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.12.1
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode tunnel
!
crypto map CRYPTOMAP 10 ipsec-isakmp
    set peer 10.1.12.1
    set transform-set TS
    match address CRYPTOACL
!
interface Loopback0
ip address 192.168.3.3 255.255.255.0
!
interface Tunnel0
    ip unnumbered FastEthernet1/0
    tunnel source FastEthernet1/0
    tunnel destination 10.1.23.3
!
interface FastEthernet1/0
ip address 10.1.23.3 255.255.255.0
crypto map CRYPTOMAP
!
ip route 0.0.0.0 0.0.0.0 10.1.23.2
ip route 192.168.3.0 255.255.255.0 Tunnel0
!
ip access-list extended CRYPTOACL
    permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255

В приведенной таблице, добавленные строки выделены, а удаленные – зачеркнуты.

Что мы ожидаем увидеть? По логике, исходный пакет, размером 100 байт, инкапсулируется в GRE, заголовок которого равен 4 байта и ко всему этому добавится новый 20-байтовый IPзаголовок , содержащий IP-адреса маршрутизаторов SiteAи SiteB. Таким образом общий размер пакета должен составить 124 байта а выглядеть он должен так:

GRE Заголовок

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

SiteA# ping 192.168.3.3 source lo0 size 100

Посмотрим, что показывает debug на транзитном роутере:

*Sep 2 14:54:32.183: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), len 124, sending full packet

Все действительно так, как и предполагалось.

Теперь добавим IPSec «поверх» GRE. Для этого создадим IPSec profile и повесим его на туннельный интерфейс каждого VPN-шлюза:

   crypto ipsec profile IPSECPROFILE
set transform-set TS
!
interface Tunnel0
tunnel protection ipsec profile IPSECPROFILE
   crypto ipsec profile IPSECPROFILE
set transform-set TS
!
interface Tunnel0
tunnel protection ipsec profile IPSECPROFILE

Снова выполним ping с маршрутизатора Site A и посмотрим дебаг на транзитном роутере:

*Sep 2 15:17:24.958: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), g=10.1.23.3, len 184, forward

Теперь, размер пакета составил целых 184 байта! Почти в два раза больше исходного. Представим  визуально что из себя представляет GRE over IPSec пакет:

GRE over IPSec

На приведенной диаграмме явно бросается в глаза, что один и тот же внешний заголовок присутствует в пакете дважды. Первый раз роутер прицепил его к пакету, когда инкапсулировал в GRE, второй – когда уже GRE инкапсулировал в IPSec (в частности в ESP). Очевидно, что в данном случае целесообразно использовать транспортный режим IPSec, когда новый IP заголовок не добавляется. В этом случае можно сэкономить лишние несколько байт. Внесем соответствующие изменения в конфигурацию каждого из VPN-шлюзов:

crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode transport
crypto ipsec transform-set TS esp-aes esp-sha-hmac
mode transport

После очередного ping с роутера Site A на транзитном роутере видим следующее:

*Sep 2 15:49:00.802: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), len 168, sending full packet

Теперь длина пакета – 168 байт. На 16 меньше чем в туннельном режиме. Почему не на 20, ведь размер IP заголовка от которого мы избавились равен 20 байтам? Потому, что этот заголовок был также зашифрован ESP, а длина зашифрованного, как правило, не равна длине оригинального. В данном случае это не столь важно. Важно, что мы избавились от лишнего заголовка и тем самым уменьшили overhead хотя бы на какую-то часть. Выглядит GRE over IPSec в транспортном режиме так:

GRE over IPSec Transport

Посмотрим два момента, которые отражают все, о чем говорилось выше, и будут полезны дальше:

SiteA#sh int tunnel 0 | i transport|protection

  Tunnel protocol/transport GRE/IP
  Tunnel transport MTU 1434 bytes
  Tunnel protection via IPSec (profile «IPSECPROFILE»)

SiteA#sh crypto ipsec sa | i inbound|outbound|setting

     current outbound spi: 0xD761501C(3613478940)
     inbound esp sas:
        in use settings ={Transport, }
          outbound esp sas:
        in use settings ={Transport, }

Тут более наглядно видно, что туннельный интерфейс работает в режиме GRE/IPи для его защиты используется IPSec в транспортном режиме.

 3. Virtual Tunnel Interface (VTI)

Что такое VTI и чем он отличается от обычного GRE over IPSec? Чтобы не вдаваться в детали, скажу следующее: это тот же GRE over IPSec, т.е. конструкция, построенная с использованием туннельных интерфейсов (через которые с успехом могут функционировать протоколы маршрутизации и другой мультикаст-трафик) со всеми их плюсами, но исключен сам GRE заголовок. Т.е., если взять последнюю схему, где представлен GRE over IPSec с IPSec в транспортном режиме и превратить ее в Static VTI, получим вот что:

GRE Static VTY

Если сравнить с самой первой картинкой, где для создания туннелей использовались crypto-map, очень сложно увидеть какие-либо отличия. А сложно потому, что их нет. На выходе пакет выглядит одинаково, независимо от технологии настройки туннеля. Длина также составляет 168 байт и является минимально возможной для выбранных алгоритмов шифрования/хеширования и размера исходного пакета. Отсюда вывод: технология VTI в маршрутизаторах Cisco призвана обеспечить возможность построения VPN-тунелей, имеющих все преимущества технологии GRE over IPSec (как, например, поддержка динамической маршрутизации), и при этом сохранить overhead минимальным (таким же, как и при использовании технологии crypto-map).

Для того, чтобы превратить туннели GRE over IPsec из предыдущего примера в VTI, нужно внести серьезные изменения в конфигурацию VPN-шлюзов:

Interface tunnel 0
mode ipsec ipv4
Interface tunnel 0
mode ipsec ipv4

После этого, посмотрим, как обычно на debug транзитного маршрутизатора:

*Sep 2 17:07:18.930: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), g=10.1.23.3, len 168, forward

Тут никаких изменений нет. Длина пакета по прежнему 168 байт. Связано, это, видимо с тем, что в предыдущем случае был использован транспортный режим ESP, а здесь, т.к. GRE больше нет, IPSec работает в туннельном режиме, игнорируя тот факт, что в конфиге явно задан транспортный.

Пара show комманд для сравнения с GRE over IPSec:

SiteA#sh int tunnel 0 | i transport|protection

  Tunnel protocol/transport IPSEC/IP
  Tunnel transport MTU 1438 bytes
  Tunnel protection via IPSec (profile «IPSECPROFILE»)

SiteA#sh crypto ipsec sa | i inbound|outbound|setting

     current outbound spi: 0x7183DC1D(1904466973)
     inbound esp sas:
        in use settings ={Tunnel, }
        in use settings ={Tunnel, }
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
        in use settings ={Tunnel, }
        in use settings ={Tunnel, }

 

Подведем итог

Размер исходного пакета: 100 байт

Размер пакета при использовании ESP в тунельном режиме и криптокартами: 168 байт.
Размер пакета при использовании GRE over IPSec(ESP) в туннельном режиме: 184 байта.
Размер пакета при использовании GRE over IPSec(ESP) в транспортном режиме: 168 байт.
Размер пакета при испольовании Static VTI интерфейсов в туннельном режиме: 168 байт.

При желании можно проделать аналогичные эксперименты с AH, задействовать другие алгоритмы или сделать то же самое с IPv6. Подобные эксприменты полезно проводить для формирования  четкого представления о том, как применение той или иной технологии реализации IPSec сказывается на конечный вид IP пакета, какой вносит overhead и т.д. Целесообразно при этом еще использовать Wireshark (тем более в GNS с этим никаких проблем нет), где наиболее наглядно видно какие заголовки добавлены, их структура и размер.


Не забывайте оставлять комментарии, если пост был вам полезен!