GRE (Generic Routing Encapsulation) – протокол инкапсуляции, который широко применяется как сам по себе, так и в совокупности с IPSec для создания туннелей. Перед прочтением данной статьи рекомендуется ознакомиться со статьёй «Принципы организации VPN».
В этой статье мы будем настраивать GRE туннель. Сам по себе GRE не обеспечивает никакой безопасности передаваемых данных – это site-to-site VPN туннель в чистом виде. Используется обычно такой туннель, когда есть специфичные задачи, связанные с маршрутизацией и нет требований к безопасности. Не стоит забывать, что чистый GRE туннель – не нагружает оборудование, а нагрузка при шифровании большого объёма данных весьма существенна.
Протокол GRE инкапсулируется напрямую в IP, минуя TCP или UDP, в IP пакете есть специальное поле «Protocol type», в котором содержится число, обозначающее протокол, инкапсулированный в данный IP пакет, для GRE protocol type равен 47. В связи с этим, если в сети есть GRE туннели, то стоит внимательно относиться к написанию расширенных списков контроля доступа (ACL), так как permit tcp any any и permit udp any any приведут к запрету на GRE из-за того, что он инкапсулируется напрямую в пакет, надо писать либо permit ip any any либо permit gre any any.
Схема инкапсуляции GRE выглядит следующим образом:
Как видно, IP инкапсулируется в GRE, который инкапсулируется в IP. При этом заголовок GRE и заголовок внешнего IP пакета добавляют 24 байта, соответственно, уменьшая размер пакета на эту величину. В данном примере мы настраиваем IPv4 в GRE в IPv4, тем не менее, GRE может успешно работать с другими инкапсулируемыми и транспортными протоколами, например, IPv6.
Рассмотрим работающую топологию. Есть две локальный сети: LAN1 за маршрутизатором R1 с адресацией 192.168.0.0/24 и LAN2 – за маршрутизатором R3, с адресацией 192.168.1.0/24. В каждой сети есть по одному компьютеру. Между маршрутизаторами есть сети 1.0.0.0/8 и 2.0.0.0/8, а также маршрутизатор R2 – это в нашем примере интернет. Маршрутизация для простоты настроена с помощью протокола RIP.
Выполним трассировку с компьютера PC1 до компьютера PC2:
Tracing route to 192.168.1.2 over a maximum of 30 hops:
1 0 ms 0 ms 0 ms 192.168.0.1
2 0 ms 0 ms 0 ms 1.1.1.2
3 0 ms 0 ms 0 ms 2.2.2.2
4 1 ms 0 ms 0 ms 192.168.1.2
Как видно, пакет проходит через все маршрутизаторы последовательно, вплоть до компьютера адресата. Теперь создадим GRE туннель между R1 и R3 со внутренней адресацией 10.10.10.0/24.
R1(config)#interface tunnel 0
R1(config-if)#
%LINK-5-CHANGED: Interface Tunnel0, changed state to up
R1(config-if)#tunnel mode gre ip
R1(config-if)#ip address 10.10.10.1 255.255.255.0
R1(config-if)#tunnel source FastEthernet0/1
R1(config-if)#tunnel destination 2.2.2.2
R1(config-if)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R1(config-if)#exit
Мы создали интерфейс Tunnel0, в нём указали с помощью ip address внутреннюю адресацию туннеля – тот есть это адреса инкапсулированного IP, а с помощью команд tunnel source и tunnel destination мы указали параметры транспортного протокола IP (внешнего). У нас появилась новая сеть, которая виртуально соединяет напрямую два маршрутизатора R1 и R3 (без лишнего хопа на R2). Настроим вторую сторону туннеля – на R3. Для примера создадим интерфейс Tunnel99:
R3(config)#interface tunnel 99
R3(config-if)#
%LINK-5-CHANGED: Interface Tunnel99, changed state to up
R3(config-if)#tunnel mode gre ip
R3(config-if)#ip address 10.10.10.2 255.255.255.0
R3(config-if)#tunnel source FastEthernet0/0
R3(config-if)#tunnel destination 1.1.1.1
R3(config-if)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel99, changed state to up
R3(config-if)#exit
Теперь выполним трассировку с маршрутизатора R1 противоположного конца туннеля – на R3:
R1#traceroute 10.10.10.2
Type escape sequence to abort.
Tracing the route to 10.10.10.2
1 10.10.10.2 1 msec 0 msec 0 msec
Как видно, трассировка проходит внутри туннеля и мы не видим лишнего хопа в виде R2. Посмотрим таблицу маршрутизации на R1:
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
C 1.0.0.0/8 is directly connected, FastEthernet0/1
R 2.0.0.0/8 [120/1] via 1.1.1.2, 00:00:12, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Tunnel0
C 192.168.0.0/24 is directly connected, FastEthernet0/0
R 192.168.1.0/24 [120/2] via 1.1.1.2, 00:00:12, FastEthernet0/1
Видно, что новая сеть отображается, как непосредственно подключенная к интерфейсу Tunnel 0. Если сейчас попробовать сделать трассировку с компьютера 1 до компьютера 2, то она не пойдёт по туннелю. Это связано с тем, что на маршрутизаторе R1 нет соответствующего маршрута. Просматривая свою таблицу маршрутизации, R1 отправит пакеты на PC2 по маршруту «R 192.168.1.0/24 [120/2] via 1.1.1.2, 00:00:12, FastEthernet0/1», то есть как и раньше – в обход туннеля. Чтобы исправить ситуацию пропишем с двух сторон на R1 и R3 статические маршруты, в которых явно укажем, что в сети 192.168.0.0 и 192.168.1.0 надо доставлять трафик через туннель. На R1:
R1(config)#ip route 192.168.1.0 255.255.255.0 10.10.10.2
На R3:
R3(config)#ip route 192.168.0.0 255.255.255.0 10.10.10.1
R3#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
R 1.0.0.0/8 [120/1] via 2.2.2.1, 00:00:05, FastEthernet0/0
C 2.0.0.0/8 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Tunnel99
S 192.168.0.0/24 [1/0] via 10.10.10.1
C 192.168.1.0/24 is directly connected, FastEthernet0/1
Теперь, как видно из таблицы маршрутизации, трафик пойдёт через GRE туннель. Проверим это, выполнив трассировку с PC1 до PC2, как и в начале этой статьи:
tracert 192.168.1.2
Tracing route to 192.168.1.2 over a maximum of 30 hops:
1 0 ms 0 ms 0 ms 192.168.0.1
2 0 ms 0 ms 0 ms 10.10.10.2
3 1 ms 0 ms 1 ms 192.168.1.2
Trace complete.
Как видно, из результатов трассировки, теперь на пути всего два хопа: 192.168.0.1 – R1, шлюз PC1, который заворачивает трафик в туннель. Далее, транспортный (внешний) IP пакет с GRE внутри проходит на R2, затем на R3 и только тут из пакета декапсулируется внутренний IP – это и есть наш второй хоп – 10.10.10.2, затем пакет по локальной сети идёт адресату – на 192.168.1.2, если добавить в интернете ещё несколько маршрутизаторов, то трассировка не изменится, в ней по-прежнему будет два хопа до адресата. Пример конфигурации доступен в формате pkt.