Как проверить gre туннель

Проверка туннеля gre

Для наблюдения и устранения неполадок в туннелях GRE можно использовать несколько команд. Для определения работоспособности интерфейса туннеля используйте команду show ip interface brief, как показано на рисунке 1.

Для проверки состояния туннеля GRE используйте команду show interface tunnel. Протокол канального уровня в интерфейсе туннеля GRE активен до тех пор, пока существует маршрут до адреса назначения туннеля. Перед реализацией туннеля GRE между IP-адресами физических интерфейсов на противоположных сторонах потенциального туннеля GRE должна уже существовать связь по IP.

Транспортный протокол туннелирования отображается в выходных данных, также показанных на рисунке 1.

Если OSPF также настроен на обмен маршрутами по туннелю GRE, то с помощью команды show ip ospf neighbor убедитесь, что через интерфейс туннеля установлены отношения смежности OSPF.

На рисунке 2 видно, что адрес соседнего устройства OSPF находится в сети IP, созданной для туннеля GRE

На рисунке 3 с помощью средства проверки синтаксиса (Syntax Checker) настройте и проверьте туннель GRE на маршрутизаторе R2, а затем на R1.

GRE считается VPN, так как это частная сеть, которая создаётся посредством туннелирования через публичную сеть. Благодаря инкапсуляции туннель GRE создаёт виртуальный канал «точка-точка» до маршрутизаторов Cisco в удалённых точках поверх IP-сети. Преимущества GRE заключаются в том, что его можно использовать для туннелирования трафика, отличного от IP, по сети IP, что делает возможным расширение сети путем подключения различных многопротокольных подсетей через однопротокольную магистральную среду. GRE также поддерживает процесс туннелирования групповой рассылки IP (IP multicast). Это означает, что в туннеле можно использовать протоколы маршрутизации, что позволяет обеспечивать динамический обмен данными о маршрутизации в виртуальной сети. Наконец, на практике часто создаются туннели GRE «IPv6 по IPv4», где IPv6 является инкапсулированным протоколом, а IPv4 — протоколом-транспортом. В будущем их роли, очевидно, поменяются местами, так как IPv6 становится стандартным протоколом IP.

Однако GRE не обеспечивает шифрования и никаких других механизмов безопасности. Поэтому данные, отправляемые по туннелю GRE, не защищены. Если требуется безопасная передача данных, то необходимо настроить сети VPN с IPsec или с SSL.

Сети VPN. Основы сетей VPN.

Организациям требуются безопасные, надёжные и недорогие способы соединения между собой нескольких сетей, которые позволят подключать филиалы и поставщиков к сети главного офиса корпорации. Кроме того, с учётом увеличения количества удалённых сотрудников предприятиям всё чаще требуются безопасные, надёжные и экономичные решения для подключения сотрудников, работающих в секторе SOHO (Small Office/Home Office — малый офис/домашний офис), а также в других удалённых местоположениях, к ресурсам корпоративных узлов.

На рисунке показаны топологии, применяемые в современных сетях для подключения удалённых местоположений. В одних случаях удалённые местоположения подключаются только к центральному офису, тогда как в других случаях они подключаются к дополнительным узлам.

Организации используют сети VPN для сквозной конфиденциальной сетевой связи через сети сторонних компаний, например, через Интернет или сети экстранет. Туннель устраняет барьер, связанный с расстоянием, и позволяет удалённым пользователям получать доступ к сетевым ресурсам на центральном узле. VPN представляет собой частную сеть, которая создаётся с помощью туннелирования в публичной сети (как правило, в Интернете). VPN — это среда передачи данных со строгим контролем доступа, позволяющим устанавливать равноправные подключения в пределах определённого целевого сообщества.

Первые сети VPN представляли собой обычные IP-туннели, в которых проверка подлинности или шифрование данных не выполнялись. Например, универсальная инкапсуляция при маршрутизации (Generic Routing Encapsulation, GRE) — это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать пакеты протоколов сетевого уровня различного типа внутри IP-туннелей. Благодаря этому создаётся виртуальный канал «точка-точка» до маршрутизаторов Cisco в удалённых точках поверх IP-сети.

В настоящее время под виртуальными частными сетями обычно понимают защищённую реализацию сети VPN с шифрованием (например IPsec VPN).

Для реализации сетей VPN требуется шлюз VPN. Шлюзом VPN может быть маршрутизатор, межсетевой экран или устройство адаптивной защиты Cisco ASA (Adaptive Security Appliance). ASA — это автономный межсетевой экран, который объединяет в пределах одного образа программного обеспечения функции межсетевого экрана, концентратора VPN, а также системы предотвращения вторжений.

12.10. Настройка GRE-туннеля

Перейдите во вкладку Сеть и задайте следующие параметры:

• MTU.
• Локальный IP: IP-адрес внешнего интерфейса UserGate А, на котором производится настройка GRE-туннеля.
• Удалённый IP: IP-адрес внешнего интерфейса UserGate В, до которого создаётся туннель GRE.
• Режим работы туннеля: GRE.
• IP-адрес интерфейса и маску: туннельный IP-адрес и маска.

Произведите аналогичную зеркальную настройку локального и удалённого IP-адресов на UserGate В, до которого настраивается GRE-туннель. Измените локальный IP-адрес на 172.31.255.2 и удалённый — на 172.31.255.1 IP-адреса, туннельный IP-адрес интерфейса назначьте из подсети 12.0.0.0/24.

Если локальный и удалённый IP-адреса принадлежат разным подсетям, обеспечьте маршрутизацию между ними в разделе Сеть —> Виртуальные маршрутизаторы.

Во вкладке Диагностика и мониторинг в разделе Сеть —> Ping проверьте сетевую доступность узлов UserGate внутри туннеля.

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(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.

Туннель GRE

Если в вашей компании имеется удаленный филиал, в котором также установлен ИКС, то для объединения локальных сетей безопасным способом наиболее подходящим решением будет настройка шифрованного туннеля между ними.

Для обеспечения безопасности передачи данных в туннеле используется IPSec . Защита передачи данных по туннелям позволяет избежать утечки информации и получения ложных данных.

В ИКС можно настроить подключение между серверами статическим туннелем по IPIP — или GRE -протоколу.

Обычно выбор типа туннеля зависит от промежуточных провайдеров, которые по каким-либо причинам могут блокировать трафик GRE или IPIP, что приводит к невозможности использования какого-то одного типа туннеля. Принципиальной разницы между данными типами туннелей нет.

Добавить туннель GRE можно в меню Сеть > Провайдеры и сети. Для этого выполните следующие действия:

1. Нажмите кнопку «Добавить» и выберите «Туннели > Туннель GRE».
2. На вкладке «Общие настройки» введите название туннеля.
3. Выберите внешний интерфейс.
4. Введите в соответствующих полях следующие адреса: внешний IP-адрес удаленного сервера, локальный IP-адрес туннеля, удаленный IP-адрес туннеля.
   
5. На вкладке также можно задать локальные сети, удаленные сети и MTU .
6. Если требуется, установите флаги:
   • «Автоматически создавать статический маршрут для удаленных сетей»;
   • «Использовать NAT ».
7. При необходимости задайте ключ GRE. По умолчанию он не используется.
8. На вкладке «Настройки шифрования» можно выбрать шифрование IPSec и установить его параметры. Внимание! Данную процедуру необходимо произвести на обоих концах туннеля, в противном случае передача данных работать не будет. Внимание! При использовании IPSec-шифрования в туннелях IPIP и GRE трафик будет проходить через интерфейс enc0 . Статистика на данном интерфейсе не собирается!
9. На вкладке «Настройки мониторинга» можно установить флаги :
   • «Проверять наличие пинга внешнего IP-адреса удаленного сервера» — проверка, отвечает ли на ICMP -запросы внешний адрес удаленного сервера, который указан в общих настройках туннеля. Если пинг не будет проходить, в статусе туннеля отобразится соответствующее уведомление;
   • «Проверять наличие пинга удаленного IP-адреса туннеля» — проверка доступности удаленного IP-адреса туннеля;
   • «Проверять доступность серверов» — при установке флага укажите серверы, доступность которых будет проверяться.

По умолчанию все флаги сняты.

Нажмите «Добавить» — новый туннель появится в списке.

Аналогичные настройки необходимо произвести на другом конце туннеля.

Внимание! Для корректной работы туннеля необходимо, чтобы в межсетевом экране ИКС был разрешен GRE-трафик, а также разрешены входящие соединения с IP-адреса удаленного сервера.