GRE — пример настройки и описание

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.

Тэги: 

Комментарии

которая виртуально соединяет напрямую два маршрутизатора R1 и R2 (без лишнего хопа на R2).
Наверно правильно будет - напрямую два маршрутизатора R1 и R3 (без лишнего хопа на R2).

Аватар пользователя bacek
Большое спасибо. Конечно, вы правы.

Добавить комментарий