Посмотреть таблицу nat linux

Просмотр правил iptables

В данной статье мы рассмотрим как посмотреть правила iptables с помощью команды iptables -L, а также основные её опции и параметры. Данная команда выводит в командную оболочку bash в структурированном виде все цепочки правил firewall Netfilter. Информация предоставляется для изучения уже настроенных возможностей межсетевого экрана и последующей их модификации с помощью других команд. Таблицы правил выводятся в текстовом режиме.

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

Как посмотреть правила iptables

В данном случае для демонстрации возможностей iptables используется операционная система Debian 10.2. Для возможности выполнения команды iptables необходимо, чтобы пользователю были предоставлены привилегии суперпользователя с помощью команды sudo. В связи с этим все команды будут выглядеть как sudo iptables [параметры] или sudo ip6tables [параметры] для IPv6.

Примечание: Для того, чтобы пользователю было позволено предоставлять привилегии суперпользователя, этого пользователя надо добавить в файл sudoers с помощью специального редактора visudo. Посмотрим на скриншот с результатом выполнения команды:

Существуют две версии утилиты для настройки брандмауэра Linux: iptables и ip6tables. Iptables используется для протокола IPv4, а ip6tables для протокола IPv6. Соответственно команда вывести все цепочки правил для межсетевого экрана имеет два варианта синтаксиса.

Для протокола IPv4:

sudo iptables -L

Для протокола IPv6:

sudo ip6tables -L

В дальнейшем рассмотрим только вариант для протокола IPv4, вариант для протокола IPv6 использует такой же синтаксис.

Выводимая на экран информация разбита на столбцы и строки. У каждого столбца свое наименование. С помощью дополнительных параметров команды sudo iptables -L можно добавлять дополнительные столбцы в выводимой таблице правил iptables. Рассмотрим название столбцов в стандартном выводе sudo iptables -L:

• target – выполняемое действие с пакетом при соответствии его данному правилу
• prot – протокол передачи данных, при котором применяется данное правило
• opt – дополнительные опции для правила
• source – IP адрес, подсеть, домен узла источника пакета, попадающего под выполнение данного правила
• destination – IP адрес, подсеть, домен узла назначения пакета, попадающего под выполнение данного правила

1. Список правил из цепочки

Команда чтобы вывести на экран конкретную цепочку правил выглядит следующим образом:

sudo iptables [ -L имя цепочки ]

Например просмотр правил iptables из цепочки OUTPUT:

sudo iptables -L OUTPUT

2. Список правил из таблицы

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

sudo iptables [ -t имя таблицы ] [ -L имя цепочки ]

sudo iptables -t nat -L OUTPUT

Вот список всех таблиц правил iptables:

• filter – таблица по умолчанию. Используется для фильтрации пакетов. Содержится в цепочках INPUT, FORWARD, OUTPUT
• raw – используется редко. Пакет проверяется на соответствие условиям данной таблицы до передачи системе определения состояний (conntrack), например, для того, чтобы не обрабатываться с помощью данной системы (действие NOTRACK). Система определения состояний позволяет фильтровать пакеты на уровне взаимодействия сеансов приложений. То есть фильтрует пакеты по сеансу связи – новый сеанс связи (NEW), уже установленный сеанс связи (ESTABLISHED), дополнительный сеанс связи к уже существующему (RELATED). Данная система позволяет реализовать высокоуровневый межсетевой экран, который вместо работы с пакетами работает с сеансами связи в рамках приложений. Содержится в цепочках PREROUTING и OUTPUT.
• mangle – содержит правила модификации обрабатываемых IP-пакетов. Например, изменение полей заголовков IP-пакетов, содержащих служебную информацию. Используется редко. Содержится в цепочках PREROUTING, INPUT, FORWARD, OUTPUT,
• nat – предназначена для подмены адреса отправителя или получателя. Данная таблица применяется только к первому пакету из потока протокола передачи данных по сети, к остальным пакетам потока пакетов выбранное действие применяется далее автоматически. Таблицу используют, например, для трансляции адресов отправителя и получателя, для маскировки адресов отправителя или получателя. Это делается в основном в двух случаях. Первый – когда необходимо организовать доступ к сети Интернет нескольким компьютерам, расположенным за данным компьютером. Второй – когда необходимо спрятать (замаскировать) в целях безопасности отправителя или получателя информации, передаваемой по сети Интернет. Содержится в цепочках PREROUTING, OUTPUT, POSTROUTING.

3. Номера правил в iptables

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

sudo iptables [ -t таблица ] [ -L имя_цепочки ] —line-numbers -n

sudo iptables -t filter -L —line-numbers -n

4. Просмотр правил со статистикой пакетов

Чтобы посмотреть таблицу правил со счетчиком переданного (полученного) количества байтов (bytes) и пакетов (pkts) используется следующая команда:

sudo iptables [ -t таблица ] [ -L имя цепочки ] -n -v

sudo iptables -t filter -L -n -v

Выводы

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

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

iptables NAT, таблица трансляций (как просмотреть таблицу трансляций)

Модератор: SLEDopit

iptables NAT, таблица трансляций

Сообщение sntaav » 21.12.2008 14:58

Re: iptables NAT, таблица трансляций

Сообщение pelmen » 21.12.2008 16:06

Re: iptables NAT, таблица трансляций

Сообщение Pchol » 21.12.2008 16:40

Re: iptables NAT, таблица трансляций

Сообщение Ariasp » 21.12.2008 18:42

Re: iptables NAT, таблица трансляций

Сообщение Pchol » 21.12.2008 18:51

Вот что вижу. Хотя сейчас «в НАТе» этой машины около 150 человек.
Может быть конечно представленная вами команда не действует при использовании дейсвтия SAME.
Но всё же её вывод не показывает в динамике разданные ip и сопоставления портов.

Re: iptables NAT, таблица трансляций

Сообщение pelmen » 21.12.2008 19:17

Re: iptables NAT, таблица трансляций

Сообщение Ariasp » 21.12.2008 19:35

Re: iptables NAT, таблица трансляций

Сообщение Sandle_X » 21.12.2008 21:13

)2.2.1
Installed versions: 2.2.1(21:11:19 21.12.2008)
Homepage: http://www.phildev.net/iptstate/
Description: IP Tables State displays states being kept by iptables in a top-like format

Re: iptables NAT, таблица трансляций

Сообщение sntaav » 28.01.2009 20:49

Источник

Быстрый роутинг и NAT в Linux

Немного истории

Тема исчерпания адресного пространства IPv4 уже не нова. В какой-то момент в RIPE появились очереди ожидания (waiting list), затем возникли биржи, на которых торговали блоками адресов и заключались сделки по их аренде. Постепенно операторы связи начали предоставлять услуги доступа в Интернет с помощью трансляции адресов и портов. Кто-то не успел получить достаточно адресов, чтобы выдать «белый» адрес каждому абоненту, а кто-то начал экономить средства, отказавшись от покупки адресов на вторичном рынке. Производители сетевого оборудования поддержали эту идею, т.к. этот функционал обычно требует дополнительных модулей расширения или лицензий. Например, у Juniper в линейке маршрутизаторов MX (кроме последних MX104 и MX204) выполнять NAPT можно на отдельной сервисной карте MS-MIC, на Cisco ASR1k требуется лицензия СGN license, на Cisco ASR9k — отдельный модуль A9K-ISM-100 и лицензия A9K-CGN-LIC к нему. В общем, удовольствие стоит немалых денег.

IPTables

Задача выполнения NAT не требует специализированных вычислительных ресурсов, ее в состоянии решать процессоры общего назначения, которые установлены, например, в любом домашнем роутере. В масштабах оператора связи эту задачу можно решить используя commodity серверы под управлением FreeBSD (ipfw/pf) или GNU/Linux (iptables). Рассматривать FreeBSD не будем, т.к. я довольно давно отказался от использования этой ОС, так что остановимся на GNU/Linux.

Включить трансляцию адресов совсем не сложно. Для начала необходимо прописать правило в iptables в таблицу nat:

Операционная система загрузит модуль nf_conntrack, который будет следить за всеми активными соединениями и выполнять необходимые преобразования. Тут есть несколько тонкостей. Во-первых, поскольку речь идет о NAT в масштабах оператора связи, то необходимо подкрутить timeout’ы, потому что со значениями по умолчанию размер таблицы трансляций достаточно быстро вырастет до катастрофических значений. Ниже пример настроек, которые я использовал на своих серверах:

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

Также необходимо увеличить и количество buckets для хэш-таблицы, хранящей все трансляции (это опция модуля nf_conntrack):

После этих нехитрых манипуляций получается вполне работающая конструкция, которая может транслировать большое количество клиентских адресов в пул внешних. Однако, производительность этого решения оставляет желать лучшего. В своих первых попытках использования GNU/Linux для NAT (примерно 2013 год) я смог получить производительность около 7Gbit/s при 0.8Mpps на один сервер (Xeon E5-1650v2). С того времени в сетевом стеке ядра GNU/Linux было сделано много различных оптимизаций, производительность одного сервера на том же железе выросла практически до 18-19 Gbit/s при 1.8-1.9 Mpps (это были предельные значения), но потребность в объеме трафика, обрабатываемого одним сервером, росла намного быстрее. В итоге были выработаны схемы балансировки нагрузки на разные серверы, но всё это увеличило сложность настройки, обслуживания и поддержания качества предоставляемых услуг.

NFTables

Сейчас модным направлением в программном «перекладывании пакетиков» является использование DPDK и XDP. На эту тему написана куча статей, сделано много разных выступлений, появляются коммерческие продукты (например, СКАТ от VasExperts). Но в условиях ограниченных ресурсов программистов у операторов связи, пилить самостоятельно какое-нибудь «поделие» на базе этих фреймворков довольно проблематично. Эксплуатировать такое решение в дальнейшем будет намного сложнее, в частности, придется разрабатывать инструменты диагностики. Например, штатный tcpdump с DPDK просто так не заработает, да и пакеты, отправленные назад в провода с помощью XDP, он не «увидит». На фоне всех разговоров про новые технологии вывода форвардинга пакетов в user-space, незамеченными остались доклады и статьи Pablo Neira Ayuso, меинтейнера iptables, про разработку flow offloading в nftables. Давайте рассмотрим этот механизм подробнее.

Основная идея заключается в том, что если роутер пропустил пакеты одной сессии в обе стороны потока (TCP сессия перешла в состояние ESTABLISHED), то нет необходимости пропускать последующие пакеты этой сессии через все правила firewall, т.к. все эти проверки всё равно закончатся передачей пакета далее в роутинг. Да и собственно выбор маршрута выполнять не надо — мы уже знаем в какой интерфейс и какому хосту надо переслать пакеты пределах этой сессии. Остается только сохранить эту информацию и использовать ее для маршрутизации на ранней стадии обработки пакета. При выполнении NAT необходимо дополнительно сохранить информацию об изменениях адресов и портов, преобразованных модулем nf_conntrack. Да, конечно, в этом случае перестают работать различные полисеры и другие информационно-статистические правила в iptables, но в рамках задачи отдельного стоящего NAT или, например, бордера — это не так уж важно, потому что сервисы распределены по устройствам.

Конфигурация

Чтобы воспользоваться этой функцией нам надо:

• Использовать свежее ядро. Несмотря на то, что сам функционал появился еще в ядре 4.16, довольно долго он было очень «сырой» и регулярно вызывал kernel panic. Стабилизировалось всё примерно в декабре 2019 года, когда вышли LTS ядра 4.19.90 и 5.4.5.
• Переписать правила iptables в формат nftables, используя достаточно свежую версию nftables. Точно работает в версии 0.9.0

Если с первым пунктом всё в принципе понятно, главное не забыть включить модуль в конфигурацию при сборке (CONFIG_NFT_FLOW_OFFLOAD=m), то второй пункт требует пояснений. Правила nftables описываются совсем не так, как в iptables. Документация раскрывает практически все моменты, также есть специальные конверторы правил из iptables в nftables. Поэтому я приведу только пример настройки NAT и flow offload. Небольшая легенда для примера: , — это сетевые интерфейсы, через которые проходит трафик, реально их может быть больше двух.

— начальный и конечный адрес диапазона «белых» адресов.

Конфигурация NAT очень проста:

С flow offload немного сложнее, но вполне понятно:

Вот, собственно, и вся настройка. Теперь весь TCP/UDP трафик будет попадать в таблицу fastnat и обрабатываться намного быстрее.

Результаты

Чтобы стало понятно, насколько это «намного быстрее», я приложу скриншот нагрузки на два реальных сервера, с одинаковой начинкой (Xeon E5-1650v2), одинаково настроенных, использующих одно и тоже ядро Linux, но выполняющих NAT в iptables (NAT4) и в nftables (NAT5).

На скриншоте нет графика пакетов в секунду, но в профиле нагрузки этих серверов средний размер пакета в районе 800 байт, поэтому значения доходят до 1.5Mpps. Как видно, запас производительности у сервера с nftables огромный. На текущий момент этот сервер обрабатывает до 30Gbit/s при 3Mpps и явно способен упереться в физическое ограничение сети 40Gbps, имея при этом свободные ресурсы CPU.

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

Источник