GRE (протокол)
GRE (англ. Generic Routing Encapsulation — общая инкапсуляция маршрутов) — протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Его основное назначение — инкапсуляция пакетов сетевого уровня сетевой модели OSI в IP-пакеты. Номер протокола в IP — 47.
IP/GRE является самостоятельным транспортным протоколом, и не опирается на протоколы типа TCP или UDP. Размер заголовка GRE составляет 4 байта, что совместно с заголовком IP в 20 байт уменьшает MTU полезной нагрузки в виде инкапсулируемых данных на 24 байта.
Туннелирование подразумевает три протокола:
- пассажир — инкапсулированный протокол (IP, CLNP, IPX, AppleTalk, DECnet Phase IV, XNS, VINES и Apollo)
- протокол инкапсуляции (GRE)
- сетевой протокол (IP)
Пример применения[править | править код]
- Используется в сочетании с PPTP для создания виртуальных частных сетей.
- Применяется в технологии WDS для координации действий точек доступа и контроллера WDS.
- Используется в технологиях мобильного IP
Пример стека протоколов[править | править код]
| Уровень модели OSI | Протокол |
|---|---|
| 5. Сеансовый | X.225 |
| 4. Транспортный | UDP |
| 3. Сетевой (GRE-инкапсуляция) | IPv6 |
| 4. Транспортный (инкапсуляция) | GRE |
| 3. Сетевой | IPv4 |
| 2. Канальный | Ethernet |
| 1. Физический | Ethernet |
В данном примере протокол GRE позволяет инкапсулировать в себя протокол сетевого уровня, несмотря на то, что сам является протоколом транспортного уровня. Это позволяет передать пакет IPv6 поверх IPv4 без обработки до конечной точки, где предполагается его извлечение, и далее обработка уже как самостоятельного пакета L3. Это свойство и позволяет строить сеть внутри IP сети (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.
Примечания[править | править код]
- ↑ О решении проблемы DF-бита и MTU на оборудовании cisco: [1] Архивная копия от 29 июня 2013 на Wayback Machine
- ↑ О проблеме фрагментации пакетов в GRE- и IPSEC-туннелях: [2] Архивная копия от 26 июня 2013 на Wayback Machine
- ↑ NAT and PPTP. Дата обращения: 3 февраля 2013. Архивировано 7 октября 2013 года.
Ссылки[править | править код]
- Проблема DF-бита и фрагментации в GRE туннелях
- Создание VPN GRE-туннеля в Linux
- RFC 1701 — Generic Routing Encapsulation (GRE), октябрь 1994
- RFC 1702 — Generic Routing Encapsulation over IPv4 networks, октябрь 1994
- RFC 2784 — Generic Routing Encapsulation (GRE), июль 2000
- RFC 2890 — Key and Sequence Number Extensions to GRE, сентябрь 2000
