Требуется фрагментация пакетов, но отключите установку флага в Windows 10
Обновлено: 02.07.2024
Прежде чем мы углубимся в детали, важно отметить несколько моментов. Во-первых, frag3 заменяет frag2, который мы обсудим позже, а во-вторых, frag2 будет удален из Snort в ближайшем будущем, так что вам следует больше не использовать этот препроцессор. При этом давайте рассмотрим, что такое фрагментация и как она используется как законно, так и злонамеренно.
Фрагментация — это нормальная часть Интернет-протокола (IP). По сути, каждый тип сети потенциально имеет разную максимальную единицу передачи (MTU), число, которое количественно определяет, сколько данных может быть передано в одном «фрагменте» на носителе. Например, MTU Ethernet составляет 1500 байт, и он называет свои фрагменты данных кадры. Передающий IP-стек при обмене данными обычно помещает в пакет столько данных, сколько может, в основном используя MTU исходящего трафика. сети в качестве максимального размера для исходящего фрагмента. Если пакет слишком велик для прохождения между двумя маршрутизирующими устройствами, он разбивается на фрагменты. Эти фрагменты сами по себе выглядят как IP-пакеты и могут передаваться по сети. Они снова собираются, когда достигают места назначения. Хост, получающий фрагментированные пакеты, должен собрать пакеты вместе в правильном порядке, чтобы понять смысл получаемого трафика. Проблема в том, что разные операционные системы собирают фрагменты в разном порядке! (Мы обсудим этот вопрос более подробно при обсуждении frag3 далее в этой главе.)< /p>
frag2 также полезен для обнаружения атак типа "отказ в обслуживании" (DoS) на основе фрагментов. Эти атаки часто отправляют серию хорошо спроектированных фрагментов, чтобы воспользоваться конкретными уязвимостями стека IP хоста. Например, некоторые машины перезагружаются, останавливаются или иным образом негативно реагируют на получение фрагмента, смещение которого настроено на перезапись данных предыдущего фрагмента. Помните, что фрагменты должны быть непересекающимися частями пакета — перекрывающийся фрагмент — это просто тип кажущегося невозможным условия, из-за которого хост зависает.
Настройка фрагмента2
Вы можете настроить frag2, добавив параметры после двоеточия в директиву препроцессора frag2:
< бр />
Давайте рассмотрим параметры, которые принимает frag2:
тайм-аут. Параметр тайм-аута указывает frag2 прекратить попытки восстановить фрагментированный пакет, если он не получил фрагмент в течение заданного количества секунд. Значение по умолчанию, равное 30 секундам, почти наверняка слишком агрессивно. Лучшее значение по умолчанию, вероятно, составляет от 60 до 90 секунд. Сайты, которые предполагают, что злоумышленник может либо использовать ссылки с высокой задержкой, либо намеренно замедлить атаку, должны установить это число немного выше.
память. Параметр memcap ограничивает объем памяти, который Snort может использовать для хранения частично перестроенных пакетов. Когда frag2 использует всю эту память, он начнет агрессивно удалять частично перестроенные пакеты из своей таблицы фрагментов. Значение по умолчанию 4 МБ может быть слишком агрессивным, особенно на сильно загруженном внешнем сетевом интерфейсе. Вероятно, это слишком агрессивно для хоста на другом конце канала с низким MTU.
мин_ttl. Параметр min_ttl задает минимальное время жизни IP (TTL), которое должно быть у пакетов для повторной сборки Snort. Если TTL пакета слишком мал, чтобы дойти до места назначения, вам, как правило, не нужно беспокоиться о том, что он несет атаку на основе полезной нагрузки. Хост назначения не получит пакет; таким образом, атака на основе полезной нагрузки не повредит этому хосту. Это не означает, что пакеты, которые не достигают хоста, не могут иметь негативных последствий! Если злоумышленник отправляет огромное количество пакетов, которые умирают на маршрутизаторе непосредственно перед тем, как они достигают узла назначения, этот узел назначения почти наверняка обнаружит, что соответствующее сетевое соединение перегружено и, следовательно, бесполезно. Злоумышленники часто используют атаки на основе фрагментов для выполнения DoS-атак. Параметр min_ttl просто запрещает frag2 выделять ресурсы для пакетов, которые не достигают адресата. Вы должны установить этот параметр на минимальное количество прыжков между сетью IDS и отслеживаемыми хостами.
ttl_limit. Параметр ttl_limit устанавливает максимальное допустимое различие между фрагментами одного и того же пакета. Фрагменты одного и того же пакета, как правило, должны проходить через примерно одинаковое количество маршрутизаторов на пути между двумя хостами. Даже когда они идут разными путями, у них должно быть примерно одинаковое количество прыжков. Если количество прыжков меняется слишком резко, это может быть признаком того, что кто-то пытается избежать обнаружения.Например, злоумышленник может вставить в поток фрагменты, которые дойдут до IDS, но срок их действия истечет до того, как они достигнут места назначения. Это приводит к тому, что IDS видит изображение перестроенного пакета, отличное от изображения хоста назначения. Трудно выбрать безопасное значение для этого параметра, хотя 10, вероятно, является безопасной ставкой. Многое из этого будет зависеть от того, насколько динамична маршрутизация вашего интернет-провайдера и насколько динамична маршрутизация к вашим стандартным пунктам назначения. Лучшее эмпирическое правило – определить максимальное количество прыжков, необходимых для достижения любого хоста в вашей среде, а затем установить значение, немного превышающее это число.
обнаружение_состояния_проблем. Параметр detect_state_problems активирует оповещение об аномалиях, обнаруженных при повторной сборке фрагментов. Это сработает при нескольких условиях. Если в пакете есть более одного фрагмента, идентифицирующего себя как первый фрагмент (благодаря нулевому смещению фрагмента и установленному флагу больше фрагментов), это сработает. Он также срабатывает, если фрагменты перекрываются или если фрагмент поступает для пакета, который уже полностью перестроен. Наконец, он сработает, если для не первого фрагмента установлены параметры IP. Параметры IP должны быть установлены только в первом фрагменте. Этот параметр не влияет на то, будет ли frag2 выдавать оповещения о перестроенных пакетах, которые слишком велики, как в случае Ping of Death — это оповещение всегда активно.
Вывод frag2
frag2 восстанавливает пакет из всех полученных им фрагментов, а затем проталкивает восстановленный пакет по обычному пути, по которому проходит пакет, только что покинувший декодер. Пакет регистрируется и/или проходит через препроцессор и механизмы обнаружения. Означает ли это, что фрагментированный трафик анализируется дважды? Да — один раз в состоянии фрагментации, когда он проходит через движок, и еще раз, когда все фрагменты получены.
Некоторые люди склонны думать, что Snort буферизует все фрагментированные пакеты до тех пор, пока они не будут собраны, а затем пропускает их через движок. По существу создание узкого места в IDS. Это заблуждение усугубляется, когда Snort работает в режиме IPS (или встроенном). Это неправда. Пакеты передаются по мере их получения.
Шаттерсток / Funtap
Максимальная единица передачи (MTU) – это максимальное количество байтов, которое может иметь отдельная дейтаграмма без фрагментации на более мелкие дейтаграммы или без потери пути между источником и получателем.
Для кадров Ethernet и многих других типов пакетов это число составляет 1500 байт, и в целом оно соответствует требованиям к трафику, который может без повреждений передаваться через общедоступный Интернет.
Поэтому, если пакеты Ethernet размером 2000 байт поступают на маршрутизатор, он разделяет их полезные данные на две части и переупаковывает их в два пакета, каждый из которых меньше 1500 байт и соответствует MTU.
В качестве альтернативы маршрутизатор отбрасывает пакет, но отправляет исходному устройству сообщение о слишком большом пакете протокола управляющих сообщений Интернета (ICMP). Цель состоит в том, чтобы исходное устройство повторно отправляло полезные данные меньшими пакетами, но оно может быть не настроено для поддержки этого.
Размер MTU также играет роль, когда кадру, чтобы добраться от источника к месту назначения, может потребоваться пересечь сеть, использующую протокол, отличный от того, который используется исходной и целевой сетями. Например, устройство в локальной сети Ethernet может захотеть отправить полезную нагрузку на устройство в локальной сети Ethernet в другом городе и по пути пересечь соединение MPLS.
В этом случае необходимо учитывать размер кадров Ethernet. Если инкапсуляция Ethernet в MPLS увеличивает размер кадра MPLS за пределы MTU граничных коммутаторов MPLS, коммутаторы отбрасывают его.
Размер MTU
Размер MTU определяется физическими свойствами среды связи. Исторически сетевые носители были медленнее и более подвержены ошибкам, поэтому размеры MTU были установлены относительно небольшими. Для большинства сетей Ethernet это 1500 байт, и этот размер почти повсеместно используется в сетях доступа. Сети Ethernet II имеют стандартный размер кадра 1518 байт, который включает 14-байтовый заголовок Ethernet II и четырехбайтовую последовательность проверки кадра (FCS). Другие средства связи имеют другие размеры MTU.
Накладные расходы на инкапсуляцию
Когда пакеты или кадры одного протокола инкапсулируются в другой протокол, общий размер кадра увеличивается. Инкапсуляция добавляет заголовок протокола, поэтому любые пакеты размером 1500 байт, которые затем инкапсулируются, превышают MTU, который может обработать сеть. Количество добавляемых байтов зависит от типа протокола:
- GRE (протокол IP 47) (RFC 2784) добавляет 24 байта (20-байтовый заголовок IPv4, 4-байтовый заголовок GRE)
- Инкапсуляция 6 в 4 (протокол IP 41, RFC 4213) добавляет 20 байт.
- Инкапсуляция 4 в 6 (например, DS-Lite RFC 6333) добавляет 40 байт.
- Каждый раз, когда вы добавляете другой внешний заголовок IPv4, добавляется 20 байтов.
- Шифрование IPsec, выполняемое DMVPN, добавляет 73 байта для служебных данных ESP-AES-256 и ESP-SHA-HMAC (служебные данные зависят от транспортного или туннельного режима, алгоритма шифрования/аутентификации и HMAC), добавляет 4 байта для каждой метки в стек
- Тег IEEE 802.1Q добавляет 4 байта (Q-in-Q добавляет 8 байтов) добавляет 50 байтов добавляет 42 байта добавляет 36 байтов для IPv4 и 56 байтов для инкапсуляции IPv6 добавляет 42 байта добавляет 54 байта
Существует много других ситуаций, когда происходит инкапсуляция протокола, поэтому вы должны быть в курсе, когда это происходит, и предпринимать шаги, чтобы приспособиться к этому. Пакет может исходить как стандартный пакет IPv4 с назначенным MTU 1500 байт, но в зависимости от пункта назначения он может проходить через инкапсуляцию, которая увеличивает его размер по сравнению с MTU.
Обнаружение MTU пути (PMTUD)
Маршрутизаторы могут фрагментировать пакеты, чтобы сократить их до размеров MTU меньшего размера, но это не оптимально. Пакет, входящий на сетевое устройство, может быть меньше, чем MTU, но если он инкапсулируется устройством и новый общий размер пакета превышает MTU исходящего интерфейса, устройство может разбить пакет на два меньших пакета перед пересылкой данных. .
Например, маршрутизатор IPv4 будет фрагментировать и пересылать пакеты, которые превышают MTU, но также отправляет обратно сообщение об ошибке ICMP message-too-big, чтобы сообщить исходному устройству, что ему следует использовать меньший MTU. С другой стороны, маршрутизаторы IPv6 не фрагментируют пакеты большого размера от имени источника; они просто отбрасывают их и возвращают сообщение об ошибке ICMPv6-слишком большой пакет.
Основная проблема с уменьшением размера MTU в сети заключается в том, что некоторые приложения могут плохо работать в этой среде.
Что еще больше усложняет ситуацию, некоторые маршрутизаторы игнорируют сообщения о слишком больших пакетах и продолжают отправлять пакеты, превышающие MTU. Они не следуют стандартному методу, называемому обнаружением MTU пути, который может избежать фрагментации в сети.
Некоторые узлы, которые отправляют 1500-байтовые пакеты в DMVPN и впоследствии получают от маршрутизатора сообщение о слишком большом пакете ICMPv4, могут игнорировать это. Эти узлы не выполняют обнаружение MTU пути (PMTUD), как предписано IETF RFC 1191 или RFC 1981, и поэтому полагаются на маршрутизаторы IPv4 для выполнения этой фрагментации от имени исходного хоста. RFC 2923 также охватывает тему «Проблемы TCP с обнаружением MTU пути». Если приложение не может работать должным образом в этой среде, это может повлиять на конечного пользователя. Кроме того, если где-то в середине пути связи есть брандмауэр, который блокирует сообщения об ошибках ICMP, то это определенно помешает правильной работе PMTUD.
Один из способов проверки и обнаружения уменьшения размера MTU – использование проверки связи с большим размером пакета. Вот несколько примеров того, как это сделать.
C:\Users\ScottHogg> ping -l 1500 192.168.10.1
На хосте Windows вы также можете установить бит Do Not Fragment (DF) равным 1 с помощью параметра -f ping.
C:\Users\ScottHogg> ping 192.168.10.1 -l 1500 –f
В Linux команда будет выглядеть так:
На устройстве Cisco IOS команда будет выглядеть так:
На устройстве Cisco NX-OS команда будет выглядеть так:
На устройстве Cisco IOS XR команда будет выглядеть так:
На устройстве JUNOS команда будет выглядеть так:
Фрагментация
Маршрутизаторы IPv4 фрагментируют от имени исходного узла, отправляющего пакет слишком большого размера. Маршрутизаторы могут фрагментировать пакеты IPv4, если только бит Do-Not-Fragment (DF) не установлен в 1 в заголовке IPv4. Если бит DF установлен на 0 (по умолчанию), маршрутизатор разделяет пакет, который слишком велик для исходящего интерфейса, и отправляет два пакета к месту назначения. Когда адресат получает два фрагмента, стек протоколов адресата должен повторно собрать фрагменты перед обработкой блока данных протокола (PDU). Но есть опасность, когда приложение отправляет свои пакеты с DF, установленным в 1, не обращает внимания на сообщения ICMP «слишком большой пакет» и не выполняет PMTUD.
Все сети IPv6 должны поддерживать размер MTU не менее 1280 байт (RFC 2460). Это связано с тем, что маршрутизаторы IPv6 не фрагментируют пакеты IPv6 от имени источника. Маршрутизаторы IPv6 отбрасывают пакет и отправляют обратно источнику пакет ICMPv6 Type 4 (размер превышен) с указанием правильного размера MTU. Затем источник сам выполняет фрагментацию и кэширует новый уменьшенный размер MTU для этого пункта назначения, чтобы будущие пакеты использовали правильный размер MTU.
Когда маршрутизаторы выполняют фрагментацию от имени источника, это увеличивает нагрузку на ЦП маршрутизатора. Если используется IPsec, то маршрутизаторы на обоих концах туннеля должны будут обрабатывать фрагментацию и повторную сборку пакетов.Если маршрутизаторы выполняют фрагментацию от имени исходного узла, желательно, чтобы фрагментация выполнялась до шифрования, чтобы туннельному маршрутизатору назначения не приходилось повторно собирать фрагменты, а затем выполнять расшифровку.
Следующие две команды глобальной конфигурации Cisco IOS могут управлять этим поведением.
Есть хороший документ от Cisco о коммутаторах 7600 и о том, как решить эти проблемы, озаглавленный «Настройка фрагментации IPSec VPN и MTU».
MTU и MSS
Еще один способ справиться с увеличением размера MTU из-за инкапсуляции и возникающей в результате фрагментации — использовать параметр максимального размера сегмента TCP (MSS). MSS — это наибольшее количество байтов полезной нагрузки, которое может быть отправлено в одном TCP-пакете. Другими словами, MSS — это наибольший объем данных TCP (в байтах), который можно передать по компьютерной сети. Это согласовывается во время трехстороннего рукопожатия TCP в пакете SYN. MSS определен в RFC 879 для IPv4 и в RFC 2460 для IPv6. MSS не включает заголовок TCP (20 байтов) или заголовок IPv4 (20 байтов; заголовок IPv6 составляет 40 байтов).
При использовании IPsec обычно устанавливается размер MTU на туннельных интерфейсах равным 1400 байт, а для параметра TCP-MSS-adjust устанавливается значение 1360 байт. Это можно настроить на устройстве Cisco IOS с помощью этих команд.
Для интерфейсов с поддержкой IPv6 мы можем использовать функции того же типа, но размер заголовка IPv6 составляет 40 байт вместо заголовка IPv4 размером ~20 байт. Мы также должны учитывать 20-байтовый заголовок TCP, который имеет одинаковый размер для IPv4 и IPv6.
Эта опция MSS не работает для приложений UDP: UDP — это протокол без установления соединения, поэтому невозможно согласовать это во время рукопожатия. Для приложений UDP, которые не выполняют PMTUD и устанавливают бит DF в 1, одним из вариантов может быть настройка политики, которая устанавливает бит DF обратно в ноль.
Компенсировать, увеличив размер MTU
Как мы видели, основная проблема с размером MTU возникает, когда происходит инкапсуляция, а ссылки между сайтами поддерживают только MTU размером 1500 байт. Это часто имеет место для каналов между корпоративными маршрутизаторами и вышестоящими маршрутизаторами интернет-провайдера или между маршрутизаторами CE и маршрутизаторами PE.
Было бы очень желательно иметь возможность увеличивать размер MTU по глобальной сети. Если бы размер MTU можно было увеличить на всем пути через глобальную сеть, то дополнительные издержки инкапсуляции можно было бы компенсировать за счет интерфейса WAN маршрутизаторов. Это устранило бы необходимость уменьшать размер MTU на туннельных интерфейсах, настраивать MSS и освобождать маршрутизаторы от фрагментации. Вот где на помощь приходят большие кадры
Кадры большого размера
Jumbo-кадры — это блоки PDU сетевого уровня, размер которых намного превышает типичный MTU Ethernet, равный 1 500 байтам. В некоторых ситуациях можно использовать большие кадры, чтобы обеспечить гораздо большие размеры кадров, если сетевое оборудование поддерживает эту конфигурацию. Большинство современных маршрутизаторов и коммутаторов, а также большинство сетевого оборудования центров обработки данных могут поддерживать кадры большого размера.
Большие кадры также могут увеличить скорость. С большими размерами кадров и, следовательно, большими размерами полезной нагрузки вы можете иметь меньше накладных расходов на протокол и достичь более высокой эффективности протокола. Другими словами, ваша «хорошая производительность» улучшается с увеличением размера кадра. Вы также можете уменьшить пропускную способность сети и циклы ЦП на сетевом оборудовании.
Чтобы настроить размер MTU большого кадра на устройстве Cisco IOS, просто введите команду MTU в конфигурации интерфейса следующим образом:
Команда show interface проверит новый размер MTU интерфейса.
Для оборудования других производителей вам просто нужно найти команду конфигурации в физическом или виртуальном интерфейсе, которая позволяет установить размер MTU больше 1500 байт.
Ключевая концепция, о которой следует помнить, заключается в том, что все сетевые устройства на пути связи должны поддерживать кадры большого размера. Jumbo-кадры необходимо настроить для работы на входном и исходящем интерфейсе каждого устройства на пути сквозной передачи. Кроме того, все устройства в топологии также должны согласовать максимальный размер jumbo-кадра. Если на пути передачи есть устройства с разными размерами кадров, вы можете столкнуться с проблемами фрагментации. Кроме того, если устройство на пути не поддерживает большие кадры и получает их, оно их отбрасывает.
Джумбограммы
Не следует путать Jumbo-кадры с Jumbo-фреймами. При обсуждении протоколов связи кадры — это PDU, используемые на уровне 2 (канальный уровень) модели OSI, пакеты — это PDU, используемые на уровне 3 (сетевой уровень). ). Jumbogram — это более крупный пакет уровня 3, который превышает размер MTU канала. IPv4 способен генерировать полезные данные размером до 65 535 байт, в то время как IPv6 поддерживает 32-битный размер «Jumbo Payload Length» в заголовке параметра «hop-by-hop». Следовательно, IPv6 может поддерживать смехотворные 4,2 ГБ полезной нагрузки.Ясно, что этот пакет нельзя было передать ни по одному обычному сетевому интерфейсу — только представьте себе последствия повторной передачи.
Поддержка больших кадров
Большинство сетевых устройств поддерживают большие кадры размером 9216 байт. Однако это не стандартизировано, как 1500-байтовый MTU Ethernet, поэтому вам нужно уточнить у вашего конкретного производителя максимальный размер кадра, поддерживаемый их устройствами, и как настроить изменения. Даже в линейке сетевых продуктов одного производителя возможности MTU могут сильно различаться, поэтому важно провести тщательное исследование всех ваших устройств в коммуникационных путях и проверить их настройки. Например, некоторые гигабитные адаптеры Intel поддерживают большие кадры, а многие нет.
Рекомендации
Проблемы с уменьшением размера MTU из-за туннелей, шифрования IPsec и протоколов наложения могут снизить производительность сети. Если вы используете технологии инкапсуляции, вам следует рассмотреть возможность увеличения размера MTU, особенно в ядре сети или глобальной сети, чтобы избежать фрагментации и проблем с PMTUD. Узнайте у поставщика услуг, поддерживает ли он кадры большего размера в своей сети и на канале между своим PE и вашим маршрутизатором CE.
Знание о преимуществах кадров большого размера может повысить производительность вашей сети. Однако важно выяснить, поддерживают ли ваши сетевые устройства jumbo-кадры и каким образом, прежде чем включать эту функцию. Некоторые из самых больших преимуществ использования кадров большого размера могут быть реализованы внутри и между центрами обработки данных. Но вы должны помнить о фрагментации, которая может произойти, если эти большие кадры попытаются пройти по каналу с меньшим размером MTU.
Присоединяйтесь к сообществам Network World на Facebook и LinkedIn, чтобы комментировать самые важные темы.
Я устранял серьезную проблему со скоростью WAN. Я исправил это, но на благо других:
С помощью WireShark, ведения журнала и упрощения конфигурации я сузил его до странного поведения шлюза, выполняющего DNAT, на серверах во внутренней сети. Шлюз (блок CentOS) и серверы работают на одном и том же хосте VMware ESXi 5 (и это оказывается важным).
Обычное установление соединения TCP (SYN, SYN ACK, ACK) проходит нормально; шлюз правильно переназначает IP-адрес сервера в обоих направлениях.
Сервер отправляет сегмент TCP размером 1460 байт с ответом 200 и частью файла через шлюз. Размер фрейма на проводе 1514 байт - 1500 в полезной нагрузке. Этот сегмент должен пересекать шлюз, но не проходит.
Сервер отправляет второй 1460-байтовый TCP-сегмент, продолжая файл, через шлюз. Опять же, полезная нагрузка ссылки составляет 1500 байт. Этот сегмент также не проходит через шлюз и никогда не учитывается.
Шлюз отправляет пакет ICMP типа 3 с кодом 4 (пункт назначения недоступен — требуется фрагментация) обратно на сервер, ссылаясь на пакет, отправленный в событии 3. Пакет ICMP указывает, что MTU следующего перехода составляет 1500. Похоже, это быть бессмысленным, так как сеть чиста на 1500 байт, а полезная нагрузка канала в 3 и 4 уже находится в пределах заявленного ограничения в 1500 байт. Сервер по понятным причинам игнорирует этот ответ. (Изначально слишком усердный брандмауэр отключал ICMP, но это было исправлено.)
После значительной задержки (а в некоторых конфигурациях дублирования ACK от сервера) сервер решает повторно отправить сегмент из события 3, только на этот раз. За исключением поля IP-идентификации и контрольной суммы, кадр идентичен кадру в Событии 3. Они имеют одинаковую длину, а новый все еще имеет установленный флаг "Не фрагментировать".< /em> Однако на этот раз шлюз успешно передает сегмент клиенту — целиком — вместо отправки ICMP-отклонения.
Клиент подтверждает это, и передача продолжается, хотя и мучительно медленно, поскольку последующие сегменты проходят примерно по той же схеме: отклонение, истечение времени ожидания, повторная отправка и последующая обработка.
Клиент и сервер работают вместе нормально, если клиент перемещается в локальную сеть, чтобы получить прямой доступ к серверу.
Это странное поведение непредсказуемо зависит от кажущихся несущественными сведений о целевом сервере.
Что еще более странно, проблема исчезла бы, если бы WireShark был установлен на целевом сервере. Таким образом, чтобы диагностировать проблему, мне пришлось установить WireShark на отдельную виртуальную машину, чтобы наблюдать за сетевым трафиком на стороне локальной сети (вероятно, в любом случае это лучшая идея по другим причинам).
Хост ESXi имеет версию 5.0 U2.
Я видел, как некоторые (не помню подробностей, но что-то не в Windows) ОС помечали подсети вне локальных (подключенных) сетей как имеющие минимальный (536?) MTU, даже если ОС была настроена на 1500 MTU.
4 ответа 4
Вы не можете удалить сообщения о необходимости фрагментации ICMP. Они необходимы для обнаружения pMTU, необходимого для правильной работы TCP. Пожалуйста, LART администратору брандмауэра.
Согласно правилу прозрачности, маршрутизатор с фильтрацией пакетов, действующий как брандмауэр, который разрешает исходящие IP-пакеты с установленным битом «Не фрагментировать» (DF), НЕ ДОЛЖЕН блокировать входящие сообщения ICMP об ошибках «Destination Unreachable / Fragmentation Needed», отправляемых в ответ. чтобы исходящие пакеты не достигали хостов внутри брандмауэра, так как это нарушит совместимое со стандартами использование определения Path MTU хостами, генерирующими законный трафик. -- Требования к брандмауэру - RFC2979 (курсив в оригинале)
Эта конфигурация уже более десяти лет считается принципиально неисправной. ICMP не является обязательным.
Я полностью согласен: правильная конфигурация должна разрешать ответы ICMP. Надеюсь, я смогу изменить локальные брандмауэры. Меня, однако, беспокоит то, что — по крайней мере, если то, что я читал, правда — интернет-брандмауэры очень часто игнорируют это требование. Поэтому, даже если мы исправим это локально, это может привести к сбою в работе из-за внешних брандмауэров, которые мы не можем контролировать. В аналогичной установке мне пришлось использовать фиксацию MSS, поэтому я решил сделать это и здесь. Я до сих пор не понимаю, как одни пакеты работали, а другие нет, когда все они передавались по одному и тому же прямому каналу.
@Kevin: Почти невозможно понять, насколько сложные, недействительные механизмы могут потерпеть неудачу. Во много-много раз труднее понять, насколько успешны сложные и действенные договоренности. Возможно, вы сможете определить, исправив брандмауэр, а затем посмотрев, что произойдет по-другому.
Я сожалею только о том, что у меня есть только один голос, чтобы дать этот ответ. Это и желание вернуть часы, которые я провел на собраниях, убеждая нетехнических ИТ-менеджеров снова включить ICMP после того, как они прочитали какую-то древнюю редакционную статью об атаках Ping of Death и заблокировали весь протокол.
Спасибо за хорошее предложение. Я изменил политику брандмауэра. Это не было первопричиной (как я полагал), но она передала дополнительную информацию, которая была полезна для поиска первопричины.
Наконец-то я докопался до сути. Оказалось, что проблема связана с реализацией VMware разгрузки сегментации TCP в виртуальном сетевом адаптере целевого сервера.
Стек TCP/IP сервера будет отправлять один большой блок на сетевую карту, ожидая, что сетевая карта разобьет его на сегменты TCP, ограниченные значением MTU канала. Однако VMware решила оставить это в одном большом сегменте до... ну, я не знаю, когда именно.
Похоже, что на самом деле он остался одним большим сегментом, когда достиг стека TCP/IP виртуальной машины шлюза, что вызвало отклонение.
В полученном ICMP-пакете была скрыта важная подсказка: IP-заголовок отклоненного пакета указывал размер 2960 байт, что намного больше, чем сам пакет, который, по-видимому, был отклонен. Это также точно такой же размер сегмента TCP, который был бы в сети, если бы он объединил данные из обоих сегментов, отправленных до сих пор.
Одна вещь, которая очень усложняла диагностику проблемы, заключалась в том, что передаваемые данные фактически были разделены на кадры по 1500 байт, поскольку WireShark работал на другой виртуальной машине (подключенной к тому же vSwitch на отдельном , неразборчивая группа портов) мог видеть. Я действительно не уверен, почему виртуальная машина шлюза увидела один пакет, а виртуальная машина WireShark — два. FWIW, на шлюзе не включена большая разгрузка при приеме - я бы понял, если бы это было так. Виртуальная машина WireShark работает под управлением Windows 7.
Я думаю, что логика VMware в задержке сегментации заключается в том, что если данные должны выходить через физический сетевой адаптер, можно использовать аппаратную разгрузку сетевого адаптера. Однако кажется ошибочным, что он не сможет сегментировать перед отправкой на другую виртуальную машину и непоследовательно, если на то пошло. Я видел, как это поведение упоминалось в другом месте как ошибка VMware.
Решением было просто отключить разгрузку сегментации TCP на целевом сервере. Процедура зависит от ОС, но между прочим:
В Windows в свойствах подключения на вкладке "Общие" или "Сеть" нажмите "Настроить" рядом с адаптером и посмотрите на вкладку "Дополнительно". Для Server 2003 R2 это указано как «Разгрузка TCP-сегментации IPv4». Для Server 2008 R2 это "Большая разгрузка отправки (IPv4)".
Это решение немного запутанно и может повлиять на производительность в некоторых средах, поэтому я все равно приму любой ответ получше.
Из-за неисправности сетевого оборудования, неправильной настройки или дефектов программного обеспечения вы можете столкнуться с тем, что небольшие передачи данных TCP работают без проблем. Но большие передачи данных, те, что с полноразмерными пакетами, зависают, а затем истекают по тайм-ауту. Обходной путь — настроить передающие узлы для выполнения одного или обоих следующих действий:
Описание проблемы и возможные причины
Иногда по некоторым IP-путям узел TCP/IP может без проблем отправлять небольшие объемы данных (обычно менее 1500 байт), но попытки передачи больших объемов данных зависают, а затем истекает время ожидания.Часто это наблюдается как однонаправленная проблема, когда большие объемы данных передаются успешно в одном направлении, но терпят неудачу в другом направлении. Эта проблема, вероятно, вызвана значением TCP MSS, сбоем PMTUD, различными типами носителей LAN или неисправными ссылками. Эти подразделы описывают проблемы:
Значение TCP MSS
Значение TCP MSS указывает максимальный объем данных TCP в одной дейтаграмме IP, которую локальная система может принять (повторно собрать). Дейтаграмма IP может быть фрагментирована на несколько пакетов при отправке. Теоретически это значение может достигать 65495, но такое большое значение никогда не используется. Как правило, конечная система использует «MTU исходящего интерфейса» минус 40 в качестве сообщаемого MSS. Например, значение MSS Ethernet равно 1460 (1500 - 40 = 1460).
Отказ PMTUD
PMTUD — это алгоритм, описанный в RFC 1191 и реализованный в последних стеках TCP/IP. Этот алгоритм пытается обнаружить самую большую дейтаграмму IP, которую можно отправить без фрагментации по пути IP, и максимизирует пропускную способность передачи данных.
PMTUD реализуется, когда отправитель IP устанавливает флаг "Не фрагментировать" (DF) в заголовке IP. Если IP-пакет с этим установленным флагом достигает маршрутизатора, чья ссылка следующего перехода имеет слишком маленькое значение MTU для отправки пакета без фрагментации, этот маршрутизатор отбрасывает этот пакет и отправляет ошибку ICMP «Фрагментация необходима, но установлен DF» отправителю IP. Когда IP-отправитель получает это сообщение протокола управляющих сообщений Интернета (ICMP), он учится использовать меньший IP MTU для пакетов, отправляемых в этот пункт назначения, и последующие пакеты могут проходить.
Различные проблемы могут привести к сбою алгоритма PMTUD. Отправитель IP никогда не узнает меньший MTU пути, но безуспешно продолжает повторную передачу слишком большого пакета до тех пор, пока не истечет время повторной передачи. Некоторые проблемы включают:
Маршрутизатор на обратном пути между маршрутизатором с малым MTU и отправителем IP отбрасывает сообщение об ошибке ICMP до того, как оно достигнет отправителя IP.
Обходной путь для этих проблем – настроить IP-отправитель на отключение PMTUD. Это приводит к тому, что отправитель IP отправляет свои дейтаграммы со снятым флагом DF. Когда большие пакеты достигают маршрутизатора с малым MTU, этот маршрутизатор фрагментирует пакеты на несколько более мелких. Фрагментированные данные меньшего размера достигают места назначения, где они снова собираются в исходный большой пакет.
Различные типы сетевых носителей
Два хоста в одной и той же маршрутизируемой сети, но с разными типами носителей LAN (Ethernet, Token Ring и оптоволоконный интерфейс распределенных данных (FDDI)) могут вести себя по-разному. Системы, подключенные к Ethernet, могут работать правильно, в то время как системы, подключенные к Token Ring и FDDI, могут дать сбой. Причина этого сбоя заключается в том, что система Ethernet сообщает значение MSS 1460, в то время как подключенные системы Token Ring и FDDI сообщают значение MSS около 4400. Поскольку удаленный сервер не может превысить значение MSS, сообщаемое с другого конца, он может использовать меньший пакеты при обмене данными с системой, подключенной к Ethernet, чем при обмене данными с системой, подключенной к Token Ring и FDDI.
Топология сети "гантели"
Проблемы с PMTUD часто возникают в сетевой топологии типа "гантель" (например, в топологии, в которой MTU внутреннего канала в сетевом пути меньше, чем MTU взаимодействующих интерфейсов хостов). Например, при использовании туннеля IP (общая инкапсуляция маршрутизации (GRE)) MTU туннельного интерфейса меньше, чем MTU соответствующего физического интерфейса. Если PMTUD дает сбой из-за фильтрации ICMP или проблем со стеком хоста, большие пакеты не могут пройти через туннель. Обходной путь в выпусках программного обеспечения Cisco IOS с интегрированным идентификатором ошибки Cisco CSCdk15279 (только для зарегистрированных клиентов) заключается в увеличении MTU IP-туннеля до 1500 байт.
Неверные ссылки
Иногда у маршрутизатора есть канал с большим (1500 байт) значением MTU, но он не может доставить дейтаграмму такого размера по этому каналу. Этот маршрутизатор не возвращает отправителю ICMP-ошибку «Требуется фрагментация, но установлен DF», поскольку на самом деле канал не имеет малого MTU. Однако большие дейтаграммы не могут пройти по ссылке. Поэтому PMTUD не помогает, и все попытки передачи больших пакетов по этому каналу завершаются неудачно.
Иногда это происходит из-за проблем с каналом нижнего уровня, таких как канал Frame Relay со слишком маленьким MTU и недостаточной буферизацией, неисправный блок обслуживания канала/блок обслуживания данных (CSU/DSU) или повторитель, нестандартный кабель, дефект программного или микропрограммного обеспечения.
Еще одна проблема нижнего уровня с каналом вызвана использованием нестандартного моста FDDI-to-Ethernet, который не может выполнять фрагментацию IP-уровня. Потенциальный обходной путь — настроить меньший MTU на интерфейсах маршрутизатора, подключенных к проблемному каналу. Однако это может быть не вариант и не может быть полностью эффективным. Вы можете настроить меньшее значение MTU, например 1500, на конечных IP-узлах, как описано в следующем разделе.
Как отключить PMTUD и настроить меньший MTU/MSS на конечном узле
В этих примерах для Solaris 10 (и предыдущих версий), HP-UX 9.x, 10.x и 11.x, IBM AIX, Linux, Windows 95/ используется IP MTU, равный 1500, или TCP MSS, равный 1460. 98/ME, Windows NT 3.1/3.51, Windows NT 4.0 и Windows 2000/XP. Когда вы устанавливаете значение IP MTU, равное 1500, и значение TCP MSS, равное 1460, это обычно дает тот же эффект, поскольку сегмент TCP обычно занимает 40 байтов заголовка IP/TCP.
Примечание. Если вы измените MTU интерфейса (маршрутизатор или конечный узел), то все системы, подключенные к одному и тому же широковещательному домену (кабель и концентратор), должны иметь одинаковый MTU. Если две системы в одном широковещательном домене не используют одинаковое значение MTU, у них возникнут проблемы при обмене данными, когда пакеты (больше малого MTU, но меньше большого MTU) отправляются из системы с большим MTU в систему с большим MTU. меньше MTU.
Solaris 10 (и более ранние версии)
Источник: TCP/IP в иллюстрациях: The Protocols, Vol. 1, Приложение E, авторы У. Ричард Стивенс и Гэри Р. Райт.
HP-UX 9.x, 10.x и 11.x
HP-UX 10.00, 10.01, 10.10, 10.20 и 10.30 поддерживают обнаружение Path MTU. Он включен (1) по умолчанию для TCP и выключен (0) по умолчанию для UDP. Вкл./выкл. можно переключать с помощью команды nettune.
HP-UX 11 поддерживает обнаружение PMTU и включает его по умолчанию. Это управляется командой ndd setting ip_pmtu_strategy.
Установите стратегию обнаружения Path MTU: 0 отключает обнаружение Path MTU; 1 включает Стратегию 1; 2 включает стратегию 2. Для получения дополнительной информации используйте команду ndd -h в системе HP-UX 11.
Установите новый размер MTU интерфейса, соответствующий NetMgmtID. Значение mtu_size должно находиться в пределах указанного диапазона ссылки, и вы должны иметь права суперпользователя.
Читайте также: