GRE (англ. Generic Routing Encapsulation — общая инкапсуляция маршрутов) — протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Его основное назначение — инкапсуляция пакетов сетевого уровня сетевой модели OSI в IP пакеты. Номер протокола в IP — 47.
Туннелирование подразумевает три протокола:
Содержание
Пример применения
Пример стека протоколов, использующих GRE
Проблема DF-бита
В связи со служебным заголовком размер передаваемых данных внутри IP пакета через GRE-туннель уменьшается при сохранении общего размера пакета. В IP-пакете предусмотрено наличие бита DF (do not fragment), запрещающего разделение пакета на несколько при передаче через среду с меньшим размером MTU. В этом случае пакет с размером полезной области данных (англ. payload ), превышающим MTU IP пакета в GRE-туннеле, отбрасывается, что приводит к потерям пакетов при существенной нагрузке (проходят пакеты малого размера, такие как SYN пакеты TCP, ICMP сообщения (ping), но теряются пакеты с данными в TCP потоке (то есть соединение рвётся)). Для решения этой проблемы рекомендуется использовать path-mtu-discovery (определение TCP MSS, то есть максимального размера IP-пакетов на всём пути) при передаче данных через GRE-туннель, чтобы избежать избыточной фрагментации или потери больших пакетов. [1] [2]
Примечания
Ссылки
Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP)
Физический
Полезное
Смотреть что такое «GRE (протокол)» в других словарях:
GRE — GRE: GRE (протокол) Generic Routing Encapsulation GRE (тест) Graduate Record Examination GRE (компания) японская компания … Википедия
Протокол обнаружения соседей — (англ. Neighbor Discovery Protocol, NDP ) протокол из набора Internet Protocol Suite, используемый совместно с IPv6. Он работает на уровне слоя Интернет Модели Интернета (RFC 1122) и ответственен за автонастройку адреса конечных точек сети,… … Википедия
протокол виртуального туннелирования — Черновой стандарт IETF, позволяющий различным протоколам канального и сетевого уровней туннельную передачу через сеть IP. VTP задает протокол обмена сообщениями для динамического создания и поддержки IP туннелей Протокол VTP использует механизм… … Справочник технического переводчика
PPP (сетевой протокол) — У этого термина существуют и другие значения, см. PPP. PPP (англ. Point to Point Protocol) двухточечный протокол канального уровня (Data Link) сетевой модели OSI. Обычно используется для установления прямой связи между двумя узлами сети,… … Википедия
RIP (сетевой протокол) — У этого термина существуют и другие значения, см. RIP. Протокол маршрутной информации (англ. Routing Information Protocol) один из самых простых протоколов маршрутизации. Применяется в небольших компьютерных сетях, позволяет маршрутизаторам … Википедия
RSVP (протокол) — У этого термина существуют и другие значения, см. RSVP. RSVP протокол резервирования сетевых ресурсов (Resource ReSerVation Protocol) (RFC 2205). С целью сообщения маршрутизаторам сети потребностей конечных узлов по качеству обслуживания… … Википедия
RTP — Протокол RTP (англ. Real time Transport Protocol) работает на транспортном уровне и используется при передаче трафика реального времени. Протокол был разработан Audio Video Transport Working Group в IETF и впервые опубликован в 1996 году как … Википедия
Rlogin — Протокол RLOGIN (англ. Remote LOGIN удалённый вход в систему) протокол прикладного уровня (7ой уровень модели OSI), часть стека TCP/IP. Позволяет пользователям UNIX подключаться к системам UNIX на других машинах и работать так же … Википедия
RUDP — Протокол RDP (англ. Reliable Data Protocol) разработан для обеспечения надежной передачи данных между пакетно ориентированными приложениями. Изначально он был разработан для приложений, реализующих удаленную загрузку данных и удаленное… … Википедия
Протоколы сетевого уровня — Протокол сетевого уровня (англ. Network layer) протокол 3 его уровня сетевой модели OSI, предназначается для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших… … Википедия
Диаграмма внизу показывает процесс инкапсуляции GRE пакета.
Настройка GRE туннеля
Настройка GRE туннеля включает в себя создание логического туннельного интерфейса. После этого необходимо настроить endpoint’ы на интерфейсе.
Чтобы настроить source и destination адреса для туннеля, используйте команды tunnel source и tunnel destination в режиме конфигурации интерфейса туннеля.
Ниже приведен пример как создать простой GRE туннель между двумя очками и необходимые шаги, чтобы создать и проверить GRE туннель между двумя сетями. Внутренние сети R1 и R2 (192.168.1.0/24 и 192.168.2.0/24) соединяются с помощью GRE туннеля через интернет. Оба туннельных интерфейса принадлежат сети 172.16.1.0/24.
Сначала необходимо создать туннельные интерфейсы на R1 и R2:
R1(config)# interface Tunnel1
R1(config-if)# ip address 172.16.1.1 255.255.255.0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
R1(config-if)# tunnel source 1.1.1.1
R1(config-if)# tunnel destination 2.2.2.2
R2(config)# interface Tunnel1
R2(config-if)# ip address 172.16.1.2 255.255.255.0
R2(config-if)# ip mtu 1400
R2(config-if)# ip tcp adjust-mss 1360
R2(config-if)# tunnel source 2.2.2.2
R2(config-if)# tunnel destination 1.1.1.1
После настройки туннели, маршрутизаторы на обоих концах видят друг друга. Это можно проверить при помощи icmp echo.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Рабочие станции в обеих сетях тем не менее не доступны друг для друга до тех пор пока не будет настроен роутинг на обоих маршрутизаторах. В данном примере используем статическую маршрутизацию.
R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.1.2
R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.1.1
Теперь обе сети (192.168.1.0/24 и 192.168.2.0/24) могут обмениваться данными посредством GRE туннеля.
CISCO GRE — в статье рассмотрено развёртывание туннеля GRE и связанные с этим особенности на роутерах CISCO в виртуальной среде EVE-NG.
Немного о GRE
GRE (Generic Routing Encapsulation), нет ничего проще, чем GRE туннель. Буквально пара настроек и туннель готов. Какой-то большой смысловой нагрузки в этом туннеле нет. Но не всё так просто, дальше будет видно 🙂 GRE «всеядный»: GRE может инкапсулировать мульткаст-трафик, броадкаст-трафик. В этом основное его достоинство. Сам GRE не имеет собственного шифрования, отсюда и пользы от GRE в чистом виде нет. Существовать так он может только где-то внутри большой корпоративной сети. В частности GRE может применяться чтобы соединить 2 области IPv6 через область IPv4.
Состоит GRE из 3 компонентов (на картинке):
Тестовая среда
Средой для тестов как всегда является EVE-NG (кто ещё не настраивал, бежать настраивать). Тестовая схема:
Почему такая вот странная схема? Как раз симулирует «большую» корпоративную среду. Роутеры не граничные, ната на них нет, он там не нужен при таком развёртывании. Зато есть какой-то протокол маршрутизации (IGP). Для определённости на всех роутерах настроен EIGRP:
Поэтому есть полная доступность всех адресов с любого устройства:
Нужно обратить внимание, что подсеть 192.168.2.0/24 находится в 5 переходах (хопах) от подсети 192.168.1.0/24. В качестве хопа считается только входящий интерфейс каждого роутера по пути следования пакета.
Настройка GRE
Туннель прокидывается между интерфейсами роутеров R1 и R4:
Особенности настройки
Посмотрим таблицу маршрутизации:
Из таблицы видно, что на данный момент компьютеры ещё не используют туннель, маршрут EIGRP для подсети 192.168.2.0 указывает на интерфейс GigabitEthernet0/0, а должен на интерфейс Tunnel1. Добавим подсеть туннеля в EIGRP:
Роутеры R1 и R4 сформировали отношения смежности через туннель (а значит мультикаст через туннель ходит):
Но если посмотреть снова таблицу маршрутизации, то ничего ровным счетом не изменилось, смотрим теперь таблицу топологии EIGRP:
Маршрут через туннель имеет бОльшую метрику и не попадает в таблицу маршрутизации. Посмотрим интерфейсы:
Проверим/посчитаем метрику EIGRP для каждого интерфейса по формуле:
Всё верно. Как же заставить трафик идти через туннель?
Recursive Routing
Такое случается если роутер пытается достичь destination туннеля через сам туннель.
Как раз наш случай. Рассмотрим подробнее, можно изменять параметры Bandwidth (Delay) на интерфейсах. Изменять Bandwidth не рекомендуется, так как он участвует в расчётах для QoS, SNMP. Рекомендуется крутить Delay. При изменении данных параметров, одного или обоих, физические характеристики интерфейса не изменяются. Эти параметры нужны только для настройки протоколов.
Попробуем уменьшить Bandwidth на интерфейсе GigabitEthernet0/0:
Как только метрика через туннель становится меньше, чем через гигабитный интерфейс, туннель сразу гасится с сообщениями о петле и рекурсивном роутинге.
Можно менять Bandwidth в настройках самого туннеля:
Не пробовал такую настройку, но скорее всего получится то же самое.
Статическая маршрутизация
Смотрим таблицу маршрутизации:
Что произошло? Статический маршрут, который имеет административное расстояние равное 1, заменил собой маршрут EIGRP, у которого административное расстояние (AD) 90. Проверяем на компьютере:
Другой протокол маршрутизации
Убираем статику, иначе она своей AD = 1 забьёт все другие маршруты:
Настраиваем протокол OSPF на R1 и R4:
Обращаю внимание, что для OSPF совпадение Process ID (1 и 101) необязательно.
Убираем информацию о подсетях 192.168.1.0/24, 192.168.2.0/24 из EIGRP:
Зачем это делать? EIGRP имеет AD = 90, против 110 у OSPF. Поэтому пока существует маршрут EIGRP, у маршрута OSPF нет шансов попасть в таблицу маршрутизации.
Смотрим таблицу маршрутизации:
Policy-Based Routing
Возвращаем как было изначально EIGRP:
Если кто обратил внимание, то подсети были добавлены без обратной маски. Так можно сделать потому, что наши подсети совпадают с подсетью класса C.
Пакеты от PC1 к PC2 и обратно снова ходят мимо туннеля.
Создаём ACL для отбора трафика между PC1 и PC2:
Создаём политику перенаправления трафика:
Политика может быть применена для трафика порождаемого внутри самого роутера, тогда она вводится как локальная в режиме глобальной конфигурации. Или же политика применяется для транзитного трафика, тогда она вешается на интерфейс.
PBR для локального трафика
Запускаем трассировку с роутера R1:
Теперь применяем политику и снова проверяем:
PBR для транзитного трафика
Убираем локальную политику:
Вешаем на внутренний интерфейс:
Теперь все пакеты, проходящие через GigabitEthernet 0/1 проверяются на совпадение с ACL 101 и при таком совпадении перенаправляются в туннель. Проверяем для PC1:
Как видно, пакеты для адресов 10.10.0.0/16 по прежнему ходят мимо туннеля, так и должно быть.
Особенности PBR
С PBR нужно обращаться аккуратно, любая ошибка в настройке может привести к неочевидным последствиям. Удалим «случайно» ACL 101 на R1:
Теперь пакеты для адресов 10.10.0.0/16 (кроме адреса интерфейса роутера R1 10.10.10.1) заворачивают сначала в туннель и уже из него к нужному адресу. Маршрут получается не оптимальный, а кривой.
PBR перехватывает пакеты до стандартной маршрутизации. Другими словами PBR действует на входящий (ingress) трафик:
Поэтому если перевесить политику на GigabitEthernet 0/0 (куда прибывают уже смаршрутизированные пакеты), то политика не отрабатывает, попаданий в ACL 101 нет. Включим дебаг и ещё раз запустим пинг с PC1 на PC2. Что при этом происходит, интересная штука:
Политика не проверяет исходящие с GigabitEthernet 0/0 пакеты PC1, но проверяет ответные от PC2, так как они являются входящими для интерфейса.
Keepalive
Протокол GRE по умолчанию является протоколом без отслеживания состояния, то есть статус одной оконечной точки туннеля неизвестен для другой. Интерфейс туннеля сразу переходит в Up, если в таблице маршрутизации имеется маршрут до destination туннеля. Когда маршрут динамический, туннель полагается на таймеры протокола маршрутизации, чтобы отслеживать состояние маршрута и значит состояние туннеля. Если же это статический маршрут, то и механизмов никаких нет.
Механизм Keepalive исправляет эту ситуацию. И траблшутинге позволит сразу оценить в каком состоянии туннель. Подробно работа Keepalive для GRE в реализации CISCO рассказана тут, значения параметров описаны здесь. Параметры:
Кратко перескажу работу Keepalive: сторона туннеля (R1), на которой настроен Keepalive периодически отправляет «хитрые» пакеты другой стороне (R4), когда хитрый пакет распакуется на R4, то внутри окажется обратный пакет для R1 (пустой, без нагрузки). Когда R1 получит обратный пакет, то он поймёт, что всё в порядке. Если обратный пакет не вернётся, то счетчик увеличивается на 1. Когда счётчик достигнет установленного значения, Keepalive переведёт Line Protocol для интерфейса Tunnel в состояние Down. Пользовательский трафик отправляться не сможет. При этом отправка пакетов Keepalive продолжится. Как только будет получен обратный пакет, Line Protocol будет переведён в UP, а счётчик обнулится.
При работе Keepalive сразу можно увидеть когда есть проблема с туннелем по упавшему Line Protocol. Для нашего примера:
Должно быть по умолчанию keepalive 10 5, на практике немного отличается: keepalive 10 3. Теперь посмотрим WireShark:
Теперь погасим интерфейс Tunnel 1 на R4:
И посмотрим что будет на R1:
После поднятия интерфейса туннеля на R4, туннель полностью поднимается и на R1.
Заключение
Рассмотренные примеры больше умозрительные, чем боевые, так как GRE в чистом виде неинтересен, кроме каких-то очень частных случаев. Рекомендую рассмотреть боевую реализацию GRE over IPSec.
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Настройка GRE туннеля на Cisco
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Туннель GRE используется, когда пакеты должны быть отправлены из одной сети в другую через Интернет или незащищенную сеть. В GRE виртуальный туннель создается между двумя конечными точками (маршрутизаторами Cisco), а пакеты отправляются через туннель GRE.
На приведенной ниже схеме показана процедура инкапсуляции простого незащищенного пакета GRE, проходящего через маршрутизатор и входящего в туннельный интерфейс:
Хотя многие могут подумать, что туннель GRE IPSec между двумя маршрутизаторами похож на VPN-соединение IPSec между сайтами, это не так. Основное отличие состоит в том, что туннели GRE позволяют multicast пакетам проходить через туннель, тогда как IPSec VPN не поддерживает multicast пакеты.
В этой статье объясняется, как создавать простые незащищенные (unprotected) и безопасные (IPSec encrypted) туннели GRE между конечными точками. Мы объясним все необходимые шаги для создания и проверки туннеля GRE (незащищенного и защищенного) и настройки маршрутизации между двумя сетями.
Создание Cisco GRE туннеля
Первым шагом является создание нашего туннельного интерфейса на R1:
Все туннельные интерфейсы участвующих маршрутизаторов всегда должны быть настроены с IP-адресом, который не используется где-либо еще в сети. Каждому туннельному интерфейсу назначается IP-адрес в той же сети, что и другим туннельным интерфейсам.
В нашем примере оба туннельных интерфейса являются частью сети 172.16.0.0/24.
Как только мы завершим настройку R1, маршрутизатор подтвердит создание туннеля и сообщит о его состоянии:
Поскольку интерфейс Tunnel 0 является логическим интерфейсом, он останется включенным, даже если туннель GRE не настроен или не подключен на другом конце.
Далее мы должны создать интерфейс Tunnel 0 на R2:
Интерфейс туннеля R2 настроен с соответствующим IP-адресом источника и назначения туннеля. Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 работает:
Маршрутизация сетей через туннель GRE
На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Echo icmp от одного конца подтвердит это:
Опять же, этот результат означает, что две конечные точки туннеля могут видеть друг друга. Рабочие станции в любой сети по-прежнему не смогут достичь другой стороны, если на каждой конечной точке не установлен статический маршрут:
На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0/24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель.
Та же конфигурация должна быть повторена для R2:
Теперь обе сети могут свободно общаться друг с другом через туннель GRE.
Защита туннеля GRE с помощью IPSec
Как упоминалось ранее, GRE является протоколом инкапсуляции и не выполняет шифрование. Создание туннеля GRE точка-точка без какого-либо шифрования чрезвычайно рискованно, поскольку конфиденциальные данные могут быть легко извлечены из туннеля и просмотрены другими.
Для этого мы используем IPSec для добавления уровня шифрования и защиты туннеля GRE. Это обеспечивает нам необходимое шифрование военного уровня и спокойствие. Наш пример ниже охватывает режим туннеля GRE IPSec.
Настройка шифрования IPSec для туннеля GRE (GRE over IPSec)
Шифрование IPSec включает в себя два этапа для каждого маршрутизатора. Эти шаги:
Настройка ISAKMP (ISAKMP Phase 1)
IKE существует только для установления SA (Security Association) для IPsec. Прежде чем он сможет это сделать, IKE должен согласовать отношения SA (ISAKMP SA) с партнером.
Для начала, мы начнем работать над R1.
Первым шагом является настройка политики ISAKMP Phase 1:
Далее мы собираемся определить Pre Shared Key (PSK) для аутентификации с партнером R1, 2.2.2.10:
PSK ключ партнера установлен на merionet. Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2).
Создание IPSec Transform (ISAKMP Phase 2 policy)
Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS:
Вышеуказанные команды определяют следующее:
Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec. Мы назвали наш профиль IPSec protect-gre:
Теперь мы готовы применить шифрование IPSec к интерфейсу туннеля:
Ну и наконец пришло время применить ту же конфигурацию на R2:
Проверка GRE over IPSec туннеля
Наконец, наш туннель был зашифрован с помощью IPSec, предоставляя нам столь необходимый уровень безопасности. Чтобы проверить и проверить это, все, что требуется, это попинговать другой конец и заставить туннель VPN IPSec подойти и начать шифрование/дешифрование наших данных:
Используя команду show crypto session, мы можем быстро убедиться, что шифрование установлено и выполняет свою работу:
Поздравляю! Мы только что успешно создали Point-to-point GRE over IPSec VPN туннель между двумя маршрутизаторами Cisco.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
GRE (Generic Routing Encapsulation — общая инкапсуляция маршрутов) — протокол туннелирования сетевых пакетов, разработанный компанией CISCO Systems. Его основное назначение — инкапсуляция пакетов сетевого уровня сетевой модели OSI в IP пакеты. Номер протокола в IP — 47.
Что такое GRE туннель?
Различия между туннель GRE или IPIP:
Туннелирование увеличивает нагрузку на систему и сеть, потому что добавляются дополнительные IP-заголовки. Таким образом, если обычный размер пакета (MTU) в сети равен 1500 байтам, то при пересылке по туннелю, пакет будет меньше, 1476 байт для GRE и 1480 байт для IPIP. Задать MTU можно вручную или с помощью PMTUD (path MTU discovery). Основная проблема в ручной настройке MTU и/или MSS состоит в том, что по пути между вашими площадками может оказаться линк с MTU, скажем, 1300. Тут на помощь может прийти PMTUD. Протокол целиком и полностью полагается на ICMP протокол диагностики перегрузки сети unreachable messages, которые должны быть разрешены на всем пути между соседями. Cisco рекомендует устанавливать MTU в 1400 байт вне зависимости от того работает GRE поверх IPSec в туннельном или в транспортном режиме.
Туннелирование подразумевает три протокола:
Как происходит инкапсуляции заголовка GRE в IP-пакет?
GRE-заголовок накладывается «поверх» стандартного IP-пакета. При этом в самом GRE-заголовке содержится так называемый Tunnel IP Header. Именно в нем содержится информация о tunnel source и tunnel destination.
Данные адреса вкладываются в основной пакет, когда он отправляется в публичную сеть. В поле Control Information оригинального IP-пакета содержатся исходные IP-адреса источника и назначения. Таким образом, локальные серые IP-адреса скрыты в пакете, а в маршрутизации участвуют только те адреса которые мы указали в tunnel source и tunnel destination. При передаче пакета в локальную сеть GRE-заголовок отбрасывается и остается «чистый» IP-пакет.
Настройка GRE туннелей в Debian GNU/Linux
Настройка GRE туннелей в FAQ Debian и Хостинг VPS/VDS на Ubuntu одинаковы. Имеется 2 удаленных сервера Debian 7.8 Wheezy с реальными статическими IP адресами.
То же самое только через файл /etc/network/interfaces
В файл /etc/network/interfaces это будет выгладить так
Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP)
