GRE (Generic Routing Encapsulation) -туннель применяется в ситуациях, когда необходимо передавать трафик между двумя удалёнными сетями офисов по Интернету. Между двумя конечными устройствами (как правило, маршрутизаторами Cisco\MikroTik) логически формируется виртуальный канал, внутри которого происходит передача сетевых пакетов.
Следует учитывать, что сам по себе GRE не обеспечивает защиту информации. Он лишь оборачивает исходные пакеты в дополнительный GRE-заголовок, не выполняя их шифрование. Поэтому данные, передаваемые внутри такого туннеля, остаются открытыми для перехвата. Если требуется обеспечить конфиденциальность и целостность трафика, поверх GRE настраивается IPSec. В этом случае обычный GRE-туннель превращается в защищённый VPN-туннель формата GRE поверх IPSec.
Принцип работы GRE #
Несмотря на распространённое заблуждение, GRE over IPSec не является аналогом классического Site-to-Site IPSec VPN. Ключевое различие заключается в поддержке типов трафика: GRE-туннели способны передавать multicast-пакеты, в то время как стандартные IPSec-VPN такие пакеты не пропускают.
Именно поэтому в крупных сетях, где используются динамические протоколы маршрутизации (например, OSPF или EIGRP), GRE-туннели являются более подходящим решением. Дополнительным преимуществом является относительная простота их настройки по сравнению с традиционными IPSec-VPN, что делает GRE популярным выбором среди сетевых инженеров.
В данной статье рассматривается процесс создания как простых, незащищённых GRE-туннелей, так и защищённых вариантов с использованием IPSec. Пошагово описываются настройка, проверка работоспособности туннелей и организация маршрутизации между двумя сетями.
Настройка GRE over IPSec между Cisco и Cisco #
Создание GRE туннеля #
Создаем интерфейс Tunnel1 на R1:
interface Tunnel1
ip address 192.168.250.1 255.255.255.252
ip tcp adjust-mss 1360
tunnel source 117.121.219.17
tunnel destination 67.35.39.23
Создаем интерфейс Tunnel1 на R2:
interface Tunnel1
ip address 192.168.250.2 255.255.255.252
ip tcp adjust-mss 1360
tunnel source 67.35.39.23
tunnel destination 117.121.219.17
На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга.
Echo ICMP от одного конца подтвердит это:
R1# ping 192.168.250.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.250.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
По умолчанию GRE не проверяет доступность адреса назначения и сразу отправляет туннель в Up. Но стоит только добавить в туннельный интерфейс команду keepalive X, как маршрутизатор начинает отсылать кипалайвы и не поднимется, пока не будет ответа.
В нашей тестовой схеме в качестве локальной сети мы просто настроим Loopback-интерфейсы – они всегда в Up’е. На самом же деле под ними подразумеваются реальные подсети наших офисов.
Создаем интерфейс Loopback0 на R1:
interface Loopback0
ip address 10.10.10.1 255.255.255.0
Создаем интерфейс Loopback0 на R2:
interface Loopback0
ip address 20.20.20.1 255.255.255.0
Маршрутизация сетей через туннель GRE
На R1 мы добавляем статический маршрут к удаленной сети 20.20.20.0/24 через 192.168.250.2, который является другим концом нашего туннеля GRE:
ip route 20.20.20.0 255.255.255.0 192.168.250.2
Такая же зеркальная конфигурация должна быть настроена на R2:
ip route 10.10.10.0 255.255.255.0 192.168.250.1
Теперь обе офисные сети могут свободно общаться друг с другом через туннель GRE.
Если туннель не поднимается, проверяем правила брандмаура с обеих сторон:
ip access-list extended ACL_ZONE_VPN
# GRE (proto 47) трафик
permit gre host 117.121.219.17 host 67.35.39.23
У протокола GRE (proto 47), как и у протокола ESP (proto 50) нет портов, поэтому они не будут работать за стандартным NAT (PAT). Но есть решения для обхода этой проблемы: Статический 1:1 NAT (без PAT) и NAT-Traversal (NAT-T порт 4500) для IPsec.
Защита GRE-туннеля с помощью IPSec #
Как уже отмечалось, GRE является лишь протоколом инкапсуляции и не обеспечивает шифрование данных. Использование GRE-туннеля «точка-точка» без защиты представляет серьёзную угрозу безопасности, так как передаваемая информация может быть легко перехвачена и просмотрена третьими лицами. Чтобы избежать этого, мы применяем IPSec, добавляя к GRE-туннелю уровень шифрования и защиты. Такой подход обеспечивает надёжное шифрование и повышает общую безопасность соединения. В приведённом ниже примере рассматривается реализация схемы GRE over IPSec.
Настройка IPSec-шифрования для GRE-туннеля (GRE over IPSec)
Конфигурация IPSec выполняется в два этапа на каждом маршрутизаторе:
- настройка ISAKMP (фаза 1 ISAKMP)
- настройка IPSec (фаза 2 ISAKMP)
Настройка ISAKMP (фаза 1 ISAKMP)
IKE используется исключительно для установления SA (Security Association) для IPSec. Прежде чем приступить к созданию IPSec-SA, протокол IKE должен согласовать ISAKMP-SA с удалённой стороной.
Начнём настройку с маршрутизатора R1
crypto isakmp policy 10
encryption 3des
hash sha
authentication pre-share
group 2
lifetime 86400
crypto isakmp key asterisker1 address 67.35.39.23
Создание IPSec Transform (фаза 2 ISAKMP policy)
crypto ipsec transform-set VPN-TSET esp-aes 256 esp-sha-hmac
mode transport
crypto ipsec profile VPN-IPSEC-PROFILE
set transform-set VPN-TSET
set pfs group2
Накладываем шифрование на туннель
interface Tunnel1
tunnel protection ipsec profile VPN-IPSEC-PROFILE
Такая же зеркальная конфигурация должна быть настроена на R2:
сrypto isakmp policy 10
encryption 3des
hash sha
authentication pre-share
group 2
lifetime 86400
crypto isakmp key asterisker1 address 117.121.219.17
crypto ipsec transform-set VPN-TSET esp-aes 256 esp-sha-hmac
mode transport
crypto ipsec profile VPN-IPSEC-PROFILE
set transform-set VPN-TSET
set pfs group2
interface Tunnel1
tunnel protection ipsec profile VPN-IPSEC-PROFILE
Проверка GRE over IPSec туннеля
R1# ping 20.20.20.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1# show crypto session
Interface: Tunnel1
Session status: UP-ACTIVE
Peer: 67.35.39.23 port 500
Session ID: 0
IKEv1 SA: local 117.121.219.17/500 remote 67.35.39.23/500 Active
Session ID: 0
IKEv1 SA: local 117.121.219.17/500 remote 67.35.39.23/500 Active
IPSEC FLOW: permit 47 host 117.121.219.17 host 67.35.39.23
Active SAs: 2, origin: crypto map
Если IPSec туннель не поднимается, проверяем правила брандмаура с обеих сторон:
ip access-list extended ACL_ZONE_VPN
# IKE (UDP 500) - для установки туннеля
permit udp host 117.121.219.17 eq 500 host 67.35.39.23 eq 500
# NAT-Traversal (UDP 4500) - если есть NAT
permit udp host 117.121.219.17 eq 4500 host 67.35.39.23 eq 4500
# ESP (proto 50) - IPsec трафик
permit esp host 117.121.219.17 host 67.35.39.23
# Не нужно уже разрешать GRE (proto 47), потому что GRE заголовок спрятан внутри ESP и зашифрован
no permit gre host 117.121.219.17 host 67.35.39.23
Траблшутинг IPSec / IKE (в т.ч. DMVPN) #
# ISAKMP SA (Phase 1)
show crypto isakmp sa # статус должен быть QM_IDLE
show crypto isakmp policy
show crypto session detail
show crypto session br
show crypto isakmp key
debug crypto isakmp
# IPsec SA (Phase 2)
show crypto ipsec sa
show crypto ipsec profile
show crypto ipsec transform-set
debug crypto ipsec
# Crypto Map
show crypto map
# DMVPN\NHRP
show dmvpn detail
show ip nhrp
# Routes
show ip route