← Cloudflare Magic Transit / magic-transit / reference

Максимальный размер передаваемого блока данных и максимальный размер сегмента

Поскольку Magic Transit оборачивает ваш трафик в дополнительные заголовки (инкапсуляция), в каждом пакете остаётся меньше места для исходных данных. Если не учитывать эти дополнительные издержки, пакеты могут оказаться слишком большими для сетевого пути и будут отброшены или фрагментированы, что приводит к снижению производительности или обрыву соединений. На этой странице описаны два ключевых параметра, которые нужно настроить: максимальный размер передаваемого блока (MTU) и максимальный размер сегмента (MSS).

максимальная единица передачи (MTU) ↗ это показатель, обозначающий наибольший пакет данных, который примет устройство, подключённое к сети. MTU почти всегда относится к уровню 3 модели OSI (Open Systems Interconnection) в сетевых технологиях и включает весь пакет целиком, в том числе все заголовки (Transmission Control Protocol (TCP), Internet Protocol (IP) и так далее) и сами данные (полезную нагрузку). Например, пакеты не должны превышать 1,500 байт, чтобы маршрутизироваться через интернет.

максимальный размер сегмента (MSS) ↗ обозначает объем данных, который можно передать в одном пакете TCP-дейтаграммы. Это значение вычисляется путем вычитания размера заголовков IP и TCP из MTU, который определяет для маршрутизатора максимальный размер полезной нагрузки. Он относится к уровню 4 модели OSI в сетевых технологиях.

Распространённое заблуждение о MSS/MTU состоит в том, что настройка этих значений якобы негативно влияет на производительность. Хотя небольшое снижение производительности действительно возможно, гораздо хуже не настраивать эти значения с учётом особенностей вашей сети.

Поскольку Magic Transit использует инкапсуляцию для предоставления своих услуг, важно также понимать, почему в этом случае имеют значение MTU и MSS.

Инкапсуляция добавляет байты к пакету, потому что Cloudflare добавляет новый IP-заголовок и (часто) какой-либо инкапсулирующий заголовок к каждому пакету. Например, в случае Generic Routing Encapsulation (GRE) для Internet Protocol version 4 (IPv4) инкапсуляция добавляет 24 байта: 20 байт на заголовок IPv4 и 4 байта на заголовок туннеля GRE.

Сетевому интерфейсу, выполняющему инкапсуляцию GRE, необходимо учитывать дополнительные накладные расходы, уменьшая значение MTU. Поскольку максимальный размер MTU составляет 1,500 байт, для IPv4 это означает, что MTU становится равным 1,476 байт (исходные 1,500 байт минус 24 байта на инкапсуляцию GRE). Этот уменьшенный MTU определяет максимальный размер IP-пакета, который может инкапсулировать GRE.

Если пакет данных превышает размер, который может принять сетевой интерфейс, сеть должна либо отбросить его, либо разбить на более мелкие пакеты. При фрагментации Cloudflare принимает только те пакеты данных, которые может полностью собрать обратно. Если часть фрагментов отсутствует, Cloudflare отбрасывает все полученные фрагменты. Cloudflare не пересылает клиенту неполные пакеты.

Установка бита DF (do not fragment) в заголовке TCP в значение 1 означает, что сеть должна отбросить пакет, а не фрагментировать его, если пакет больше значения MTU, которое могут принять промежуточные сетевые устройства. Большинство реализаций TCP устанавливают бит DF в 1 чтобы избежать возможных проблем, вызванных фрагментацией.

Если у вас возникают проблемы с фрагментацией и вы не можете задать MSS clamp, Cloudflare может сбрасывать бит DF за вас. При включении этой опции Cloudflare фрагментирует пакеты размером более 1,500 байт, а ваша инфраструктура собирает их заново после декапсуляции. Используйте эту опцию только в крайнем случае. За дополнительной информацией обратитесь в свою команду по работе с аккаунтом.

Рассмотрим датаграмму UDP размером 3,000 байт (8 байт для заголовка UDP + 2,992 байт для данных UDP). Чтобы уместиться в стандартный MTU размером 1,500 байт, эта датаграмма UDP будет фрагментирована на три IP-пакета следующим образом:

Предположим, что UDP-дейтаграмма имеет исходный порт 389 и предназначен для IP-адреса клиента Magic Transit. Предположим также, что у клиента Magic Transit настроено правило межсетевого экрана, отбрасывающее UDP-трафик с исходным портом 389, общий Lightweight Directory Access Protocol (CLDAP) без установления соединения ↗ вектор атаки с отражением.

Все три предыдущих фрагмента пакета поступят в Cloudflare, но только первый фрагмент содержит заголовок UDP с информацией об исходном порте. Второй и третий фрагменты содержат данные UDP, но не содержат информации заголовка UDP.

Итак, вопрос в следующем: какие из этих фрагментов Cloudflare отбрасывает, а какие доставляет клиенту? Если Cloudflare отбрасывает только первые части фрагментированных пакетов, оставшиеся части все равно могут создавать большой объем трафика во время атаки типа «отказ в обслуживании» (DoS).

На следующей диаграмме показано, как три фрагмента UDP из предыдущего примера проходят через Cloudflare и Magic Transit. Основные выводы:

• Cloudflare никогда не отправляет клиентам неполные пакеты: Если Cloudflare не видит все части пакета, необходимые для его полной пересборки, она не отправляет клиенту частичные фрагменты данных.
• Cloudflare Network Firewall работает с полностью собранными пакетами, а не с отдельными фрагментами: Это означает, что фильтры, срабатывающие, например, по информации заголовков UDP/TCP, применяются к полностью пересобранному пакету, а не только к начальному фрагменту. Cloudflare не передает клиентам неначальные фрагменты.
• Клиенты по-прежнему могут видеть фрагментированные пакеты: По умолчанию (без clear_dont_fragment_bit задан), Cloudflare фрагментирует пакеты, чтобы уместить их в настроенный MTU туннеля, перед отправкой данных клиенту. Если пакет превышает 1,476 байт, Cloudflare разделит его на фрагменты и отправит клиенту для повторной сборки.

Во всех случаях Cloudflare отправляет клиенту все фрагменты.

Maximum segment size (MSS) представляет собой параметр TCP, который ограничивает размер TCP-сегментов. Пакеты SYN устанавливают этот параметр в ходе трёхэтапного рукопожатия.

По умолчанию конечная точка TCP задает значение MSS на основе MTU своего локального сетевого интерфейса. Например, для IPv4 при MTU 1500 байт значение MSS составит 1460 байт (1500 байт минус 20 байт заголовка IPv4 минус 20 байт заголовка TCP).

MSS представляет собой инструмент, который можно использовать для настройки поведения размера пакетов TCP. Если конечная точка TCP находится за сетью с уменьшенным значением MTU, изменение значения MSS в соответствии с фактическим значением MTU пути вынуждает удалённые конечные точки отправлять пакеты, помещающиеся в указанный MTU. Так, если конечная точка TCP IPv4 находится за туннелем GRE с MTU 1,476 байт, значение MSS в её пакетах TCP SYN должно составлять 1,436 байт (1,476 байт минус 20 байт заголовка IPv4, минус 20 байт заголовка TCP).

Один из способов изменить настройку MSS: изменить MTU сетевого интерфейса в WAN-интерфейсе маршрутизатора так, чтобы он соответствовал path MTU. Другой способ изменить MSS: применить MSS clamp, при котором промежуточное сетевое устройство, например маршрутизатор, настраивается так, чтобы изменять опцию TCP MSS на лету при прохождении пакетов через него. Обратите внимание, что изменение MTU на интерфейсе промежуточного сетевого устройства не то же самое, что применение MSS clamp, и оно не изменяет значение TCP MSS.

См. рекомендации по MSS clamping с информацией о том, какое значение следует задать для MSS clamping в зависимости от типа туннеля.

Асимметричная маршрутизация ↗ распространённый сценарий, особенно в случае Magic Transit. Входящий трафик из интернета попадает в сеть Cloudflare, затем проходит через GRE-туннель (MTU 1,476 байт), а исходящий трафик из дата-центра отправляется через интернет с использованием Direct Server Return (DSR) (MTU 1,500 байт).

В асимметричном сценарии необходимо уменьшить значение MSS пакетов, отправляемых пользователями Magic Transit в интернет, чтобы уменьшить размер пакетов, поступающих из интернета в их сеть. Для этого настройте либо конечные узлы клиента, либо ограничение MSS на промежуточном устройстве на исходящем пути трафика, покидающего его сеть. В следующей таблице показано, как значения MSS влияют на размер полезной нагрузки на обоих маршрутах.

Главный вывод из предыдущей таблицы: ограничение MSS влияет на размер полезной нагрузки TCP-пакетов, передаваемых в направлении, противоположном тому, где применяется это ограничение.

Ограничение MSS действует только на TCP-трафик. Например, если у вас есть веб-сервер на префиксе Magic Transit, ограничение MSS применяется к TCP-данным трафика Direct Server Return (DSR). Однако для туннелей внутри вашего туннеля Magic Transit (сценарий «туннель в туннеле») потребуется другой подход.

Например, если у вас настроен туннель GRE Magic Transit, а также работает ещё один туннель IPsec или GRE от сторонних устройств на вашей территории, MSS clamp не влияет на внешние пакеты инкапсулированного трафика. Это происходит потому, что MSS clamping затрагивает только трафик TCP, а инкапсулированный трафик IPsec/GRE является IP-трафиком. В этом случае нужно дополнительно снизить MTU внутреннего интерфейса туннеля как для входящего, так и для исходящего трафика.

Значение MSS зависит от настройки вашей сети.

• Только входящий трафик Magic Transit (DSR):

  • На транзитных портах вашего пограничного маршрутизатора: Установите TCP MSS clamp не более 1,436 байт.
  • На любых туннелях IPsec/GRE со сторонними организациями в рамках вашего префикса Magic Transit: Примените MSS clamp на внутреннем интерфейсе туннеля (скорее всего, на отдельном межсетевом экране за маршрутизатором, завершающим GRE-туннель), чтобы уменьшить текущее значение на 24 байта.

• Для входящего и исходящего трафика Magic Transit:

  • На внутреннем интерфейсе GRE-туннеля Magic Transit: То есть там, где будет проходить исходящий трафик Magic Transit. После настройки туннеля ваши устройства могут делать это автоматически, но это зависит от конкретного оборудования. Установите TCP MSS clamp не более 1,436 байт.
  • На любых туннелях IPsec/GRE со сторонними организациями в рамках вашего префикса Magic Transit: На внутреннем интерфейсе туннеля (скорее всего, на отдельном межсетевом экране за маршрутизатором, завершающим GRE-туннель), чтобы уменьшить текущее значение на 24 байта.

Для туннелей IPsec значение, которое нужно указать, зависит от того, как настроена ваша сеть. Значение MSS clamping для них ниже, чем для туннелей GRE, поскольку физический интерфейс получает IPsec-зашифрованный пакеты ↗, а не TCP-пакетов, поэтому MSS clamping к ним не применяется.

• Только входящий трафик Magic Transit (DSR):

  • На транзитных портах вашего пограничного маршрутизатора: Установите TCP MSS clamp на значение не более 1,436 байт.
  • На любых туннелях IPsec/GRE со сторонними организациями в рамках вашего префикса Magic Transit: На внутреннем интерфейсе туннеля (скорее всего, на отдельном межсетевом экране за маршрутизатором, завершающим GRE-туннель), чтобы уменьшить текущее значение на 140 байт.

• Входящий и исходящий трафик Magic Transit:

  • На вашем пограничном маршрутизаторе: Примените это на внутреннем интерфейсе IPsec-туннеля Magic Transit (то есть там, где будет проходить исходящий трафик Magic Transit). После настройки туннеля ваши устройства могут делать это автоматически, но это зависит от конкретного оборудования. Установите TCP MSS clamp не более 1,360 байт.
  • На любых туннелях IPsec/GRE со сторонними организациями в рамках вашего префикса Magic Transit: На внутреннем интерфейсе туннеля (скорее всего, на отдельном межсетевом экране за устройством, завершающим IPsec, в вашей инфраструктуре), чтобы уменьшить текущее значение на 140 байт.