Drop пакеты что это

Как отбрасывать 10 миллионов пакетов в секунду

В компании нашу команду по противостоянию DDoS-атакам называют «отбрасыватели пакетов» (the packet droppers — прим. пер). Пока все остальные команды делают клёвые штуки с проходящим через нашу сеть трафиком, мы развлекаемся поиском новых способом избавиться от него.

Фотография: Brian Evans, CC BY-SA 2.0

Умение быстро отбрасывать пакеты очень важно в противостоянии DDoS-атакам.

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

Примечание переводчика: в выводе некоторых представленных команд были удалены лишние пробелы для сохранения читаемости.

Тестовая площадка

Для удобства сравнения способов мы предоставим вам немного цифр, однако, не стоит воспринимать их слишком буквально, ввиду искусственности тестов. Мы воспользуемся одним из наших Intel-серверов с 10Гбит/с сетевой картой. Остальные характеристики сервера не так важны, потому что мы хотим акцентировать внимание на ограничениях операционной системы, а не железа.

Наши тесты будут выглядеть следующим следующим образом:

На выбранном сервере все пакеты будут становиться в одну RX-очередь и, следовательно, обрабатываться одним ядром. Мы добиваемся этого с помощью аппаратного управления потоком:

Тестирование производительности — сложный процесс. Когда мы готовили тесты, мы заметили, что наличие активных raw-сокетов негативно влияет на производительность, поэтому перед запуском тестов необходимо удостовериться, что ни один tcpdump не запущен. Есть простой способ проверить наличие плохих процессов:

Ну и наконец мы отключаем Intel Turbo Boost на нашем сервере:

Несмотря на то, что Turbo Boost — прекрасная штука и увеличивает пропускную способность по крайней мере на 20%, он значительно портит стандартное отклонение в наших тестах. Со включенным turbo отклонение достигают ±1.5%, в то время как без него всего 0.25%.

Шаг 1. Отбрасывание пакетов в приложении

Начнём с идеи доставлять все пакеты в приложение и игнорировать их там. Для честности эксперимента убедимся, что iptables никак не влияют на производительность:

Приложение — простой цикл, в котором пришедшие данные тут же выбрасываются:

Мы уже подготовили код, запускаем:

Такое решение позволяет ядру забирать всего 175 тысяч пакетов из очереди аппаратного обеспечения, как и было измерено утилитами ethtool и нашей mmwatch :

Технически, на сервер приходит 14 миллионов пакетов в секунду, однако, одно ядро процессора не справляется с таким объёмом. mpstat подтверждает это:

Как мы можем видеть, приложение не является узким местом: CPU#1 используется на 27.17% + 2.17%, в то время как обработка прерываний занимает 100% на CPU#2.

Использование recvmessagge(2) играет важную роль. После обнаружения уязвимости Spectre системные вызовы стали ещё более дорогими из-за используемых в ядре KPTI и retpoline

Шаг 2. Убийство conntrack

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

Более того, в dmesg так же можно увидеть крики conntrack:

Так давайте отключим его:

И перезапустим тесты:

Это позволило дойти нам до отметки в 333 тысячи пакетов в секунду. Ура!
P.S. С использованием SO_BUSY_POLL мы можем достичь целых 470 тысяч в секунду, однако, это тема для отдельного поста.

Шаг 3. Пакетный фильтр Беркли

Идём дальше. Зачем нам доставлять пакеты в приложение? Хотя это не является распространённым решением, мы можем привязать классический пакетный фильтр Беркли к сокету вызовом setsockopt(SO_ATTACH_FILTER) и настроить фильтр отбрасывать пакеты ещё в ядре.
Подготовим код, запускаем:

С использованием пакетного фильтра (классический и расширенный фильтры Беркли дают примерно схожую производительность) мы добираемся до примерно 512 тысяч пакетов в секунду. Более того, отбрасывание пакета во время прерывания освобождает процессор от необходимости будить приложение.

Шаг 4. iptables DROP после маршрутизации

Теперь мы можем отбрасывать пакеты, добавив в iptables в цепочку INPUT такое правило:

Посмотрим на числа в iptables:

Ну что ж, неплохо, но мы можем лучше.

Шаг 5. iptabes DROP в PREROUTING

Более быстрая техника — отбрасывать пакеты ещё до маршрутизации с помощью такого правила:

Это позволяет нам отбрасывать солидные 1.688 миллиона пакетов в секунду.

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

В любом случае, «сырые» iptables работают значительно быстрее.

Шаг 6. nftables DROP

Сейчас утилита iptables уже немного старая. Ей на смену пришла nftables. Ознакомьтесь с этим видео-объяснением, почему nftables — топ. Nftables обещается быть быстрее, чем поседевшая iptables по множеству причин, среди которых слух, что retpoline’ы сильно замедляют iptables.

Но наша статья всё же не о сравнении iptables и nftables, так что давайте просто попробуем самое быстрое, что я смог сделать:

Счётчики можно увидеть так:

Входной хук nftables показал значения около 1.53 миллиона пакетов. Это немногим меньше, чем PREROUTING цепочка в iptables. Но в этом есть и загадка: теоретически, хук nftables идёт раньше, чем PREROUTING iptables и, следовательно, должен обрабатываться быстрее.

В нашем тесте nftables чуть-чуть медленнее чем iptables, но всё равно nftables круче. 😛

Шаг 7. tc DROP

Несколько неожиданно, что tc (traffic control) хук происходит раньше, чем iptables PREROUTING. tc позволяет нам отбирать пакеты по простым критериям и, конечно же, отбрасывать их. Синтаксис немного необычный, поэтому для настройки предлагаем использовать этот скрипт. А нам нужно достаточно сложное правило, которое выглядит так:

И мы можем проверить его в действии:

Хук tc позволил нам отбрасывать до 1.8 миллионов пакетов в секунду на одном ядре. Это прекрасно!
Но мы можем ещё быстрее…

Шаг 8. XDP_DROP

Обычно XDP-проект состоит из двух частей:

Исходный код загружаемой eBPF-программы доступен здесь. Программа смотрит на такие характеристики IP-пакетов, как UDP-протокол, подсеть отправителя и порт назначения:

XDP-программа должна быть собрана с помощью современного clang, который умеет генерировать BPF-байткод. После этого мы можем загрузить и проверить работоспособность BFP-программы:

А после посмотреть статистику в ethtool :

Ю-ху! С помощью XDP мы можем отбрасывать до 10 миллионов пакетов за секунду!

Фотография: Andrew Filer, CC BY-SA 2.0

Выводы

Мы повторили эксперимент для IPv4 и для IPv6 и подготовили эту диаграмму:

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

В Linux есть множество способов фильтровать пакеты, каждый со своими быстродействием и сложностью настройки.

Для защиты от DDoS вполне разумно отдавать пакеты в приложение и обрабатывать их там. Хорошо настроенное приложение может показывать хорошие результаты.

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

В остальных случаях есть смысл добавить firewall Linux’а как один из способов смягчения DDoS-атаки. В некоторых случаях лучше пользоваться таблицей «-t raw PREROUTING», так как она значительно быстрее, чем таблица filter.

Для наиболее запущенных случаев мы всегда используем XDP. И да, это очень мощная штука. Вот вам график как выше, только с XDP:

Если вы хотите повторить эксперимент, то вот вам README, в котором мы всё задокументровали.

Мы в CloudFlare используем… почти все из этих техник. Некоторые трюки в пространстве пользователя интегрированы в наши приложения. Техника с iptables встречается в нашем Gatebot. Ну и наконец мы заменяем наш собственное решение в ядре на XDP.

Большое спасибо Jesper Dangaard Brouer за помощь в работе.

Источник

Типы ошибок (dlink)

Posted on 30 июля, 2014

RX (recive) — принимать пакеты приходящие от клиента
TX (transmit) передавать — пакеты приходящие к клиенту

Типы ошибок:

CRC Error — ошибки проверки контрольной суммы

Undersize — возникают при получение фрейма размером 61-64 байта.

Фрейм передается дальше, на работу не влияет

Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой

Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме

Drop Pkts — пакеты отброшенные в одном из трех случаев:

Какие пакеты входят в Drop Packets при выводе show error ports?

Переполнение входного буфера на порту

Пакеты, отброшенные ACL

Проверка по VLAN на входе

Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.

Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.

Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред

Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета

Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается

Single Collision — единичная коллизия

Источник

PacketTrain.NET

Анализ сетевого трафика

Руководство по захвату сетевого трафика. Часть 2 – Скорость, дуплекс и дропы (Перевод)

В первой части серии мы прошлись взглядом по типичным схемам сетей Ethernet и различным ситуациям при захвате трафика. Поэтому в текущей статье (и во всех последующих!) я буду считать, что вы ознакомились с предыдущими частями. Сегодня давайте обсудим, в каком случае скорость интерфейса и режим дуплекса становятся очень важны, и что такое эти «дропы».

Скорость и дуплекс

Есть 2 режима дуплекса, которые можно встретить при работе с сетью Ethernet:

Ну так и что же случится, если одна сторона работает в режиме FDX, а вторая всего лишь в HDX? Ничего хорошего. Узел, который использует FDX, будет думать, что он спокойно может передавать данные когда только пожелает, не понимая, что это вызовет коллизию, если вдруг случится так, что HDX-сосед как раз в этот момент отправляет что-то свое. Называется такая ситуация «duplex mismatch». Что в результате? Скорость передачи упадет до совсем печального уровня (уточним: это считанные килобайты в секунду вместо мегабайтов в секунду на линке в 100 Мбит/с).

Интересный факт 1: Автосогласование

Иногда люди думают, что “10/100 автосогласование” на одной стороне окажется достаточно разумным алгоритмом, чтобы распознать параметры второй стороны, настроенной вручную. Типа: «так, я поставлю на одной стороне 100 Мбит/с + полный дуплекс самостоятельно, а вторая сторона должна это увидеть и подстроиться». Давайте рассмотрим это на примере. Сторона номер 1 (обычно коммутатор) настроена принудительно на “100/полный дуплекс”, сторона номер 2 (обычно ПК) – выставлена на “автосогласование”. Что получится? Правильно, несоответствие, именно этот duplex mismatch:

Почему так происходит? Сторона 2 (ПК, настроенный в “авто”), сообщает: «я могу 10Мбит/с полудуплекс; 10Мбит/с полный дуплекс; 100Мбит/с полудуплекс; 100Мбит/с полный дуплекс». Ну, то есть, перечисляет все свои возможные режимы. А что говорит сторона 1 – коммутатор? А вообще ничего, он же настроен жестко. Из-за этого ПК, который ничего не слышит, на всякий случай переходит в режим полудуплекса (предполагает худшее). И это ещё хорошо, что скорость он все же может обнаружить и все-таки выставит себе 100Мбит/с, а иначе мы бы получили полный сбой соединения – стороны с несогласованной скоростью порта не могут общаться вообще никак!

Поэтому существует такое правило: ставим или обе стороны на авто, или обе вручную! По крайней мере, так было, пока не вышла спецификация 1Гбит/с (IEEE 802.3z), которая содержит небольшое, но важное предписание сообщать о параметрах, даже если узел настроен статически вручную.

По этой причине в последнее время, когда все стали переходить на гигабит и больше, количество проблем с duplex mismatch пошло на убыль.

Интересный факт 2: Полудуплекс на гигабите!

Да, есть такой стандарт: 1Гбит/с, полудуплекс. Ходят слухи, что инженеры (естественно, зная, что полудуплекс – дело прошлого) все равно должны были описать этот режим, чтобы стандарт формально остался в группе 802.3. Которая называется «CSMA-CD», и где CD означает «Collision Detection», а для этого Collision Detection нужен полудуплекс, иначе откуда там взяться коллизиям? 🙂

Что? Опять про дуплекс?

Могу себе представить, что некоторые читатели, снова смотря на главу про полный/полудуплекс, скажут: «чувак, об этом надо было помнить лет 10-15 назад, но сейчас? Сейчас все на полном дуплексе!» Ну, во-первых, этот цикл создавался для начинающих. А, во-вторых, давайте зададим простой, но важный вопрос более знающим читателям:

Сможете ли вы захватить полностью загруженный гигабитный полнодуплексный канал, используя один такой же полнодуплексный порт гигабитной сетевой карты?

И ответ… нет, не сможете.

И так как я уверен, что многие сейчас чешут затылок в размышлениях, давайте углубимся в этот вопрос ещё немного, потому что это по-настоящему важно. Ключевое слово в моем вопросе – «полнодуплексный» гигабитный канал. Как мы помним, это значит, что узел может отправлять и получать данные одновременно.

Ну так что это означает, если мы говорим про гигабитный полнодуплексный канал? 1 гигабит в секунду на прием и 1 гигабит в секудну на отправку (а совсем не 500Мбит/с на прием и 500Мбит/с на отправку, как часто неправильно думают мои ученики на курсах по Wireshark). Итого, когда мы говорим про полнодуплексный гигабитный канал, по факту мы имеем дело с общей скоростью передачи 2 гигабита в секунду (да-да, конечно, если он полностью загружен). То же относится и к 10Гбит FDX – это по сути 20Гбит. 25Гбит означает 50Гбит, 40 означает 80, 100 означает 200, если мы имеем дело с полным дуплексом.

Но все же, и почему мы не сможем захватить такой канал одним портом гигабитной карты? Она же тоже полнодуплексная, правда?

Оно-то так, но карта захвата может только получать трафик, но не отправлять (точнее, не должна бы отправлять, или, по моему мнению, не должна отправлять ни в коем случае). Итак, скорость карты захвата на передачу нам становится полностью неважна и бесполезна. И все, что нас интересует – это скорость карты захвата на прием, а она равна 1 Гбит/с. Выходит, что такой карты мало, для того, чтобы захватить полнодуплексный гигабитный загруженный канал. Потому что он будет иметь в сумме скорость 2 Гбит/с. А мы сможем принять из них только 1 Гбит/с. Нам придется с этим столкнуться ещё позже, но если уже сейчас вы подумали «вот же…», то вы на правильном пути.

Захватываем преамбулу и протокол автосогласования

Захватить преамбулу и делимитер Ethernet-кадра, которые передаются перед самим кадром, практически невозможно. Может, удастся их увидеть на экране осциллографа в медленной сети (10Мбит/с), или получится захватить коллизию (смотрите в предыдущей статье).

А причина в том факте, что сетевая карта передает компьютеру только сами кадры. Ей незачем передавать также всякие служебные вещи, которые происходят где-то в проводах, потому что попросту эти вещи никому кроме самой сетевой карты не нужны и никакого смысла загружать ими ПК нет. Если все-таки очень хочется увидеть эти данные, понадобится как минимум специализированная (читайте: профессиональная и очень дорогая) карта захвата. Никакая обычная потребительская сетевая карта не позволит этого сделать.

Если вы обладатель профессиональной карты захвата совместно с TAP, то вы как минимум сможете захватить импульсы протокола автосогласования, как на рисунке ниже (это только часть, ещё многое происходит позже, но, как видите, эта часть происходит как раз перед переходом в состояние “link up”). Захватывался этот дамп на специализированном устройстве Network General S6040 в комбинации с полнодуплексным оптическим ТАР:

«Дропы»

«Дроп», он же «отброшенный пакет» – это пакет, который по факту был в сети и должен был быть захвачен, но не захватился. Разница «потерянного» (lost) и «отброшенного» (drop) пакетов в том, что потерянный пакет пропал где-то в сети (то есть, на входе нашего порта его уже не было), и в случае, если у нас ТСР, то такой пакет будет переотправлен заново отправителем. Если же пакет не захватился, в дампе отсутствует, но в сети он был, дошел до получателя и никуда по пути не пропал – то это «дроп» То есть отбросили его мы. Примерно ситуация с дропами выглядит так:

Пример дропов в дампе

Если вы видите в Wireshark сообщение “TCP ACKed unseen segment” (это сообщение генерируется модулем-анализатором ТСР) – это верный признак дропов при захвате: Wireshark видит, что в дампе присутствует ACK (подтверждение) для какого-то пакета данных, а вот самого пакета не видит. Так как узел, участвующий в обмене данными, подтвердил прием, следовательно, пакет с данными дошел до получателя нормально. Просто этот пакет с данными не добрался до нас, до самого Wireshark’а. Всего две основных причины могут быть связаны с этим:

Но все же больше, чем в 95% случаев причиной “недолета” пакетов является первая – было недостаточно производительности устройства захвата. Кстати, ещё один признак дропов – это сообщения “TCP Previous segment not captured”, после которых нет переотправленных пакетов с данными. Подумайте об этом.

Причины дропов

Возможны несколько причин, но все они попадают в категорию «ваше устройство захвата было недостаточно быстро, чтобы захватить весь трафик без потерь». Дропы могут возникнуть по вине коммутатора, ответвителя ТАР, сетевой карты, жесткого диска и даже ЦП или памяти вашего ПК (к примеру, если ваш софт недостаточно оптимизирован). Подведем итог: всё, что угодно, – любое устройство или схема – которые находятся между пакетом в проводе и диском, куда пишется дамп, может стать причиной дропов. Что-то из этого виновато чаще, что-то реже. (Дорогие производители ТАР, следите за своим давлением, мы будем рассматривать ТАР позже, и тогда же уточним, почему дропы могут возникнуть и здесь).

В зависимости от ситуации, дропы могут иметь разную степень критичности.

Критичные дропы

Считаются таковыми, если вам нужна полная информация, и вы не можете себе позволить ни одного потерянного пакета. Зачастую это касается задач сетевой безопасности, когда необходима реконструкция контента, переданного по сети. Если у вас пропал один или несколько пакетов, которые были частью переданного вредоносного файла – вы уже не сможете этот файл полностью восстановить, и его реверс-инжиниринг будет невозможен (или как минимум затруднен).

В другой ситуации у вас может быть задача исследовать причину потерь пакетов – и дропы приведут вас к ложным выводам, просто потому, что вы думали, что пакет был потерян в сети (packet loss), а на самом деле он дропнулся на вашем устройстве захвата. (В случае с ТСР об этом хотя бы косвенно можно догадаться, как написано выше. А вот UDP и другие уже не дадут таких подсказок. – прим. перев.)

Некритичные дропы

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

Как пример можно взять анализ ТСР-соединения, которое страдает от симптома «низкая производительность (bad performance)». Здесь аналитик сможет пережить редкие дропы, потому что он видит, что TCP ACK на эти «как бы потерянные» пакеты есть, а значит, эти пакеты потеряли мы сами.

В обратном случае (исследование места реальных потерь пакетов в сети, packet loss), где задача – найти сбойное сетевое устройство, вызывающее потери, вы не можете себе позволить дропы, потому что они исказят всю картину. Вы можете быть не в состоянии разграничить, был ли этот пакет реально потерян кем-то другим, или виновник – вы же сами.

Несущественные дропы

Дропы становятся несущественными, если аналитику и так не нужен был каждый пакет. Например, если он делает снимок характеристик трафика в сети (baselining). Если просто нужно собрать некоторую статистику сети (например, распределение протоколов, «какой процент от всех пакетов у нас НТТР?»), вы можете запросто пережить дропы. Они особо не повлияют на конечный результат (ну, конечно, если у вас их не огромное количество) 🙂

Заключение

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

Что стоит вынести из данной статьи:

– дропы могут быть как большой проблемой, так и не очень;

– полный дуплекс – это скорость больше, чем она кажется на первый взгляд, и если канал загружен, а у вас карта захвата только с одним портом…

Статья переведена и опубликована с разрешения автора (Jasper Bongertz) только для сайта packettrain.net

Использование материала статьи без согласования запрещено!

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Погружение в Iptables – теория и настройка

Большой и наглядный материал

Netfilter является основой для построения Firewall’а в дистрибутивах Linux, но для того, чтобы он заработал в полную силу его нужно настроить. Как раз с помощью iptables мы можем взаимодействовать с хуками Netfilter и создавать правила фильтрации, маршрутизации, изменения и транслирования пакетов. Иногда про Netfilter забывают и называют эту связку просто iptables.

Введение

Почему же iptables всем так понравился, что его стали включать во все сборки Linux? Всё дело в том, что iptables действительно очень прост в настройке. С помощью него можно решить следующие задачи:

Прежде чем переходить к практике, давайте обратимся к теории и поймём саму логику iptables.

Логика и основные понятия iptables

Правила

Как и все файрволлы, iptables оперирует некими правилами (rules), на основании которых решается судьба пакета, который поступил на интерфейс сетевого устройства (роутера).

Ну допустим у нас есть сетевое устройство с адресом 192.168.1.1, на котором мы настроили iptables таким образом, чтобы запрещать любые ssh (порт 22) соединения на данный адрес. Если есть пакет, который идёт, например, с адреса 192.168.1.15 на адрес 192.168.1.1 и порт 22, то iptables скажет: “Э, нет, брат, тебе сюда нельзя” и выбросит пакет.

Или вообще ничего не скажет и выбросит, но об этом чуть позже 🙂

Каждое правило в iptables состоит из критерия, действия и счётчика

Цепочки

Набор правил формируется в цепочки (chains)

Существуют базовые и пользовательские цепочки.

Существует 5 базовых цепочек и различаются они в зависимости от того, какое назначение имеет пакет. Имена базовых цепочек записываются в верхнем регистре.

В базовых цепочках обязательно устанавливается политика по умолчанию, как правило – принимать (ACCEPT) или сбрасывать (DROP) пакеты. Действует она только в цепочках INPUT, FORWARD и OUTPUT

Таблица

Существует 5 таблиц:

Теперь мы можем представить себе логику iptables в виде следующей схемы:

Действия

Итак, наиболее используемые действия:

Помимо этих четырех, есть ещё масса других действий, которые называются расширенными (extension modules):

Есть действия, которые доступны только в определенной цепочке и таблицах, например, только в табоице nat и цепочках OUTPUT и PREROUTING доступно действие DNAT, которое используется в NAT’ировании и меняет Destination IP пакета. В той же таблице, только в цепочке POSTRUNNING доступно действие SNAT, меняющее Source IP пакета.

Отдельно остановимся на действии MASQUERADE, которое делает то же самое что SNAT, только применяется на выходном интерфейсе, когда IP адрес может меняться, например, когда назначается по DHCP.

Пишем правила

Отлично, теперь давайте приближаться к практике. Как Вы уже поняли, мы будем писать правила, поэтому нам нужно понять, как они строятся.

Итак, допустим у нас есть хост с адресом 192.168.2.17, на 80 (http) порту которого, работает вэб-сервер Apache. Мы заходим на адрес http://192.168.2.17 с хоста с адресом 192.168.2.2 и всё отлично работает:

А теперь открываем командную строку под root на хосте 192.168.2.17 и пишем:

Попробуем открыть открыть http://192.168.2.17 ещё раз:

Упс, не работает. Давайте теперь разбираться, что мы наделали?

Всё очень просто – данной командой мы:

Таким образом, мы заблокировали все пакеты с адреса 192.168.2.2 на локальный порт 80 и тем самым закрыли доступ к нашему серверу Apache для данного хоста.

Чтобы открыть доступ опять просто поменяем ключ -A в правиле на -D, тем самым мы удалим данное правило из iptables.

Синтаксис iptables

Друзья, на самом деле в iptables очень богатый синтаксис правил. Полный список ключей и параметров вы можете найти в официальном гайде на iptables.org. Мы же приведём самые “ходовые” опции, которыми вы, вероятно, будете пользоваться. Чтобы вы не запутались, мы приводим их в табличках ниже.

Для удобства, в iptables реализовано очень много сокращений для разных ключей. Например, мы писали ключ -A вместо полного —append, -p вместо полного —proto и -s вместо полного —source, дальше мы покажем, что ещё можно сократить и где применить.

Начнём с команд для редактирования правил и цепочек – добавления, удаления, замены и так далее:

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

Теперь рассмотрим опции для действий, которые должны сработать по совпадению критериев:

Теперь рассмотрим какую информацию мы можем вытянуть с помощью iptables и какие опции для этого нужно использовать:

Пример посложнее

Давайте рассмотрим ещё один пример. Допустим у нас во локальной сети есть хост 192.168.2.19 с сервером Apache. Мы хотим сделать его доступным из Интернета. Для этого нам нужно воспользоваться возможностями таблицы nat и написать правило, которое будет перенаправлять входящий http трафик на внешний интерфейс (пусть будет enp0s3 с адресом 101.12.13.14) и порт 80 на адрес нашего сервера внутри сети и 80 порт – 192.168.2.19:80. По сути – нужно сделать проброс портов.

Напишем такое правило:

Теперь если мы перейдём по адресу http://101.12.13.14, то должны попасть на наш Apache.

Возможности iptables настолько обширны, что мы могли бы начать писать новую Базу знаний по нему. В статье мы показали лишь базовые варианты применения. Это действительно великий инструмент и освоить его не так уж сложно. Надеюсь, данная статья Вам в этом поможет. Спасибо за внимание!

Источник