Источник: http://kickself.com/variantyi-realizatsii-ipsec-vpn-tuneley-na-oborudovanii-cisco/
В этой статье посмотрим на разные технологии реализации статических site-to-site IPSecтуннелей на оборудовании Cisco с позиции того, как та или иная технология инкапсулирует исходный пакет в новые заголовки и как это сказывается на конечном размере и структуре пакета.
В этой статье посмотрим на разные технологии реализации статических site-to-site IPSecтуннелей на оборудовании Cisco с позиции того, как та или иная технология инкапсулирует исходный пакет в новые заголовки и как это сказывается на конечном размере и структуре пакета.
Использовать будем вот эту простую, собранную в 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 байт – таким он и дошел до транзитного роутера. Т.е. сейчас он (пакет), если не учитывать заголовок и трейлер канального уровня, выглядит так:
1. IPSec с «классическими» crypto-map
Сразу приведу конфигурацию для SiteA и SiteB маршрутизаторов. Выглядеть она будет так (все в самом простом виде, все лишнее успешно удалено, дабы не загружать ненужной в рамках статьи информацией):
Site A
|
Site B
|
| 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? Посмотрим на следующий рисунок:
Во-первых, добавился новый 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:
Site A
|
Site B
|
| 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 ! ! 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 ! 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 ! | 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 ! ! 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 ! 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 ! |
В приведенной таблице, добавленные строки выделены, а удаленные – зачеркнуты.
Что мы ожидаем увидеть? По логике, исходный пакет, размером 100 байт, инкапсулируется в GRE, заголовок которого равен 4 байта и ко всему этому добавится новый 20-байтовый IPзаголовок , содержащий IP-адреса маршрутизаторов SiteAи SiteB. Таким образом общий размер пакета должен составить 124 байта а выглядеть он должен так:
Подтвердим, что вышесказанное соответствует действительности, выполнив традиционный 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-шлюза:
Site A
|
Site B
|
| 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, второй – когда уже GRE инкапсулировал в IPSec (в частности в ESP). Очевидно, что в данном случае целесообразно использовать транспортный режим IPSec, когда новый IP заголовок не добавляется. В этом случае можно сэкономить лишние несколько байт. Внесем соответствующие изменения в конфигурацию каждого из VPN-шлюзов:
Site A
|
Site B
|
| 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 в транспортном режиме так:
Посмотрим два момента, которые отражают все, о чем говорилось выше, и будут полезны дальше:
SiteA#sh int tunnel 0 | i transport|protection
Tunnel protocol/transport GRE/IP
Tunnel transport MTU 1434 bytes
Tunnel protection via IPSec (profile «IPSECPROFILE»)
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, }
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, получим вот что:
Если сравнить с самой первой картинкой, где для создания туннелей использовались crypto-map, очень сложно увидеть какие-либо отличия. А сложно потому, что их нет. На выходе пакет выглядит одинаково, независимо от технологии настройки туннеля. Длина также составляет 168 байт и является минимально возможной для выбранных алгоритмов шифрования/хеширования и размера исходного пакета. Отсюда вывод: технология VTI в маршрутизаторах Cisco призвана обеспечить возможность построения VPN-тунелей, имеющих все преимущества технологии GRE over IPSec (как, например, поддержка динамической маршрутизации), и при этом сохранить overhead минимальным (таким же, как и при использовании технологии crypto-map).
Для того, чтобы превратить туннели GRE over IPsec из предыдущего примера в VTI, нужно внести серьезные изменения в конфигурацию VPN-шлюзов:
Site A
|
Site B
|
| 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»)
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, }
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 байт.
Размер пакета при использовании GRE over IPSec(ESP) в туннельном режиме: 184 байта.
Размер пакета при использовании GRE over IPSec(ESP) в транспортном режиме: 168 байт.
Размер пакета при испольовании Static VTI интерфейсов в туннельном режиме: 168 байт.
При желании можно проделать аналогичные эксперименты с AH, задействовать другие алгоритмы или сделать то же самое с IPv6. Подобные эксприменты полезно проводить для формирования четкого представления о том, как применение той или иной технологии реализации IPSec сказывается на конечный вид IP пакета, какой вносит overhead и т.д. Целесообразно при этом еще использовать Wireshark (тем более в GNS с этим никаких проблем нет), где наиболее наглядно видно какие заголовки добавлены, их структура и размер.
