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):

И далее вы направляете в него нужный вам трафик статическим маршрутом.

Что при этом меняется в настройке IPSec?
В принципе, даже если вы ничего не поменяете, всё уже будет работать, но это не наш путь.
Во-первых, поскольку туннель уже существует (GRE), нет нужды делать его ещё и средствами IPSec – можно перевести его в транспортный режим, тем самым, сэкономив 20 байтов на лишнем IP-заголовке:

*Заметьте, менять, это надо на обеих сторонах, иначе соседство IPSec не установится.

Во-вторых, шифроваться должен весь трафик между филиалами, то есть тот, который идёт через туннель, соответственно, нет необходимости прописывать все сети в ACL, поступим хитрее:

Условие выполняется, если на порт пришёл трафик с заголовком 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:

Нужно правда помнить, что в этом случае инкапсулировать можно только данные IP, а не любые, как в случае GRE.

Поиск по сайту: