GRE (протокол)


GRE (англ. Generic Routing Encapsulation — общая инкапсуляция маршрутов) — протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Его основное назначение — инкапсуляция пакетов сетевого уровня сетевой модели OSI в IP-пакеты. Номер протокола в IP — 47.

IP/GRE является самостоятельным транспортным протоколом, и не опирается на протоколы типа TCP или UDP. Размер заголовка GRE составляет 4 байта, что совместно с заголовком IP в 20 байт уменьшает MTU полезной нагрузки в виде инкапсулируемых данных на 24 байта.

Туннелирование подразумевает три протокола:

Пример работы GRE-туннеля. Между двумя маршрутизаторами A и B находится несколько маршрутизаторов, туннель позволяет обеспечить связь между разными сетевыми сегментами 192.168.1.0/24 и 192.168.3.0/24 так, как если бы маршрутизаторы A и B были в одной канальной среде.

Пример применения

Пример стека протоколов

Уровень модели OSI Протокол
5. Сеансовый X.225
4. Транспортный UDP
3. Сетевой (GRE-инкапсуляция) IPv6
4. Транспортный (Инкапсуляция) GRE
3. Сетевой IPv4
2. Канальный Ethernet
1. Физический Ethernet

В данном примере протокол GRE позволяет инкапсулировать в себя протокол сетевого уровня, не смотря на то, что сам является протоколом транспортного уровня. Это позволяет передать пакет IPv6 поверх IPv4 без обработки до конечной точки, где предполагается его извлечение, и далее обработка уже как самостоятельного пакета L3. Это свойство и позволяет строить сеть внутри сети (VPN).

Проблема 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 MSS у всех транзитных соединений. Этот способ подходит тогда, когда path-mtu-discovery не работает адекватно или не работает вовсе. Так же можно использовать принудительное снятие бита DF, тем самым побуждая маршрутизатор совершить фрагментацию пакета, но этот способ не рекомендуется, поскольку увеличивает количество передаваемых пакетов и количество служебной информации (overhead), тем самым снижая максимально доступную пропускную способность и увеличивая нагрузку на оборудование. В том числе следует помнить, что сама процедура фрагментации так же требует дополнительного буфера памяти для хранения фрагментов, а так же вычислительных мощностей для совершения сборки и фрагментирования пакетов.

Проблема NATа

Так как GRE является протоколом транспортного уровня, который не использует порты (в отличие от протоколов TCP и UDP), а одним из необходимых условий работы механизма PAT является наличие «открытого» порта, то работа протокола GRE через межсетевой экран может быть затруднена[3].

Для GRE, работающего совместно с PPTP эта задача решается, благодаря тому, что PPTP согласует оконечные точки соединения и маршрутизатор совершающий NAT, с технологией PPTP Passthrough или ее разновидностью может построить в таблице трансляции соответствующее правило.

Для чистого GRE этот способ не подходит, поскольку оконечные точки указываются непосредственно при конфигурировании протокола, и если в одну сторону (клиент за NAT) пакеты еще могут быть транслированы, то обратный трафик не сможет быть транслирован, поскольку в своём составе GRE не имеет инструментов для сопоставления сеанса связи. Единственное решение может быть только статическая настройка SNAT\DNAT.

Примечания

  1. О решении проблемы DF-бита и MTU на оборудовании cisco: [1] Архивная копия от 29 июня 2013 на Wayback Machine
  2. О проблеме фрагментации пакетов в GRE- и IPSEC-туннелях: [2] Архивная копия от 26 июня 2013 на Wayback Machine
  3. NAT and PPTP. Дата обращения: 3 февраля 2013. Архивировано 7 октября 2013 года.

Ссылки