Теория
Что будет происходить при таком раскладе? 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 over IPSec.
Можно сделать тут ещё одно дополнение: технически, можно исключить четырёхбайтовый заголовок GRE из пакета, указав с обеих сторон, что режим работы туннеля IPIP:
Нужно правда помнить, что в этом случае инкапсулировать можно только данные IP, а не любые, как в случае GRE.
Last updated