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.
Комментарии
Sam (не проверено)
вт, 05/12/2015 - 11:04
Постоянная ссылка (Permalink)
которая виртуально соединяет напрямую два маршрутизатора R1 и R2 (без лишнего хопа на R2).
Наверно правильно будет - напрямую два маршрутизатора R1 и R3 (без лишнего хопа на R2).
bacek
ср, 05/13/2015 - 15:15
Постоянная ссылка (Permalink)
Добавить комментарий