Кратко

  • RFC 2784 разделяет внешний заголовок доставки, заголовок GRE и полезную нагрузку. Базовые четыре октета называют внутренний протокол, но не определяют назначение туннеля, круг пользователей, доступность после снятия оболочки или безопасность содержимого.
  • Tony Li был соавтором GRE-документа 1994 года и спецификации IETF 2000 года. Более поздние RFC показывают операционный долг: поле Key — метка контекста, а не секрет; Sequence Number создаёт состояние и риск отказа; перенос IPv6 требует постоянной проверки MTU и целостности на обоих концах.

Один пакет получает два адреса назначения

На входе в GRE исходный пакет становится полезной нагрузкой. Перед ним помещается заголовок GRE, а снаружи — заголовок доставки. Опорная сеть читает внешний адрес и доставляет всю конструкцию к выходу. Там внешние слои снимаются, и внутренний адрес снова управляет пересылкой.

Так возникают три независимые записи. Заголовок доставки называет концы туннеля. GRE сообщает тип содержимого и наличие дополнительных функций. Внутренний пакет сохраняет источник, назначение, время жизни и смысл верхнего уровня. Исправный внешний маршрут доказывает только доставку конверта. Он не доказывает внутренний маршрут, разрешение после снятия оболочки или правильную точку проверки безопасности.

RFC 2784, опубликованный в марте 2000 года в качестве стандарта IETF, подписан Dino Farinacci, Tony Li, Stan Hanks, David Meyer и Paul Traina. Ему предшествовал информационный RFC 1701 авторов Hanks, Li, Farinacci и Traina. Профиль Tony Li в IETF Datatracker фиксирует публичную личность, перечень RFC и роли на дату снимка. Эти данные подтверждают коллективное авторство, но не единоличное изобретение, нынешнего работодателя или личную власть над развёрнутыми сетями.

Связь с человеком уже и точнее: Li присутствует и в исходном описании общей оболочки, и в документе, сократившем её общий центр. Долговечным решением была не власть над всеми вариантами применения, а отказ переносить лишние решения в общий заголовок.

Общий конверт вместо матрицы частных сочетаний

Если для каждого протокола полезной нагрузки поверх каждого протокола доставки нужна отдельная техника, число сочетаний растёт матрицей. RFC 2784 называет проблему O(n²) и делит её на полезную нагрузку, общий слой GRE и доставку.

Всеобщность имеет заявленные пределы. Специфические нюансы протоколов отброшены, поэтому отдельная схема X over Y иногда лучше. Главное — RFC намеренно не отвечает, когда пакет следует помещать в оболочку. Он задаёт грамматику, а не законность применения.

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

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

Четыре октета сообщают только то, что должен знать сосед

Без необязательной контрольной суммы базовый заголовок RFC 2784 состоит из двух 16-битных слов. Первое содержит признак контрольной суммы, зарезервированные биты и номер версии; второе — Protocol Type, то есть EtherType полезной нагрузки. Базовая версия равна нулю.

В нём нет всемирного идентификатора туннеля, владельца, политики, маршрута, заявления о шифровании или обещания качества услуги. Он лишь объясняет, как читать следующие байты. Неизвестный Protocol Type следует отбросить. Зарезервированные биты передаются нулевыми; определённые ненулевые позиции требуют отбрасывания, если приёмник не реализует прежнее поведение.

Контрольная сумма добавляет четыре октета и покрывает заголовок GRE с полезной нагрузкой обычной контрольной суммой Internet. Она способна заметить часть случайных повреждений, но не подтверждает отправителя, не скрывает содержимое и не выдаёт право доступа. Правильная сумма не равна доверенному туннелю.

Минимальная спецификация не означает неопределённость. Она строго фиксирует небольшое число совместных фактов и оставляет остальные решения видимыми за своей границей.

После раскрытия маршрут снова принадлежит полезной нагрузке

Для IPv4 внутри GRE RFC 2784 требует использовать внутренний адрес назначения и уменьшить внутренний TTL. Внешнее назначение выполнило доставку и не заменяет правила маршрутизации содержимого.

Документ также описывает петлю: если внутреннее назначение указывает на устройство инкапсуляции на другом конце, пакет может снова войти в тот же туннель и должен быть отброшен. Туннель скрывает топологию, но не отменяет последствия петли.

Для диагностики это принципиально. Внешний traceroute достигает выхода при отсутствии внутреннего маршрута. Интерфейс показывает up, а полезная нагрузка отвергается после снятия оболочки. Сбой, приписанный GRE, может находиться в опорной сети, обратном пути, фильтре или MTU. Три записи нужно наблюдать раздельно и связывать одним пакетом.

Стандартизация уменьшила общий центр

RFC 1701 предлагал поля Routing, Key, Sequence, Strict Source Route и Recursion Control. RFC 2784 выбрал пересечение, уже реализованное несколькими поставщиками, и исключил эти функции из базового профиля. Приёмник без явно заявленной поддержки старого формата отбрасывает пакет с соответствующими ненулевыми битами.

Это не обычная история накопления возможностей. Общее значение стало меньше, чтобы независимые системы увереннее соглашались о меньшем. Необязательная функция могла вернуться через отдельное определённое расширение, а не через догадку о зарезервированном пространстве.

Совместимость здесь — объяснимая граница отказа. Мягко принять незнакомую раскладку не значит исправить разницу возможностей. Оператор доказывает совместимость обоих концов, включает только согласованный профиль и сохраняет возможность отката к прежнему порядку разбора.

Поле Key не является ключом безопасности

RFC 2890, написанный Govindan Dommety, а не Li, позднее определил необязательные поля Key и Sequence Number. Четырёхоктетный Key обозначает поток или контекст между концами; способ назначения находится вне документа.

Название провоцирует ошибку, которую RFC отдельно отвергает: Key не участвует в безопасности. По местному соглашению он различает клиентов или услуги, но без внешней защиты участник, способный создать GRE, может скопировать или придумать значение. Метка контекста — не пароль.

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

RFC 2890 требует IPsec AH или ESP для защиты от этой атаки. Он советует не дублировать упорядочивание, если верхний уровень уже его обеспечивает или терпит перестановку. Включение необязательного поля означает память, очереди, счётчики, журналы и поверхность атаки на обоих концах.

Фильтр должен находиться там, где виден внутренний смысл

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

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

Проверяемая архитектура записывает разрешённые внутренние префиксы и протоколы, место снятия оболочки, точку проверки и реальное применение IPsec. GRE up — не состояние безопасности. Доказательством служит действующая политика двух слоёв на наблюдаемом пакете.

IPv6 превратил пропуски в условия активации

RFC 7676, авторами которого являются Carlos Pignataro, Ron Bonica и Suresh Krishnan, позднее описал IPv6 как содержимое или протокол доставки GRE. Это не работа Li. Она показывает, как тонкий общий договор встречает конкретные обязанности новой сетевой среды.

Туннель с IPv6 внутри должен переносить пакет в 1280 октетов от входа к выходу без фрагментации внутреннего пакета. Входное устройство проверяет способность до активации и периодически после неё, включая или выключая туннель по результату. GMTU равен MTU пути между концами за вычетом заголовка доставки и накладных расходов GRE. Слишком большой внутренний пакет при описанных условиях отбрасывается, а ICMPv6 Packet Too Big возвращает допустимое значение.

Малый заголовок не устраняет размер. Он делает накладные расходы вычислимыми, а проверку и обратную связь — обязанностью конечной точки. Потеря Packet Too Big создаёт обман: небольшие пробы проходят, крупные потоки зависают, система управления остаётся зелёной.

Есть и граница целостности. Отключение контрольной суммы GRE экономит повторные вычисления, но внешний заголовок IPv6 не имеет собственной суммы, а GRE всё равно его не покрывает. RFC 7676 разбирает редкий случай: повреждённый внешний адрес назначения доставляет пакет не тому пограничному устройству VPN; совпадающее пространство частных адресов и состояние могут отправить содержимое в чужую VPN. GRE over IPv6 нельзя включать там, где оператор не принял этот риск; сквозная аутентификация внутренней нагрузки может его уменьшить.

RFC не утверждает, что сбой произошёл в конкретной сети. Он устанавливает вопрос с местным владельцем решения. Общая переносимость не является общей безопасностью.

Тонкая координация требует толстого доказательства на краях

Более поздний текст Lu Heng Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption даёт Sofia Ren рамку для GRE. Общими остаются раскладка, версия, тип, расширения и поведение при отказе. Каждая сеть сохраняет свободу и обязанность решить цель, конечные точки, допуск трафика, безопасность и вывод из эксплуатации.

Running-Code Primacy повышает стандарт доказательства. Объект конфигурации — только намерение. Реальность соединяет внешний маршрут, отправленные флаги, Protocol Type, фактические накладные расходы, контекст Key, связь IPsec, внутренний маршрут, решение фильтра, обратную связь MTU, счётчики и результат приложения.

Эти тексты Heng — поздняя редакционная рамка, а не свидетельство личного намерения Li или консенсуса IETF вне процитированных RFC. Они проясняют распределение: стандарт отвечает за общий конверт; реализация — за разбор и состояние; оператор — за все причины, по которым конверт разрешён.

GRE сохранился, потому что не управляет полезной нагрузкой. Такая сдержанность сделала его переносимым. Она же означает, что внутри четырёх октетов нет института, который спасёт небрежное развёртывание. Конверт способен нести почти всё; только конечные точки могут доказать, что именно ему следует нести.

Источники