GRE over IPSec
𝔯𝔱_𝔣𝔞𝔫У начинающих тут часто случается конфуз (он и у автора случился): GRE over IPSec или IPSec over GRE. В чём разница, где применяются. Нельзя на этом не остановиться.
Обычный режим, который мы рассматриваем тут и который применяется в подавляющем большинстве случаев, – это GRE over IPSec, то есть данные GRE инкапсулируются заголовками ESP или AH
А IPSec over GRE означает, наоборот, что внутри будут зашифрованные данные IPSec, а сверху заголовки GRE/IP. Они будут не зашифрованы:
Такой вариант возможен, например, если шифрование у вас происходит на отдельном устройстве перед туннелированием
Зачем такая пахабщина нужна, не очень понятно, поэтому обычно используется именно GRE over IPSec.
Практика.
Вернёмся к нашей старой схеме и реализуем на ней именно этот вариант.
Разумеется, при этом у нас снова появляется туннельный интерфейс (настраивается, как обычный GRE):
interface Tunnel0 ip address 10.2.2.1 255.255.255.252 tunnel source 100.0.0.1 tunnel destination 200.0.0.1
И далее вы направляете в него нужный вам трафик статическим маршрутом.
ip route 10.1.1.0 255.255.255.255 10.2.2.2
Что при этом меняется в настройке IPSec? В принципе, даже если вы ничего не поменяете, всё уже будет работать, но это не наш путь. Во-первых, поскольку туннель уже существует (GRE), нет нужды делать его ещё и средствами IPSec – можно перевести его в транспортный режим, тем самым, сэкономив 20 байтов на лишнем IP-заголовке:
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac mode transport
*Заметьте, менять, это надо на обеих сторонах, иначе соседство IPSec не установится.
Во-вторых, шифроваться должен весь трафик между филиалами, то есть тот, который идёт через туннель, соответственно, нет необходимости прописывать все сети в ACL, поступим хитрее:
access-list 101 permit gre host 100.0.0.1 host 200.0.0.1
Условие выполняется, если на порт пришёл трафик с заголовком GRE и соответствующими адресами.
Теория.
Что будет происходить при таком раскладе?
1) Пакет с адресом назначения 10.1.1.0 приходит на маршрутизатор, тот определяет по своей таблице, что пакет нужно передать на next-hop 10.2.2.2
R1#sh ip route 10.1.1.0 Routing entry for 10.1.1.0/32 Known via «static», distance 1, metric 0 Routing Descriptor Blocks: * 10.2.2.2 Route metric is 0, traffic share count is 1
2) Это туннельный интерфейс, с адресом назначения 200.0.0.1. Пакет упаковывается заголовком GRE и новым IP заголовком.
R1#sh int tun 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is 10.2.2.1/30 MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 100.0.0.1, destination 200.0.0.1 Tunnel protocol/transport GRE/IP
3) Сеть 200.0.0.1 известна через адрес 100.0.0.2
R1#sh ip route Gateway of last resort is 100.0.0.2 to network 0.0.0.0
А подсеть 100.0.0.0/30 подключена к интерфейсу FE0/0
R1#sh ip route 100.0.0.0 Routing entry for 100.0.0.0/30, 1 known subnets Attached (1 connections) C 100.0.0.0 is directly connected, FastEthernet0/0
А на него применена карта шифрования с ACL.
Трафик, естественно, подпадает под него (имеет заголовок GRE и нужные IP-адреса), поэтому всё, что находится внутри внешнего IP-заголовка будет зашифровано.
Такая схема работы позволяет нормально внедрять протоколы динамической маршрутизации, а также передавать мультикастовый трафик, оставляя возможность шифрования. Хулиганы уже не смогут выкрасть секретные рецепты приготовления лифтов.
Можно сделать тут ещё одно дополнение: технически, можно исключить четырёхбайтовый заголовок GRE из пакета, указав с обеих сторон, что режим работы туннеля IPIP:
interface Tunnel0 tunnel mode ipip
Нужно правда помнить, что в этом случае инкапсулировать можно только данные IP, а не любые, как в случае GRE.