Как проверить потерю пакетов. Функционирование маршрутизаторов

Как проверить потерю пакетов. Функционирование маршрутизаторов

Проблема не определена точно, но она явно с железом. Почему - см. ниже список предпринятых действий.

Система
core i5 3570K
ASUS P8 z77V LX, вздутых конденсаторов нет
GIGABYTE NVIDIA GEFORCE 760, версия драйвера 361.43
Kingston KHX1600C9D3P1K2/8G - 4gb, 4 планки, итого 16
Винт WDC WD10EZEX-60ZF5A0 + SSD ... какой то, не системный, для хлама.
Блок питания Thermaltake TR2 Bronze 650W, около 2 лет
Звуковая карта Sound Blaster Z
Microsoft Windows 7 Максимальная (64 bit)
Версия 6.1.7601 Service Pack 1 Сборка 7601

Примерно 3 или 4 дня назад ни с того ни с чего начались жуткие потери пакетов. Стабильно 5-8%, чаще 20-25, иногда подпрыгивает до 40-50%.
Сопровождается это все жуткими фризами в сетевых играх, остановки на пол-одну секунду, затем все уже где то на других местах, твой же персонаж не сдвинулся или дёрнулся. Причем пинг остается стабильный на уровне до 70ms.
По ping"у получить процент потерь трудновато, так что как "методику" определния использую TeamSpeak 3 с подключение с различным серверам в разных странах. Экспериментально установлено что показания pocket loss"a прям пропорциональны интенсивности фризов в играх и задержками при работе в Skype"e, так что их можно считать достоверными, см пример.
Пример , слева зарубежный сервер, справа российский.

На момент написания поста показывает цифру в 20% на трех разных серверах, т.е потери не зависят от географического положения сервера.
Причину установиться не удаеться до сих пор.

Структура сети примерно следующая - Сервер в универе, Сервер в гостиннице, дальше большая сеть роутеров (по 2 на этаж), дальше я. Ни у кого кроме меня, даже у тех кто сидит на том же роутере, таких проблем не наблюдаеться. Авторизация на сервере гостинницы идет по mac-адресу, по нему же dhcp выдает внутрисетевой ip.

Что делалось:
-1. проверка антивирусом CureIt! на предмет всяких ботнетов и прочего говна. отрицательно.
0. попытки найти приложение которые спамит в сеть, или блокирует её, аля брандмауэр, центр обновления, и т.д.
1. обновление драйвера сетевой карты, не помогло
2. тесты сети (методом teamspeak"a) из безопасного режима, не помогло, значит это не какая то левая софтина (скорее всего)
3. подключение к другому роутеру, с другим кабелем, не помогло
4. изменение mac-адерса сетевой карты у себя (подмена) и на сервере гостинницы, было подозрение что где то стоит комп с таким же mac-ом, и происходит шум и конфликт в сети. не помогло
5. установка новой сетевой карты (подозрения что встроенная Realtek вышла из строя), не помогло
6. полная переустановка windows, сброс BIOS, обновление BIOS до актуальной версии, не помогло
7. подключение к другому роутеру, с другим кабелем, не помогло
8. Система запускалась на совершенной иной конфиругации, винчестер был подключен с другому компу. Потерь нет.

Очень прошу помочь, уже руки опускаются.

IP (internet protocol - межсетевой протокол) - маршрутизируемый сетевой протокол, протокол сетевого уровня семейства («стека») TCP/IP. IPv4 описан в RFC 791 (сентябрь 1981 года).

Основные положения:

    IP - основной протокол стека TCP/IP, он решает вопросы доставки сообщений между узлами составной сети.

    IP является дейтаграммным протоколом: при передаче информации по протоколу IP каждый пакет передается от узла к узлу и обрабатывается в узлах независимо от других пакетов.

    IP относится к протоколам без установки соединений. IP используется для негарантированной доставки данных, разделяемых на так называемые пакеты от одного узла сети к другому. Это означает, что на уровне этого протокола (третий уровень сетевой модели OSI) не даётся гарантий надёжной доставки пакета до адресата. В частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (когда приходят две копии одного пакета; в реальности это бывает крайне редко), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прибыть вовсе. Гарантию безошибочной доставки пакетов дают протоколы более высокого (транспортного уровня) сетевой модели OSI - например, Порты TCP - которые используют IP в качестве транспорта.

    Протокол IP использует принцип маршрутизации. Вид таблицы IP- маршрутизации зависит от конкретной реализации маршрутизатора, но в таблицах всех типов маршрутизаторов есть все ключевые поля, необходимые для выполнения маршрутизации. Существует несколько источников, поставляющих записи в таблицу маршрутизации:

    • Во-первых, при инициализации программное обеспечение стека TCP/IP заносит в таблицу записи о непосредственно подключенных сетях и маршрутизаторах по умолчанию, а также записи об особых адресах типа 127.0.0.0.

      Во-вторых, администратор вручную заносит статические записи о специфичных маршрутах или о маршрутизаторе по умолчанию.

      В-третьих, протоколы маршрутизации автоматически заносят в таблицу динамические записи о имеющихся маршрутах.

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

Структура IP пакета

Пакет протокола IP состоит из заголовка и поля данных. Максимальная длина пакета 65 535 байт. Заголовок обычно имеет длину 20 байт и содержит информацию о сетевых адресах отправителя и получателя, о параметрах фрагментации, о времени жизни пакета, о контрольной сумме и некоторых других. В поле данных IP- пакета находятся сообщения более высокого уровня.

Рассмотрим поля структуру IP- пакета на конкретном примере.

    Поле Длина заголовка (IHL) IP- пакета занимает 4 бит и указывает значение длины заголовка, измеренное в 32-битовых словах. Обычно заголовок IP-пакета имеет длину в 20 байт (пять 32-битовых слов), но при увеличении объема служебной информации эта длина может быть увеличена. Наибольший заголовок занимает 60 октетов.

    Поле Тип сервиса (Type of Service) занимает один байт и задает приоритетность пакета и вид критерия выбора маршрута. Первые три бита этого поля образуют подполе приоритета пакета (Precedence) . Приоритет может иметь значения от самого низкого - 0 (нормальный пакет) до самого высокого - 7 (пакет управляющей информации) . Маршрутизаторы и компьютеры могут принимать во внимание приоритет пакета и обрабатывать более важные пакеты в первую очередь. Поле Type of Service содержит также три бита, определяющие критерий выбора маршрута. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. Во многих сетях улучшение одного из этих параметров связано с ухудшением другого, кроме того, обработка каждого из них требует дополнительных вычислительных затрат. Поэтому редко, когда имеет смысл устанавливать одновременно хотя бы два из этих трех критериев выбора маршрута. Зарезервированные биты имеют нулевое значение. Установленный * бит D (delay) говорит о том, что маршрут должен выбираться для минимизации задержки доставки данного пакета * бит Т - для максимизации пропускной способности * бит R - для максимизации надежности доставки.

    Поле Общая длина (Total Length) занимает 2 байта и означает общую длину пакета с учетом заголовка и поля данных. Максимальная длина пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65 535 байт, однако в большинстве компьютеров и сетей такие большие пакеты не используются. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP- пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной в 1500 байт, умещающиеся в поле данных кадра Ethernet. В стандарте предусматривается, что все хосты должны быть готовы принимать пакеты вплоть до 576 байт длиной (приходят ли они целиком или по фрагментам). Существует такое правило: хостам рекомендуется отправлять пакеты размером более чем 576 байт, только если они уверены, что принимающий хост или промежуточная сеть готовы обслуживать пакеты такого размера.

    Поле Идентификатор пакета (Identification) занимает 2 байта и используется для распознавания пакетов, образовавшихся путем фрагментации исходного пакета. Все фрагменты должны иметь одинаковое значение этого поля.

    Поле Флаги (Flags) занимает 3 бита и содержит признаки, связанные с фрагментацией: установленный бит DF (Do not Fragment) запрещает маршрутизатору фрагментировать данный пакет, а установленный бит MF (More Fragments) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Оставшийся бит зарезервирован.

    Поле Смещение фрагмента (Fragment Offset) занимает 13 бит и задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного пакета, подвергнутого фрагментации. Используется при сборке/разборке фрагментов пакетов при передачах их между сетями с различными величинами MTU . Смещение должно быть кратно 8 байт.

    Поле Время жизни (Time to Live) занимает 1 байт и означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

    Идентификатор Протокол верхнего уровня (Protocol) занимает 1 байт и указывает, какому протоколу верхнего уровня принадлежит информация, размещенная в поле данных пакета (например, это могут быть сегменты протоколов верхних уровней или протоколов маршрутизации). Значения идентификаторов для различных протоколов приводятся в документе RFC 3232 - Assigned Numbers.

    Контрольная сумма (Header Checksum) занимает 2 байта и рассчитывается только по заголовку. Поскольку некоторые поля заголовка меняют свое значение в процессе передачи пакета по сети (например, время жизни), контрольная сумма проверяется и повторно рассчитывается при каждой обработке IP- заголовка. Контрольная сумма - 16 бит - подсчитывается как дополнение к сумме всех 16-битовых слов заголовка. При вычислении контрольной суммы значение самого поля "контрольная сумма" устанавливается в нуль. Если контрольная сумма неверна, то пакет будет отброшен, как только ошибка будет обнаружена.

    Поля IP-адрес источника (Source IP Address) и

    IP-адрес назначения (Destination IP Address) имеют одинаковую длину - 32 бита - и одинаковую структуру.

    Поле Опции (IP Options) является необязательным и используется обычно только при отладке сети. Механизм опций предоставляет функции управления, которые необходимы или просто полезны при определенных ситуациях, однако он не нужен при обычных коммуникациях. Это поле состоит из нескольких подполей, каждое из которых может быть одного из восьми предопределенных типов. В этих подполях можно указывать точный маршрут прохождения маршрутизаторов, регистрировать проходимые пакетом маршрутизаторы, помещать данные системы безопасности, а также временные отметки. Так как число подполей может быть произвольным, то в конце поля Опции должно быть добавлено несколько байт для выравнивания заголовка пакета по 32-битной границе.

    Поле Выравнивание (Padding) используется для того, чтобы убедиться в том, что IP- заголовок заканчивается на 32-битной границе. Выравнивание осуществляется нулями.

IP фрагментация, MTU, MSS, и PMTUD

Фрагментация IP пакетов: MTU , MSS , и PMTUD . PMTUD (Path MTU Discovery) и проблема фрагментации пакетов (network mtu ping packet)

Почему же работают пинг при проблемах с MTU? Пакеты ICMP Request и Relpy имеют размер от 32 до 64 байтов, пингуемый сервер возвращает очень мало информации, которая вполне укладывается в допустимый размер вместе со всеми заголовками.

Протокол Порты TCP позволяет согласовать значение максимального размера сегмента (MSS) обоим участникам соединения. Каждая сторона указывает предлагаемый размер MSS в поле ОПЦИИ заголовка пакета TCP. Будет принято наименьшее из двух значений. Такое согласование позволяет избежать фрагментации пакетов при прохождении через маршрутизаторы и шлюзы, и их последующей сборки на целевом хосте, что приводит к задержкам и снижению скорости передачи.

Фрагментация подразумевает разбиение блока данных (пакета) на равные части. Соответственно после фрагментации следующим этапом следует сборка фрагментов. Протокол IP позволяет выполнять фрагментацию только тех пакетов, которые поступают на входные порты маршрутизаторов. Следует различать фрагментацию сообщений в узле-отправителе, и динамическую фрагментацию сообщений в маршрутизаторах. Дело в том, что практически во всех стеках протоколов есть протоколы, которые осуществляют фрагментацию сообщений прикладного уровня на такие части, которые укладываются в кадры канального уровня. В стеке TCP/IP, например, эту задачу решает протокол транспортного уровня TCP. Этот протокол может разбивать поток байтов, передаваемый ему с прикладного уровня на сообщения нужного размера (например, на 1460 байт для протокола Ethernet).

Поэтому протокол IP в узле-отправителе не использует свои возможности по фрагментации пакетов.

А вот при необходимости передать пакет в следующую сеть, для которой размер пакета является слишком большим, IP-фрагментация становится необходимой.

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

В большинстве типов локальных и глобальных сетей значения MTU, то есть максимальный размер поля данных, в которое должен инкапсулировать свой пакет протокол IP, значительно отличается.

Сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI - 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.

Итак, необходимость фрагментации пакетов на уровне IP мы пояснили. Теперь перейдем к самому процессу фрагментации пакетов IP.

Как мы уже выяснили из предыдущего раздела нашего урока, в поле Flags заголовка IP-пакет может быть помечен как не фрагментируемый. Любой пакет, помеченный таким образом, не может быть фрагментирован модулем IP ни при каких условиях.

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

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

Например, технология АТМ делит поступающие IP-пакеты на ячейки с полем данных в 48 байт с помощью своего уровня сегментирования, а затем собирает ячейки в исходные пакеты на выходе из сети. Но такие технологии, как АТМ, являются скорее исключением, чем правилом.

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

Для того, чтобы не перепутать фрагмент различных типов, в заголовке IP-пакетов используется поле Identification.

Модуль протокола IP, отправляющий пакет, устанавливает в поле Identification значение, которое должно быть уникальным для данной пары отправитель - получатель. Кроме этого отправитель в заголовке пакета устанавливает время, в течение которого пакет может быть активным в сети.

Поле смещения фрагмента (Fragment Offset) сообщает получателю положение фрагмента в исходном пакете. Смещение фрагмента и длина определяют часть исходного пакета, принесенную этим фрагментом. Флаг "more fragments" показывает появление последнего фрагмента. Модуль протокола IP, отправляющий неразбитый на фрагменты пакет, устанавливает в нуль флаг "more fragments" и смещение во фрагменте.

Все эти поля дают достаточное количество информации для сборки пакета.

Итак, чтобы разделить на фрагменты большой пакет, модуль протокола IP, установленный, например, на маршрутизаторе, создает несколько новых пакетов и копирует содержимое полей IP-заголовка из большого пакета в IP-заголовки всех новых пакетов. Данные из старого пакета делятся на соответствующее число частей, размер каждой из которых, кроме самой последней, обязательно должен быть кратным 8 байт.

Размер последней части данных равен полученному остатку.

Каждая из полученных частей данных помещается в новый пакет.

Когда происходит фрагментация, то некоторые параметры IP-заголовка копируются в заголовки всех фрагментов, а другие остаются лишь в заголовке первого фрагмента.

Процесс фрагментации может изменить значения данных, расположенных в поле параметров, и значение контрольной суммы заголовка, изменить значение флага "more fragments" и смещение фрагмента, изменить длину IP-заголовка и общую длину пакета.

В заголовок каждого пакета заносятся соответствующие значения в поле смещения "fragment offset", а в поле общей длины пакета помещается длина каждого пакета.

Таким образом, первый фрагмент будет иметь в поле "fragment offset" нулевое значение. Во всех пакетах, кроме последнего, флаг "more fragments" устанавливается в единицу, а в последнем фрагменте - в нуль.

Теперь давайте рассмотрим процесс сборки фрагментов пакетов.

Чтобы собрать фрагменты пакета, модуль протокола IP объединяет IP-пакеты, имеющие одинаковые значения в полях идентификатора, отправителя, получателя и протокола.

Таким образом, отправитель должен выбрать идентификатор таким образом, чтобы он был уникален для данной пары отправитель-получатель, для данного протокола и в течение того времени, пока данный пакет (или любой его фрагмент) может существовать в составной IP-сети.

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

Однако, поскольку поле идентификатора допускает 65 536 различных значений, некоторые хосты могут использовать просто уникальные идентификаторы, не зависящие от адреса получателя.

В некоторых случаях целесообразно, чтобы идентификаторы IP-пакетов выбирались протоколами более высокого, чем IP, уровня.

Процедура объединения заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке пакета в поле "fragment offset".

Каждый модуль IP должен быть способен передать пакет из 68 байт без дальнейшей фрагментации. Это связано с тем, что IP-заголовок может включать до 60 байт, а минимальный фрагмент данных - 8 байт. Каждый получатель должен быть в состоянии принять пакет из 576 байт в качестве единого куска либо в виде фрагментов, подлежащих сборке. Если бит флага запрета фрагментации (Don"t Fragment, DF) установлен, то фрагментация данного пакета запрещена, даже если в этом случае он будет потерян.

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

Итак, после длительных объяснений давайте закрепим на примере все, что мы сейчас узнали о фрагментации IP-пакетов.

Рассмотрим процесс фрагментации IP-пакетов при передаче между сетями с разным размером пакетов на примере, который показан на этом рисунке.

Канальный и физический уровни обозначены, как К1, Ф1, К2, Ф2 соответственно.

Пусть компьютер 1 связан с сетью, имеющей значение MTU в 4096 байт, например с сетью FDDI.

При поступлении на IP-уровень компьютера 1 сообщения от транспортного уровня размером в 5600 байт протокол IP делит его на два IP-пакета. В первом пакете устанавливает признак фрагментации и присваивает пакету уникальный идентификатор, например 486.

В первом пакете величина поля смещения равна 0, а во втором - 2800.

Признак фрагментации во втором пакете равен нулю, что показывает, что это последний фрагмент пакета.

Общая величина IP-пакета составляет 2800 плюс 20 (размер IP-заголовка), то есть 2820 байт, что умещается в поле данных кадра FDDI.

Сетевой интерфейс отправляет кадры следующему маршрутизатору.

После того, как кадры пройдут уровень сетевого интерфейса маршрутизатора (К1 и Ф1) и освободятся от заголовков FDDI, модуль IP по сетевому адресу определяет, что прибывшие два пакета нужно передать в сеть 2, которая является сетью Ethernet и имеет значение MTU, равное 1500.

Следовательно, прибывшие IP-пакеты необходимо фрагментировать.

Маршрутизатор извлекает поле данных из каждого пакета и делит его еще пополам, чтобы каждая часть уместилась в поле данных кадра Ethernet.

Затем он формирует новые IP-пакеты, каждый из которых имеет длину 1400 + 20 = 1420 байт, что меньше 1500 байт, поэтому они нормально помещаются в поле данных кадров Ethernet.

В результате в компьютер 2 по сети Ethernet приходят четыре IP-пакета с общим идентификатором 486.

Протокол IP, работающий в компьютере 2, должен правильно собрать исходное сообщение.

Если пакеты пришли не в том порядке, в котором были посланы, то смещение укажет правильный порядок их объединения.

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

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

Таймер устанавливается на максимальное из двух значений: первоначальное установочное время ожидания и время жизни, указанное в принятом фрагменте.

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

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

В сетях с предварительным соединением отправителя и получателя (connection- oriented ) отправитель и получатель перед обменом данными предварительно устанавливают соединение. Кроме того, при использовании таких технологий проводится подтверждение принятых данных. Примером сетей с предварительным соединением являются телефонные сети с коммутацией каналов, а также сети с виртуальными каналами (см. лекцию 1).

Правила телекоммуникаций узлов между собой при обмене данными через сети устанавливают протоколы. Протоколы описывают формат сообщения, путь ( маршрут ) обмена сообщениями и другие правила. Чтобы продвигать пакет от одного узла до другого, протоколы сетевого уровня используют информацию, заключающуюся в адресе заголовка сетевого уровня (например, IP - адрес ). Такие протоколы получили название сетевых (routed). Таким образом, сетевые протоколы определяют формат пакета, логические адреса узла источника и назначения, прокладывают маршрут пакета на основе имеющихся таблиц маршрутизации .

Для обеспечения телекоммуникаций помимо сетевых (routed) протоколов применяются маршрутизирующие ( routing ), которые также являются протоколами сетевого уровня. Они создают и поддерживают таблицы маршрутизации. Обновления ( update ) таблиц протоколами маршрутизации реализуются путем связи и обмена данными между маршрутизаторами. Следовательно, протоколы маршрутизации создают и поддерживают таблицы маршрутизации , а сетевые протоколы используют эти таблицы для продвижения пакетов.

Протоколы сетевого уровня, к которым относится и IP , должны обеспечивать номера ( адреса) сетей и номера (адреса) хостов. Некоторым протоколам, например Novell Internetwork Packet Exchange (IPX ), требуется только сетевой адрес , поскольку они используют MAC-адрес устройства в качестве адреса хоста. Протоколу IP требуется адрес , содержащий как сетевую, так и узловую (хостовую) части. Для того чтобы можно было выделить адрес сети и адрес хоста, необходима маска сети или подсети (см. лекцию 7). Протоколы IP, IPX/SPX и AppleTalk обеспечивают поддержку Уровня 3 модели OSI .

Основным сетевым (routed) протоколом всемирной сети Интернет является Internet Protocol (IP ). Формат сообщения сетевого уровня представляет собой пакет , известный также как дейтаграмма ( datagram ). Это означает, что в процессе организации связи не используются схемы коммутации цепей, поскольку все соединения выполнены заранее и нужно лишь выбрать наилучший путь к адресату назначения на основе метрики протокола маршрутизации. Термины ненадежный ( unreliable ) и доставка по возможности , доставка с наибольшими возможными усилиями (besteffort delivery ) означают, что проверка ( верификация ) правильности полученных данных на сетевом уровне не производится. Для такой проверки при необходимости используется протокол транспортного уровня TCP .

Формат пакета сетевого протокола IP ( рис. 8.5) включает заголовок, состоящий из 12 полей общей длиной в 160 бит (5 слов по 4 байта, т. е. 20 байт ), поле опций переменной длины и поле данных.


Рис. 8.5.

  1. Первое 4-разрядное поле ( Vers ) задает номер версии протокола. В настоящее время действует версия 4 – IPv4 , согласно которой длина адреса источника (Source IP address ) и адреса назначения ( Destination IP address ) равна 32 разрядам (4 байтам). В распечатках поля заголовка обычно представляются в десятичной и шестнадцатеричной системах. Например, действующая в настоящее время версия 4 выглядит следующим образом: Version = 4 (0x4). В поле заголовка номер версии будет задан в двоичной системе – 0100.
  2. Длина заголовка – количество 32-разрядных слов в заголовке – задается вторым полем HLEN. Например, код в этом поле – 0101, и запись Header Length = 20 (0x14) означает, что заголовок содержит 5 слов по 32 разряда или 20 байт.
  3. Поле типа сервиса (Type of Service – ToS ) длиной 8 бит включает четыре идентификатора: трехразрядный идентификатор PR и одноразрядные D, T и R. Идентификаторы определяют требования к метрике при прокладке маршрута. Идентификатор PR определяет тип пакета (нормальный, управляющий и др.) и в соответствие с этим задает приоритет. Установка 1 в разряде D означает требование минимизации задержки при передаче пакета; единица в разряде Т означает требование максимальной пропускной способности; установка 1 в разряде R требует максимальной надежности.
  4. Поле Total Length задает общую длину пакета, включая заголовок и поле данных. 16 разрядов поля позволяют задавать максимальную длину 64 Кбайт. Поскольку максимальная длина кадра в большинстве технологий локальных сетей меньше 64 Кбайт (например, в Ethernet она составляет 1500 байт), большие пакеты разбивают на фрагменты. При фрагментации пакета используется информация 5-го, 6-го и 7-го полей, все фрагменты должны иметь: одинаковый идентификационный номер пакета; номер, определяющий порядок следования фрагмента при сборке пакета; дополнительную информацию.
  5. Пятое поле заголовка содержит идентификационный номер пакета . При фрагментации пакета идентификационный номер будет единым для всех фрагментов.
  6. Трехразрядное поле Flags содержит два одноразрядных флага фрагментации. Установка 1 в разряде DF запрещает маршрутизатору производить фрагментацию данного пакета. Единичка в разряде MF указывает, что данный пакет не является последним.
  7. 13-разрядное поле смещения данных Fragment Offset помогает собрать фрагменты в единый пакет. Оно задает смещение в байтах поля данных этого пакета от начала общего поля данных исходного нефрагментированного пакета.
  8. Из заданного значения Time to Live – время жизни (255 – максимум) при прохождении каждого маршрутизатора или каждую секунду вычитается 1. Таким образом, число узлов, через которые может пройти пакет, ограничено.
  9. Поле Protocol указывает протокол верхнего уровня (TCP, UDP , OSPF и др.), которому будет передан принятый пакет после завершения IP-процесса.
  10. Поле контрольной суммы заголовка Header Checksum . Поскольку при прохождении маршрутизатора значения некоторых полей заголовка изменяются (например, время жизни), расчет контрольной суммы производится в каждом маршрутизаторе заново.
  11. Source IP address – адрес источника информации, длина – 4 байта (32 разряда).
  12. Destination IP address – адрес приемника информации, длина – 4 байта (32 разряда).
  13. Поле IP option позволяет поддерживать различные опции, например, опцию защиты информации. Поскольку это поле может иметь разную длину, оно дополняется нулями до 32 разрядов.
  14. Поле данных Data имеет длину более 64 разрядов.

Краткие итоги

  1. Основным протоколом автоматического назначения IP-адресов устройств является протокол динамического конфигурирования узлов DHCP .
  2. При передаче данных через составную сеть IP-адреса узла назначения и узла источника остаются неизменными.
  3. При передаче данных через составную сеть МАС-адреса назначения и источника меняются при прохождении каждого маршрутизатора.
  4. При формировании кадра вычисляется контрольная сумма , которая записывается в поле FCS -трейлера кадра. При приеме кадра на каждом входном интерфейсе вновь вычисляется контрольная сумма , которая сравнивается с принятой.
  5. Правильность принятых данных проверяется с использованием циклического кода CRC .
  6. При передаче данных через соединения "точка-точка" заголовок кадра может быть существенно упрощен.
  7. Сетью с доставкой данных без предварительного соединения отправителя и получателя сообщения является Internet, где передаются пакеты ( дейтаграммы ) с использованием протокола IP .
  8. Правила телекоммуникаций узлов между собой при обмене данными через сети устанавливают протоколы. Протоколы описывают формат сообщения, путь (маршрут) обмена сообщениями и другие правила.
  9. Основным сетевым протоколом всемирной сети Интернет является Internet Protocol (IP).
  10. Сетевые (routed) протоколы определяют

Applies To: Forefront Client Security

You can configure the following parameters of flood protection:

    Indicates whether Client Security automatically approves computers that are on the Pending Computers list. When this parameter is set to true, Client Security checks the Pending Computers list once an hour and approves the computers on the list; however, when a "Flooding Detected" alert is triggered, Client Security changes the value of this parameter to false to prevent a flooding computer from being automatically approved. The default setting is true, which automatically approves pending computers.

    When you have resolved a "Flooding Detected" alert parameter, you must manually reset this parameter to true if you want Client Security to resume automatically approving pending computers.

    Disconnect clients -Indicates whether a client exceeding the maximum number of events should be moved into the Pending Computers list, which disconnects the client from the MOM server. The default setting is to disconnect flooding computers.

    Controls the maximum number of parameters that an event message can contain before triggering the flood protection alert. This protects the MOM server from event messages maliciously designed to be too large. The default value for this parameter is 40 parameters per event.

    Controls the number of event messages from a single client (within the past four days) that will trigger the flood protection alert. The default value for this parameter is 5,000 events per computer.

It is recommended that you use the default parameters for disconnecting clients, maximum parameters per event, and maximum events per computer; however, consider changing the default parameters when:

    Computers generate more events than allowed by the maximum events per computer parameter. This is unlikely but can occur in some organizations.

    You do not want the console to disconnect computers automatically. Disabling the disconnection of clients that exceed the maximum permitted number of events does not stop DoS attacks. Instead, Client Security will only generate alerts about the possible attack, which may jeopardize the server.

Using the MOM Administrator console, you can configure the parameters for flood detection.

To change "Flooding Detected" alert parameters

    On the collection server, open the MOM Administrator console and expand the Microsoft Operations Manager tree, click Management Packs , click Rule Groups , click Microsoft Forefront Client Security , click Server Behaviors , and then click Event Rules .

    Double-click Run Flood Protection .

    In the Event Rules Properties dialog box, click the Responses tab.

    Select the flood protection script and click Edit .

    In the Launch a Script dialog box, under Script parameters , select the parameter you want to change and click Edit Parameter .

    In the Edit Script Parameter dialog box, enter the new parameter value in the Value box. Valid values depend on which parameter you chose to edit. For details, see the following list:

    • Auto-approve pending computers -To enable automatic approval of pending computers, type true . To disable automatic approval of pending computers, type false . The default value is true.

      Disconnect clients -To enable disconnection of flooding computers, type 1 . To disable disconnection of flooding computers, type 0 . The default value is 1.

      Maximum allowed parameters per event -Type a whole number. The default value is 40.

      Maximum events per computer in OPDB -Type a whole number. The default value is 5,000.

    Click OK three times, and then right-click the Management Packs node and click Commit Configuration Change . MOM implements the changes you made.

Раскрывающийся список, в котором вы можете выбрать действие Kaspersky Internet Security при обнаружении сетевой активности, для которой создается пакетное правило. Список содержит следующие значения:

  • Разрешить . Kaspersky Internet Security разрешает сетевое соединение.
  • Запретить . Kaspersky Internet Security запрещает сетевое соединение.
  • По правилам программ . Kaspersky Internet Security не обрабатывает поток данных в соответствии с пакетным правилом, а применяет правило для программ.

Название сетевого правила. В качестве названия вы можете использовать имя сетевого сервиса.

Сетевой сервис – это набор параметров, характеризующих сетевую активность, для которой вы создаете правило.

В раскрывающемся списке вы можете выбрать направление сетевой активности, которое требуется контролировать. Список содержит следующие направления сетевой активности:

  • Входящее . Kaspersky Internet Security применяет правило к сетевому соединению, которое открыл удаленный компьютер.
  • Исходящее . Kaspersky Internet Security применяет правило к сетевому соединению, которое открыл ваш компьютер.
  • Входящее/Исходящее . Kaspersky Internet Security применяет правило как к входящему, так и к исходящему пакету или потоку данных, независимо от того, какой компьютер (ваш или удаленный) инициировал сетевое соединение.
  • Входящее (пакет) . Kaspersky Internet Security применяет правило к пакетам данных, которые принимает ваш компьютер. Не применяется в правилах для программ.
  • Исходящее (пакет) . Kaspersky Internet Security применяет правило к пакетам данных, которые передает ваш компьютер. Не применяется в правилах для программ.

В списке вы можете выбрать тип протокола, который контролирует Kaspersky Internet Security (доступны протоколы TCP, UDP, ICMP, ICMPv6, IGMP, GRE).

В блоке Параметры ICMP можно настроить тип и код проверяемых пакетов данных.

Тип проверяемых ICMP-пакетов вы можете выбрать в раскрывающемся списке слева.

Код проверяемых ICMP-пакетов вы можете выбрать в раскрывающемся списке справа.

Блок параметров доступен, если выбраны протоколы ICMP, ICMPv6.

Номера удаленных портов, перечисленные через запятую.

Номера контролируемых локальных портов, перечисленные через запятую.

Позволяет задать диапазон адресов, к которому Kaspersky Internet Security применяет правило. Возможные значения:

  • Любой адрес . Kaspersky Internet Security применяет правило к любому IP-адресу.
  • Адреса подсети . Kaspersky Internet Security применяет правило к IP-адресам всех сетей, подключенных в данный момент и имеющих указанный статус. Для этого параметра ниже доступен выбор статуса сети, для которого Kaspersky Internet Security применяет правило (доверенные сети, локальные сети, публичные сети).
  • Адреса из списка . Kaspersky Internet Security применяет правило к IP-адресам, входящим в заданный диапазон. Для этого параметра доступны поля Удаленные адреса и Локальные адреса (список Локальные адреса недоступен при создании сетевого правила).

Статус сетевого правила, который обозначает, используется ли это сетевое правило Сетевым экраном.

Принимает одно из следующих значений:

  • Активно . Сетевой экран использует сетевое правило для обработки пакетов данных.
  • Неактивно . Сетевой экран не использует сетевое правило.

Флажок включает / выключает запись подключений, которые производятся с использованием выбранного протокола.

Если флажок установлен, Kaspersky Internet Security сохраняет информацию о событиях в отчете.



© 2024 beasthackerz.ru - Браузеры. Аудио. Жесткий диск. Программы. Локальная сеть. Windows