оригинал тут http://www.k-max.name/linux/princip-raboty-routing-policy-database/

 

Пару вступительных слов о маршрутизации

 

 Итак, из основных понятий сетей мы знаем, если сетевой пакет предназначен для локальной сети, к которой подключен интерфейс, то он направляется прямо в сеть. Маршрут для такого пакета создается автоматически при поднятии настроенного интерфейса. Если пакет предназначен не локальной сети, то ядро просматривает таблицу маршрутизации на наличие маршрута для данного пакета и отправляет по маршруту, в котором адрес назначения пакета соответствует заданному в маршруте параметру - на адрес шлюза, который указан в поле gateway в маршруте.  При этом, может существовать несколько маршрутов для данного пакета. В таком случае выбирается тот маршрут, в котором в заданной подсети меньше всего компьютеров. Если для текущего пакета маршрут не обнаружен, то он направляется на маршрут "по-умолчанию". Это классическая маршрутизация протокола IPv4, основанная на поиске маршрута по адресу назначения в заголовках IP.

 

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

 

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

 

 

 

Маршрутизация на основе политик (Policy Routing)

 

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

 

Основу маршрутизации на основе политик составляют 4 понятия. Это традиционные понятия address (адрес) , routes (маршрут), Routing table (таблица маршрутизации), а так же новое в Policy Routing (и являющееся его основой) - rules (правила). Давайте разберем каждый из них.

 

 

 

Адрес (Address) определяет место назначения пакета и источник. Маршрут (routes) задает путь пакета, данное понятие не сильно отличается от традиционной маршрутизации. Соответственно, при задании маршрута так же, как и в традиционном способе (с помощью команды route) можно указать шлюз и несколько опций для маршрута, задаваемого для хоста или подсети. Среди опций можно выделить такие как: метрика (metric),  размер-TCP-окна (window) и др. В Policy Routing помимо стандартных параметров добавления маршрута появились так же опции, позволяющие указать исходящий адрес источника пакета, интерфейс или тип ICMP ответа. Таблица маршрутизации (Routing table) состоит из последовательного набора маршрутов.  Правила (rule) можно рассматривать, как своеобразный фильтр, который отбирает пакеты, удовлетворяющие определенным требованиям и подходящие - направляет по заданному маршруту.

 

 

 

Routing Policy DataBase (RPDB)

 

Механизм маршрутизации на основе политик впервые был реализован в ядре версии 2.1. Он так же называется "база данных политик маршрутизации" (он же Routing Policy DataBase (RPDB)). RPDB - это связанный набор маршрутов, таблиц маршрутизации и правил. Механизм маршрутизации и ip адресации в ядре Linux 2.1 был переписан чуть более чем полностью, в результате чего появилась возможность поддерживать до 255 таблиц маршрутизации и 2^32 правил маршрутизации. Это позволяет создать более чем 4 миллиарда правил, данная цифра перекрывает все пространство адресов IPv4. Другими словами, Вы можете определить правило управления каждым отдельным адресом, доступным во всем адресном пространстве IPv4.

 

 

 

Давайте рассмотрим некоторый пример, который далее позволит нам более детально разобраться в Routing Policy.  В классическом примере на хосте Linux имеется единственная таблица маршрутизации, в которой согласно правил и места назначения пакета ищется маршрут (адрес шлюза и/или физической интерфейс). Давайте предположим, что у нас есть 3 маршрута к некоторой сети назначения, путь через которые (маршруты) проходит по каналам разного качества, соответственно разная скорость. Предположим, в локальной сети есть некоторая группа компьютеров, которой нужна гарантированная скорость, а другой группе высокая скорость не нужна. Если у нас будет единственная таблица маршрутизации, то мы сможем указать лишь единственный маршрут к сети назначения, через единственны шлюз. Данный функционал реализуем в Policy Routing - маршрутизации на основе адреса отправителя пакета.  Это наиболее распространенный и часто применяемый метод маршрутизации. При этом, в правилах отбираются пакеты на основании принадлежности хоста-отправителя заданной в правиле подсети.

 

 

 

Давайте рассмотрим работу Routing Policy в схеме и разберем порядок работы:

 

1. Правила (rules)

 

Как видно, при маршрутизации первый элемент, через который проходит пакет - это набор правил. Каждое правило состоит из критерия отбора пакетов - своеобразный "фильтр" (например, from 2.1.7.100 - отбирает все пакеты с адресом отправителя 2.1.7.100) и действия над "подходящим" пакетом (например, lookup table_name2 - направляет пакет в таблицу маршрутизации с именем table_name2. Дословно: просмотреть table_name2).

 

 

 

При этом, каждый фильтр/критерий может состоять из указания исходного адреса, адреса получателя, входящего интерфейса, TOS и fwmark (поле TOS задает тип сервиса, что это и с чем его едят я ответить не готов, но могу направить в RFC 1349, fwmark - это метки, которые можно задать силами iptables/netfilter).

 

 

 

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

 

 

 

• unicast (lookup) - просмотр указанной таблицы маршрутизации, если при создании правила не указан тип, то используется данный тип.
• nat - правило преобразовывает адрес отправителя, без запоминания состояния соединения! (обычно используется совместно с соответствующей записью, маршрутизирующей данный пакет)
• unreachable - выбросить пакет и вернуть сообщение ICMP о недоступности сети
• prohibit - выбросить пакет и вернуть сообщение ICMP о запрещении доступа
• blackhole - молча выбросить пакет (дословно - черная дыра)

 

 

 

Каждое правило имеет свой приоритет от 0 до 32767, в соответствии с которым ядро просматривает данные правила. При старте системы по умолчанию создаются следующие правила:

 

 

 

[root@rpdb ~]# ip rule list

0: from all lookup local

32766: from all lookup main

32767: from all lookup default

 

 

 

Правило с приоритетом 0 (ноль) действует для всех пакетов (from all) и направляет в таблицу маршрутизации local. Таблица local - специальная таблица маршрутизации, содержащая высокоприоритетные маршруты управления для локальных и широковещательных адресов. Правило 0 (ноль) является особенным, оно не может быть удалено или переопределено.

 

 

 

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

 

 

 

Правило с приоритетом 32767 действует так же для всех пакетов (from all) и направляет в таблицу default. Таблица default - по-умолчанию пуста и зарезервирована для использования. Может применяться для назначения маршрутов по умолчанию для пакетов, не направленных куда-либо в предыдущих правилах. Правило может быть удалено.

 

 

 

При добавлении правила в ручную, без указания приоритета (параметр  priority), новые правила будут получать номер с 32765 до 1.

 

 

 

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

 

 

 

Управление правилами осуществляется с помощью команды ip с ключом rule. Вот некоторые примеры:

 

 

 

[root@rpdb: ~]# # добавление правила, направляющего пакеты с хоста 192.168.100.1 в таблицу 5

[root@rpdb: ~]# ip rule add from 192.168.100.1 table 5 

[root@rpdb: ~]# # добавление правила для пакетов, помеченных netfilter меткой 4 в таблицу 4

[root@rpdb: ~]# ip rule add fwmark 4 table 4

[root@rpdb: ~]# # добавление правила для хоста 209.10.26.51 - пакеты будут "пропадать"

[root@rpdb: ~]# ip rule add blackhole from 209.10.26.51

 

 

 

2. Таблицы маршрутизации

 

 

 

Итак, следующим шагом на пути пакета по сетевой подсистеме ядра будет таблица маршрутизации, в которую пакет будет направлен соответствующим правилом. Ядро использует несколько таблиц маршрутизации с номерами от 1 до 255. Сопоставление номеров таблиц к их именам задается в файле /etc/iproute2/rt_tables. Фактически, задавать имена таблиц их номерным идентификаторам нет необходимости (в правилах можно просто использовать номера таблиц). По умолчанию при создании маршрута в Linux, если не задано имя таблицы, то используется таблица с ID 254 (main). Кроме таблицы main в ядре зарезервированы следующие имена:

 

 

 

[root@rpdb ~]# cat /etc/iproute2/rt_tables

255 local

254 main

253 default

0 unspec

 

 

 

Про main я уже сказал, но в ядре существует так же не менее важная таблица local с  ID 255, которая состоит из маршрутов для локальных и широковещательных адресов. Ядро поддерживает эту таблицу автоматически, и администраторы никогда не должны изменять ее содержимое и нет необходимости даже в нее заглядывать при нормальном функционировании. Назначение таблицы default я описывал выше при описании правил. Таблица unspec - это "псевдо-таблица", которая содержит в себе правила ВСЕХ таблиц маршрутизации системы. Именно по этому у нее номер ноль, который не входит в диапазон с 1 по 255.  Все таблицы маршрутизации ядра никак между собой не связаны, таким образом, у Вас может быть несколько идентичных маршрутов в различных таблицах, которые не будут конфликтовать. Нумерация таблиц большого значения не имеет. То есть все таблицы по сути имеют одинаковый вес и приоритет их определяется только заданными правилами.

 

 

 

Просмотреть содержимое таблицы можно командой ip (на примере таблицы main):

 

 

 

[root@rpdb ~]# ip route list table main

default via 10.0.0.254 dev eth0

10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.0.2

 

 

 

3. Маршруты/правила

 

 

 

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

 

 

 

• unicast - обычный маршрут, определяет исходящий интерфейс и адрес следующего хопа для подсети/хоста назначения.
• unreachable - пакет выбрасывается и посылается ICMP сообщение "host unreachable".
• blackhole - пакет просто выбрасывается без возвращения какого-либо сообщения.
• prohibit (дословно - запрещен) - пакет выбрасывается и посылается ICMP сообщение "administratively prohibited".
• local - место назначения данного маршрута - локальный хост. В этом маршруте пакеты перемещаются локально.
• broadcast - пакет пересылается в виде широковещательного сообщения
• throw - специальный управляющий маршрут, используется совместно с правилами маршрутизации; Если пакет будет соответствовать данному маршруту, то поиск в этой таблице завершается, эмитируя что для данного пакета маршрут не найден и возвращается в RPDB для обработки в следующем правиле.
• nat - адреса сети назначения преобразуются в соответствии с параметром via; маршрутизатор также обслуживает ARP запросы для этой сети; не предназначен для сжатия адресного пространства или разделения нагрузки; в частности, не хранит таблицу соединений и не заглядывает внутрь пакета; можно использовать при перенумерации сети; для обратного преобразования необходимо задать дополнительное правило маршрутизации "ip rule add from реальный-адрес nat виртуальный-адрес".
• anycast - локальные адреса, которые нельзя использовать в качестве адресов источника. (непонятный мне тип маршрута)
• multicast - Специальный тип, используемый для многоадресной маршрутизации. Он не присутствует в статичных таблицах маршрутизации.

 

 

 

Управление правилами в таблице маршрутизации осуществляется с помощью команды ip с ключом route.

 

 

 

Выбор IP-адреса для исходящих соединений

 

 

 

Выбор локального адреса для исходящих соединений в большинстве случаев системой осуществляется автоматически, исходя из имеющихся IP-адресов интерфейсов и таблиц маршрутизации. Во многих случаях сетевые сервисы (веб-сервер, почтовый сервер и др.) позволяют указывать исходный адрес с помощью конфигурационных файлов. Давайте рассмотрим пример. Пусть система имеет два интерфейса eth0(192.168.1.1/24) и eth1(192.168.56.102/24):

 

 

 

[root@rpdb ~]# ip addr show

1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast

        state UP qlen 1000 link/ether 08:00:27:23:22:97 brd ff:ff:ff:ff:ff:ff

        inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0

        inet6 fe80::a00:27ff:fe23:2297/64 scope link

        valid_lft forever preferred_lft forever

2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast

        state UP qlen 1000 link/ether 08:00:27:fd:e5:aa brd ff:ff:ff:ff:ff:ff

        inet 192.168.56.102/24 brd 192.168.56.255 scope global eth1

        inet6 fe80::a00:27ff:fefd:e5aa/64 scope link

        valid_lft forever preferred_lft forever

 

 

 

Маршрут по умолчанию у данной системы - 192.168.56.1:

 

 

[root@rpdb ~]# ip route show

192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1

192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.102

default via 192.168.56.1 dev eth1

 

 

 

При такой конфигурации для исходящих соединений будет использоваться интерфейс eth1 и IP-адрес 192.168.56.102 (кроме соединений с узлами сети 192.168.1.0/24 — eth0 и IP-адрес 192.168.1.1). Ниже показан дамп сетевого пакета, отправленного командой ping -c 1 192.168.3.4:

 

 

 

[root@rpdb ~]# tcpdump -ne -i eth1 host 192.168.3.4

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode  listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

10:18:18.924084 08:00:27:fd:e5:aa > 0a:00:27:00:00:00, ethertype IPv4 (0x0800),

length 98: 192.168.56.102 > 192.168.3.4: ICMP echo request, id 960, seq 1, length 64

 

 

 

Однако, если добавить альтернативный маршрут для сети 192.168.3.0/24 через некоторый шлюз 192.168.1.254:

 

 

 

[root@rpdb ~]# ip route add 192.168.3.0/24 via 192.168.1.254

 

 

 

то, для пакетов, предназначенных узлу 192.168.3.4, будет использоваться интерфейс eth0 и исходящий адрес 192.168.1.1 (показан дамп сетевого пакета):

 

 

 

[root@rpdb ~]# tcpdump -ne -i eth0 host 192.168.3.4

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

10:23:33.393706 08:00:27:23:22:97 > 00:00:00:00:00:aa, ethertype IPv4 (0x0800),

 length 98: 192.168.1.1 > 192.168.3.4: ICMP echo request, id 968, seq 1, length 64

 

 

 

Синтаксис команды ip route позволяет повлиять на выбор локального IP-адреса при соединении с удаленными системами. Для этого служит параметр src с указанием предпочитаемого IP-адреса (должен быть установлен на сетевом интерфейсе компьютера) для отправки пакетов на направление, определяемое в команде префиксом маршрутизации. Так, для указанной ниже конфигурации будет использоваться исходящий адрес 192.168.56.102 (кроме взаимодействия с узлами сети 192.168.1.0/24):

 

 

 

[root@rpdb ~]# ip addr show eth1

2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

         link/ether 08:00:27:fd:e5:aa brd ff:ff:ff:ff:ff:ff

         inet 192.168.56.102/24 brd 192.168.56.255 scope global eth1

         inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1:1

         inet6 fe80::a00:27ff:fefd:e5aa/64 scope link

         valid_lft forever preferred_lft forever

[root@rpdb ~]# ip route show

192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10

192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.102

default via 192.168.56.1 dev eth1

 

 

 

Для того, чтобы использовать исходный адрес 192.168.1.10 для соединения с узлами сети 192.168.3.0/24 следует использовать команду:

 

 

 

[root@rpdb ~]# ip route add 192.168.3.0/24 via 192.168.56.1 src 192.168.1.10 dev eth1:1

 

 

 

Таблица маршрутизации при этом будет иметь вид:

 

 

 

[root@rpdb ~]# ip route show

192.168.3.0/24 via 192.168.56.1 dev eth1 src 192.168.1.10

192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10

192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.102

default via 192.168.56.1 dev eth1

 

 

 

Добавление альтернативного маршрута для "избранных" хостов

 

 

 

Рассмотрим классический пример, когда в локальной сети необходимо направить избранные хосты по альтернативному маршруту. Предположим, что в локальной сети 10.0.0.0/24 имеется некоторый шлюз с двумя интерфейсами, имеющими IP-адреса 10.0.0.1/24 - смотрит в локальную сеть, 12.13.14.15/24 - смотрит в глобальную сеть. Маршрут по умолчанию проходит через IP 12.13.14.1. При этом необходимо, чтобы хост 10.0.0.100 был направлен по маршруту 12.13.14.100. Для решения этой задачи, необходимо:

 

 

 

Добавить описание  дополнительной таблицы маршрутизации в файл /etc/iproute2/rt_tables (это действие необязательно, можно использовать просто номер таблицы)

 

 

 

# echo 100 newtable >> /etc/iproute2/rt_tables

 

 

 

Добавить правило, которое будет направлять пакеты с адресом отправителя 10.0.0.100 в описанную на прошлом шаге таблицу маршрутизации

 

 

 

# ip rule add from 10.0.0.100 lookup newtable

# # или

# ip rule add from 10.0.0.100 lookup 100

# # после выполнения данной команды список правил примет следующий вид

# ip rule show

0: from all lookup local

32765: from 10.0.0.100 lookup newtable

32766: from all lookup main

32767: from all lookup default

 

 

 

Добавить новый маршрут по умолчанию, отправляющий пакеты на хост 12.13.14.100 в новую таблицу маршрутизации

 

 

 

# ip route add default via 12.13.14.100 dev eth1 table newtable

# # после внесенных изменений необходимо очистить кэш маршрутов, чтобы ядро обновило информацию о новых маршрутах

# ip route flush cache

# # после данных изменений таблица newtable (id 100) будет иметь следующий вид

# ip route show table 100

default via 12.13.14.100 dev eth1

 

 

 

Давайте рассмотрим путь пакета, согласно наших правил. Хост 10.0.0.100 отправляет пакет некоторому узлу 7.8.9.10, соответственно, в заголовках пакета источник - 10.0.0.100, назначение - 7.8.9.10. На хосте 10.0.0.100 шлюз по умолчанию - 10.0.0.1, согласно данного правила пакет попадает на шлюз 10.0.0.1. Ядро, получив пакет последовательно с нулевого правила просматривает соответствие пакета заданным в правилах фильтрам/критериям. Пакет подходит под действие правила 0 (0: from all lookup local) и направляется в таблицу маршрутизации local. Но т.к. пакет не принадлежит локальной системе и он не широковещательный, то маршрут в данной таблице не найден и пакет возвращается в RPDB для просмотра следующего правила. Следующее правило на пути пакета -  32765: from 10.0.0.100 lookup newtable. Пакет под критерии данного правила подходит, поэтому направляется в таблицу newtable (id 100). Согласно данной таблицы все пакеты направляются на единственный маршрут по умолчанию - 12.13.14.100. Пакет уходит согласно этого правила на указанный хост. Следующие правила не обрабатываются. Обращаю внимание, что в данном разборе я не учитывал прохождение пакета через таблицы netfilter.

 

 

 

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

 

 

 

В статье я рассмотрел работу механизма Routing Policy DataBase (RPDB) - маршрутизации на основе политик. Я долго вникал в работу этого механизма и постарался изложить свое понимание всего происходящего в ядре. Доходчивой документации на русском языке по данному вопросу в сети я не нашел. Даже всеми хваленый LARTC не дает прозрачного понимания RPDB. Надеюсь, что мои мысли помогут вам понять основные принципы. Подводя итог всему вышесказанному можно свести основной смысл к тому, что пакет в порядке приоритета правил (от 0 до 32767) сверяется с каждым правилом и в случае, если подходит под заданные условия, над пакетом совершается какое-либо действие (обычно отправляется в указанную таблицу). Если пакет в заданной таблице находит свой маршрут, то он отправляется по заданному маршруту. Если не находит - возвращается к списку правил для обработки в следующем правиле. Управление всем этим делом осуществляется командой ip с различными параметрами. В дальнейших статьях я постараюсь рассмотреть более интересные примеры реализации маршрутизации на основе политик. Кроме того, я бы обязательно посоветовал вам почитать приведенные ниже ссылки для более глубокого ознакомления.

 

 

 

Что еще почитать

 

 

 

Хорошая статья о том, что такое маршрут по умолчанию - http://xgu.ru/wiki/Маршрут_по_умолчанию
RFC 1394 (что такое TOS и с чем его едят) - http://www.ietf.org/rfc/rfc1349.txt
Обязательно к прочтению (Policy Routing With Linux) - http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html
Guide to IP Layer Network Administration with Linux - http://www.linux-ip.net/html/
Команда ip на буржуйском от русского автора - http://www.linux-ip.net/gl/ip-cref/
Linux Advanced Routing & Traffic Control HOWTO - http://www.opennet.ru/docs/RUS/LARTC/index.html

 

 

оригинал тут http://www.k-max.name/linux/netfilter-iptables-v-linux/

Доброго времени, читатели и гости моего блога. C этой статьи начну серию статей о подсистеме Netfilter/iptables в Linux. В данной статье приведу основные понятия работы netfilter в Linux. Для понимания данной темы, обязательно советую ознакомиться со статьями Основные понятия сетей, Настройка сети в Linux, диагностика и мониторинг и Настройка и управление сетевой подсистемой Linux (iproute2).

 

Введение и история

 

Netfilter — межсетевой экран (он же, брандмауэр, он же файерволл, он же firewall...) встроен в ядро Linux с версии 2.4. Netfilter управляется утилитой iptables (Для IPv6 — ip6tables). До netfilter/iptables был Ipchains, который входил в состав ядер Linux 2.2. До ipchains в Linux был так называемый ipfw (IPV4 firewal), перенесенный из BSD. Утилита управления - ipfwadm. Проект netfilter/iptables был основан в 1998. Автором является Расти Расселл (он же руководил и прошлыми разработками). В 1999 г. образовалась команда Netfilter Core Team (сокращено coreteam). Разработанный межсетевой экран получил официальное название netfilter. В августе 2003 руководителем coreteam стал Харальд Вельте (Harald Welte).

 

Проекты ipchains и ipfwadm изменяли работу стека протоколов ядра Linux, поскольку до появления netfilter в архитектуре ядра не существовало возможностей для подключения дополнительных модулей управления пакетами. iptables сохранил основную идею ipfwadm — список правил, состоящих из критериев и действия, которое выполняется если пакет соответствует критериям. В ipchains была представлена новая концепция — возможность создавать новые цепочки правил и переход пакетов между цепочками, а в iptables концепция была расширена до четырёх таблиц (в современных netfilter - более четырех), разграничивающих цепочки правил по задачам: фильтрация, NAT, и модификация пакетов. Также iptables расширил возможности Linux в области определения состояний, позволяя создавать межсетевые экраны работающие на сеансовом уровне.

 

Архитектура Netfilter/iptables

 

Предварительные требования (с)

 

Как уже говорилось выше, для работы Netfilter необходимо ядро версии 2.6 (ну или хотя бы 2.3.15). Кроме того, при сборке и настройке ядра необходимо наличие настроек CONFIG_NETFILTER, CONFIG_IP_NF_IPTABLES, CONFIG_IP_NF_FILTER (таблица filter), CONFIG_IP_NF_NAT (таблица nat), CONFIG_BRIDGE_NETFILTER, а также многочисленные дополнительные модули: CONFIG_IP_NF_CONNTRACK (отслеживание соединений), CONFIG_IP_NF_FTP (вспомогательный модуль для отслеживания FTP соединений), CONFIG_IP_NF_MATCH_* (дополнительные типы шаблонов соответствия пакетов: LIMIT, MAC, MARK, MULTIPORT, TOS, TCPMSS, STATE, UNCLEAN, OWNER), CONFIG_IP_NF_TARGET_* (дополнительные действия в правилах: REJECT, MASQUERADE, REDIRECT, LOG, TCPMSS), CONFIG_IP_NF_COMPAT_IPCHAINS для совместимости с ipchains, CONFIG_BRIDGE_NF_EBTABLES и CONFIG_BRIDGE_EBT_* для работы в режиме моста, прочие CONFIG_IP_NF_* и CONFIG_IP6_NF_*. Полезно также указать CONFIG_PACKET.

 

Файлы в каталоге /proc, отображающие информацию о работе netfilter (о некоторых из них - ниже по тексту):

 

• /proc/net/ip_tables_names - список используемых таблиц
• /proc/net/ip_tables_targets - список используемых действий
• /proc/net/ip_tables_matches - список используемых протоколов
• /proc/net/nf_conntrack (или /proc/net/ip_conntrack) - список установленных соединений и их состояний
• /proc/sys/net/ipv4/netfilter/* - cодержит множество настроек системы conntrack, например:
• ip_conntrack_tcp_be_liberal
• 0 - все пакеты, не попадающие в окно, считаются INVALID
• 1 - только RST пакеты, не попадающие в окно, считаются INVALID (пришлось поставить)
• ip_conntrack_log_invalid - выводить в журнал INVALID пакеты
• ip_conntrack_tcp_loose - при "подхватывании" уже установленного соединения сколько пакетов требуется в обоих направлениях для подтверждения; если 0, то установленное соединение не подхватывается вовсе; по умолчанию - 3
• ip_conntrack_max_retrans - число повторных пакетов без подтверждения ACK, которое требуется для удаления соединения из таблицы после дополнительного ожидания ip_conntrack_timeout_max_retrans секунд; по умолчанию - 3

 

Функциональность netfilter может расширяться с помощью модулей ядра. Головной модуль ядра называется iptable_filter, модуль поддержки утилиты iptables называется ip_tables, вспомогательные модули обычно имеют префикс "ipt_" (например: ipt_state, ipt_REJECT, ipt_LOG; хотя - ip_conntrack/nf_conntrack). Большинство модулей загружается автомагически, но некоторые всё же приходиться загружать вручную (ip_conntrack_ftp - иначе может не работать в режиме Active; ip_conntrack_irc - иначе может не работать отсылка файлов по DCC; ip_nat_ftp; ip_nat_irc; ip_conntrack_tftp/nf_conntrack_tftp на клиенте - иначе не будет работать TFTP).

 

Схема работы

 Для начального понимания архитектуры Netfilter/iptables отлично подойдет иллюстрация из википедии, которую я несколько модифицировал для большей прозрачности и понимания материала:

 

 

 Ахтунг, ниже в трех абзацах изложена основная мысль статьи и принцип работы сетевого фильтра, поэтому желательно вчитаться как можно внимательнее!

 

Итак, давайте разберем данную схему работы netfilter. Сетевые пакеты поступают в сетевой интерфейс, настроенный на стек TCP/IP и после некоторых простых проверок ядром (например, контрольная сумма) проходят  последовательность цепочек (chain) (обозначены пунктиром). Пакет обязательно проходит первоначальную цепочку PREROUTING. После цепочки PREROUTING, в соответствии с таблицей маршрутизации, проверяется кому принадлежит пакет и, в зависимости от назначения пакета, определяется куда он дальше попадет (в какую цепочку). Если пакет НЕ адресован (в TCP пакете поле адрес получателя - НЕ локальная система) локальной системе, то он направляется в цепочку FORWARD, если пакет адресован локальной системе, то направляется в цепочку INPUT и после прохождения INPUT отдается локальным демонам/процессам. После обработки локальной программой, при необходимости формируется ответ. Ответный пакет пакет отправляемый локальной системой в соответствии с правилами маршрутизации направляется на соответствующий маршрут (хост из локальной сети или адрес маршрутизатора) и направляется в цепочку OUTPUT. После цепочки OUTPUT (или FORWARD, если пакет был проходящий) пакет снова сверяется с правилами маршрутизации и отправляется в цепочку POSTROUTING. Может возникнуть резонный вопрос: почему несколько раз пакет проходит через таблицу маршрутизации? (об этом - ниже).

 

Каждая цепочка, которую проходит пакет состоит из набора таблиц (table) (обозначены овалами). Таблицы в разных цепочках имеют одинаковое наименование, но тем не менее никак между собой не связаны. Например таблица nat в цепочке PREROUTING никак не связана с таблицей nat в цепочке POSTROUTING. Каждая таблица состоит из упорядоченного  набора (списка) правил. Каждое правило содержит условие, которому должен соответствовать проходящий пакет и действия к пакету, подходящему данному условию.

 

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

 

Очень часто о таблицах и цепочках говорят в плоскости "таблицы содержат  в себе наборы цепочек", но я считаю, что это неудобно и непонятно.

 

Цепочки netfilter:

 

• PREROUTING — для изначальной обработки входящих пакетов
• INPUT — для входящих пакетов, адресованных непосредственно локальному компьютеру
• FORWARD — для проходящих (маршрутизируемых) пакетов
• OUTPUT — для пакетов, создаваемых локальным компьютером (исходящих)
• POSTROUTING— для окончательной обработки исходящих пакетов
• Также можно создавать и уничтожать собственные цепочки при помощи утилиты iptables.

 

Цепочки организованны в 4 таблицы:

 

• raw — пакет проходит данную таблицу до передачи системе определения состояний. Используется редко, например для маркировки пакетов, которые НЕ должны обрабатываться системой определения состояний. Для этого в правиле указывается действие NOTRACK. Содержитcя в цепочках PREROUTING и OUTPUT.
• mangle — содержит правила модификации (обычно полей заголовка) IP‐пакетов. Среди прочего, поддерживает действия TTL, TOS, и MARK (для изменения полей TTL и TOS, и для изменения маркеров пакета). Редко необходима и может быть опасна. Содержится во всех пяти стандартных цепочках.
• nat — предназначена для подмены адреса отправителя или получателя. Данную таблицу проходят только первый пакет из потока, трансляция адресов или маскировка (подмена адреса отправителя или получателя) применяются ко всем последующим пакетам в потоке автоматически. Поддерживает действия DNAT, SNAT, MASQUERADE, REDIRECT. Содержится в цепочках PREROUTING, OUTPUT, и POSTROUTING.
• filter — основная таблица, используется по умолчанию если название таблицы не указано. Используется для фильтрации пакетов. Содержится в цепочках INPUT, FORWARD, и OUTPUT.

 

Как я уже отметил, непосредственно для фильтрации пакетов используются таблицЫ filter. Поэтому в рамках данной темы важно понимать, что для пакетов, предназначенных данному узлу необходимо модифицировать таблицу filter цепочки INPUT, для проходящих пакетов — цепочки FORWARD, для пакетов, созданных данным узлом — OUTPUT.

 

Примеры прохождения цепочек

 

Последовательность обработки входящего пакета, предназначенного для локального процесса:

 

1. Просматривается цепочка PREROUTING
1. Просматривается таблица raw
2. Просматривается  таблица mangle, далее происходит отслеживание соединений
3. Просматривается таблица nat (используется для DNAT - модификация адреса получателя)
2. маршрутизация: если пакет надо маршрутизовать мимо локального хоста, то переходим к обработке проходящего пакета, если для он предназначен локальному хосту, то обрабатывается как локальный
3. Просматривается цепочка INPUT 
1. Просматривается таблица mangle
2. Просматривается таблица filter

 

Последовательность обработки пакета, уходящего с нашего хоста:

 

1. Маршрутизация: определение исходящего адреса, адреса назначения, используемого интерфейса; если пакет маршрутизируется внутрь, то переходим к предыдущей процедуре
2. Просматривается цепочка OUTPUT
1. Просматривается таблица raw
2. Просматривается таблица mangle, фильтровать здесь не стоит, здесь же происходит отслеживание локально создаваемых соединений
3. Просматривается таблица nat (NAT для локально сгенерированных пакетов)
4. Просматривается таблица filter
3. Повторная маршрутизация, т.к. в таблицах mangle и nat пакет мог быть изменён; если пакет маршрутизируется внутрь, то переходим к предыдущей процедуре
4. Просматривается цепочка POSTROUTING 
1. Просматривается таблица mangle
2. Просматривается таблица nat (используется для SNAT - модификация адреса источника, фильтровать здесь не стоит)

 

Последовательность обработки проходящего пакета (начинается от п.2 первой процедуры):

 

1. Просматривается цепочка FORWARD
1. Просматривается таблица mangle
2. Просматривается таблица filter
2. повторная маршрутизация, т.к. в таблице mangle пакет мог быть изменён; если пакет маршрутизируется внутрь, то переходим к первой процедуре
3. Просматривается цепочка POSTROUTING
1. Просматривается таблица mangle
2. Просматривается таблица nat (используется для SNAT и Masquerading, фильтровать здесь не стоит)

 

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

 

Механизм определения состояний (conntrack)

 

Выше в тексте несколько раз указывалось понятие "определение состояний", оно заслуживает отдельной темы для обсуждения, но тем не менее я кратко затрону данный вопрос в текущем посте. В общем, механизм определения состояний (он же state machine, он же connection tracking, он же conntrack) является частью пакетного фильтра и позволяет определить определить к какому соединению/сеансу принадлежит пакет. Conntrack анализирует состояние всех пакетов, кроме тех, которые помечены как NOTRACK в таблице raw. На основе этого состояния определяется принадлежит пакет новому соединению (состояние NEW), уже установленному соединению (состояние ESTABLISHED), дополнительному к уже существующему (RELATED), либо к "другому" (неопределяемому) соединению (состояние INVALID). Состояние пакета определяется на основе анализа заголовков передаваемого TCP-пакета. Модуль conntrack позволяет реализовать межсетевой экран сеансового уровня (пятого уровня модели OSI). Для управления данным механизмом используется утилита conntrack, а так же параметр утилиты iptables: -m conntrack или -m state (устарел). Состояния текущих соединений conntrack хранит в ядре. Их можно просмотреть в файле /proc/net/nf_conntrack (или /proc/net/ip_conntrack).

 

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

 

Управление правилами сетевой фильтрации Netfilter (использование команды iptables)

 

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

 

В общем случае формат команды следующий:

 

iptables [-t таблица] команда [критерии] [действие]

 

Все параметры в квадратных скобках - необязательны. По умолчанию используется таблица filter, если же необходимо указать другую таблицу, то следует использовать ключ -t с указанием имени таблицы. После имени таблицы указывается команда, определяющая действие (например: вставить правило, или добавить правило в конец цепочки, или удалить правило). "критерии" задает параметры отбора. "действие" указывает, какое действие должно быть выполнено при условии совпадения критериев отбора в правиле (например: передать пакет в другую цепочку правил, "сбросить" пакет, выдать на источник сообщение об ошибке...).

 

Ниже приведены команды и параметры утилиты iptables:

 

Параметр	Описание	Пример
Команды
--append (-A)	Добавить в указанную цепочку и указанную таблицу заданное правило в КОНЕЦ списка.	iptables -A FORWARD критерии -j действие
--delete (-D)	Удаляет заданное номером(ами) или правилом(ами) правило(а). Первый пример удаляет все правила с номерами 10,12 во всех цепочках, в таблицах filter, второй пример удаляет заданное правило из таблицы mangle в цепочке PREROUTING.	iptables -D 10,12 iptables -t mangle -D PREROUTING критерии -j действие
--rename-chain (-E)	Изменить имя цепочки.	iptables -E OLD_CHAIN NEW_CHAIN
--flush (-F)	Очистка всех правил текущей таблицы. Ко всем пакетам, которые относятся к уже установленным соединениям, применяем терминальное действие ACCEPT — пропустить	iptables -F
--insert (-I)	Вставляет заданное правило в место, заданное номером.	iptables -I FORWARD 5 критерии -j действие
--list (сокр. -L)	Просмотр существующих правил (без явного указания таблицы - отображается таблица filter всех цепочек).	iptables -L
--policy (-P)	Устанавливает стандартную политику для заданной цепочки.	iptables -t mangle -P PREROUTING DROP
--replace (-R)	Заменяет заданное номером правило на заданное в критериях.	iptables -R POSROUTING 7 | критерии -j действие
--delete-chain (-X)	Удалить ВСЕ созданные вручную цепочки (оставить только стандартные INPUT, OUTPUT, FORWARD, PREROUTING и POSTROUTING).	iptables -X
--zero (-Z)	Обнуляет счетчики переданных данных в цепочке.	iptables -Z INPUT
Параметры
--numeric (-n)	Не резолвит адреса и протоколы при выводе.
--line-numbers	Указывать номера правил при выводе (может использоваться совместно с -L).	iptables -L --line-numbers
--help (-h)	куда же без нее
-t таблица	Задает название таблицы, над которой необходимо совершить действие. В примере сбрасывается таблица nat во всех цепочках.	iptables -t nat -F
--verbose (-v)	Детальный вывод.	iptables -L -v

 

Критерии (параметры) отбора сетевых пакетов команды iptables

 

Критерии отбора сетевых пакетов негласно делятся на несколько групп: Общие критерии, Неявные критерии, Явные критерии. Общие критерии допустимо употреблять в любых правилах, они не зависят от типа протокола и не требуют подгрузки модулей расширения. Неявные критерии (я бы из назвал необщие),  те критерии, которые подгружаются неявно и становятся доступны, например при указании общего критерия --protocol tcp|udp|icmp. Перед использованием Явных критериев, необходимо подключить дополнительное расширение (это своеобразные плагины для netfilter). Дополнительные расширения подгружаются с помощью параметра -m или --match. Так, например, если мы собираемся использовать критерии state, то мы должны явно указать это в строке правила: -m state левее используемого критерия. Отличие между явными и неявными необщими критериями заключается в том, что явные нужно подгружать явно, а неявные подгружаются автоматически.

 

Во всех критериях можно использовать знак ! перед значением критерия. Это будет означать, что под данное правило подпадают все пакеты, которые не соответствуют данному параметру. Например: критерий --protocol ! tcp будет обозначать, что все пакеты, которые не являются TCP-протоколом подходят под действие правила. Однако последние версии iptables (в частности, 1.4.3.2 и выше), уже не поддерживают этот синтаксис и требуют использования не --protocol ! tcp, а ! --protocol tcp,  выдавая следующую ошибку:

 

Using intrapositioned negation (`--option ! this`) is deprecated in favor of extrapositioned (`! --option this`).

 

Ниже в виде таблицы приведены часто используемые параметры отбора пакетов:

 

Параметр	Описание	Пример
Общие параметры
--protocol (сокр. -p)	Определяет протокол транспортного уровня. Опции tcp, udp, icmp, all или любой другой протокол определенный в /etc/protocols	iptables -A INPUT -p tcp
--source (-s, --src)	IP адрес источника пакета. Может быть определен несколькими путями: Одиночный хост: host.domain.tld, или IP адрес: 10.10.10.3 Пул-адресов (подсеть): 10.10.10.3/24 или 10.10.10.3/255.255.255.0 Настойчиво не рекомендуется использовать доменные имена, для разрешения (резольва) которых требуются DNS-запросы, так как на этапе конфигурирования netfilter DNS может работать некорректно. Также, заметим, имена резольвятся всего один раз — при добавлении правила в цепочку. Впоследствии соответствующий этому имени IP-адрес может измениться, но на уже записанные правила это никак не повлияет (в них останется старый адрес). Если указать доменное имя, которое резольвится в несколько IP-адресов, то для каждого адреса будет добавлено отдельное правило.	iptables -A INPUT -s 10.10.10.3
--destination (-d)	IP адрес назначения пакета. Может быть определен несколькими путями (см. --source).	iptables -A INPUT --destination 192.168.1.0/24
--in-interface (-i)	Определяет интерфейс, на который прибыл пакет. Полезно для NAT и машин с несколькими сетевыми интерфейсами. Применяется в цепочках INPUT, FORWARD и PREROUTING. Возможно использование знака "+", тогда подразумевается использование всех интерфейсов, начинающихся на имя+ (например eth+ - все интерфейсы eth).	iptables -t nat -A PREROUTING --in-interface eth0
--out-interface (-o)	Определяет интерфейс, с которого уйдет пакет. Полезно для NAT и машин с несколькими сетевыми интерфейсами. Применяется в цепочках OUTPUT, FORWARD и POSTROUTING. Возможно использование знака "+".	iptables -t nat -A POSTROUTING --in-interface eth1
Неявные (необщие) параметры
-p proto -h	вывод справки по неявным параметрам протокола proto.	iptables -p icmp -h
--source-port (--sport)	Порт источник, возможно только для протоколов --protocol tcp, или --protocol udp	iptables -A INPUT --protocol tcp --source-port 25
--destination-port (--dport)	Порт назначения, возможно только для протоколов --protocol tcp, или --protemocol udp	iptables -A INPUT --protocol udp --destination-port 67
Явные параметры
-m state --state (устарел) он же -m conntrack --ctstate	Состояние соединения. Доступные опции: NEW (Все пакеты устанавливающие новое соединение) ESTABLISHED (Все пакеты, принадлежащие установленному соединению) RELATED (Пакеты, не принадлежащие установленному соединению, но связанные с ним. Например - FTP в активном режиме использует разные соединения для передачи данных. Эти соединения связаны.) INVALID (Пакеты, которые не могут быть по тем или иным причинам идентифицированы. Например, ICMP ошибки не принадлежащие существующим соединениям) и др. (более подробно в документации)	iptables -A INPUT -m state --state NEW,ESTABLISHEDiptables -A INPUT -m conntrack --ctstate NEW,ESTABLISHED
-m mac --mac-source	Задает MAC адрес сетевого узла, передавшего пакет. MAC адрес должен указываться в форме XX:XX:XX:XX:XX:XX.	-m mac --mac-source 00:00:00:00:00:0

 

Действия над пакетами

 

Данный заголовок правильнее будет перефразировать в "Действия над пакетами, которые совпали с критериями отбора". Итак, для совершения какого-либо действия над пакетами, необходимо задать ключ -j (--jump) и указать, какое конкретно действие совершить.

 

Действия над пакетами могут принимать следующие значения:

 

• ACCEPT - пакет покидает данную цепочку и передается в следующую (дословно - ПРИНЯТЬ).
• DROP - отбросить удовлетворяющий условию пакет, при этом пакет не передается в другие таблицы/цепочки.
• REJECT - отбросить пакет, отправив отправителю ICMP-сообщение, при этом пакет не передается в другие таблицы/цепочки.
• RETURN - возвратить пакет в предыдущую цепочку и продолжить ее прохождение начиная со следующего правила.
• SNAT - применить трансляцию адреса источника в пакете. Может использоваться только в цепочках POSTROUTING и OUTPUT в таблицах nat.
• DNAT - применить трансляцию адреса назначения в пакете. Может использоваться в цепочке PREROUTING в таблице nat. (в исключительных случаях - в цепочке OUTPUT)
• LOG - протоколировать пакет (отправляется демону syslog) и обработать остальными правилами.
• MASQUERADE — используется вместо SNAT при наличии соединения с динамическим IP (допускается указывать только в цепочке POSTROUTING таблицы nat).
• MARK — используется для установки меток на пакеты, передается для обработки дальнейшим правилам.
• и др.

 

Кроме указанных действий, существуют и другие, с которыми можно ознакомиться в документации (возможно, в скором времени я дополню статью в ходе освоения темы). У некоторых действий есть дополнительные параметры.

 

В таблице ниже приведены примеры и описания дополнительных параметров:

 

Параметр	Описание	Пример
DNAT (Destination Network Address Translation)
--to-destination	указывает, какой IP адрес должен быть подставлен в качестве адреса места назначения. В примере во всех пакетах протокола tcp, пришедших на адрес 1.2.3.4, данный адрес будет заменен на 4.3.2.1.	iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 -j DNAT --to-destination 4.3.2.1
LOG
--log-level	Используется для задания уровня журналирования (log level). В примере установлен максимальный уровень логирования для всех tcp пакетов в таблице filter цепочки FORWARD.	iptables -A FORWARD -p tcp -j LOG --log-level debug
--log-prefix	Задает текст (префикс), которым будут предваряться все сообщения iptables. (очень удобно для дальнейшего парсинга) Префикс может содержать до 29 символов, включая и пробелы. В примере отправляются в syslog все tcp пакеты в таблице filter цепочки INPUT с префиксом INRUT-filter.	iptables -A INPUT -p tcp -j LOG --log-prefix "INRUT-filter"
--log-ip-options	Позволяет заносить в системный журнал различные сведения из заголовка IP пакета.	iptables -A FORWARD -p tcp -j LOG --log-ip-options
и др...

 

На этом закончим теорию о сетевом фильтре netfilter/iptables. В следующей статье я приведу практические примеры для усвоения данной теории.

 

Резюме

 

В данной статье мы рассмотрели очень кратко основные понятия сетевого фильтра в Linux. Итак, подсистема netfilter/iptables является частью ядра Linux и используется для организации различных схем фильтрации и манипуляции с сетевыми пакетами. При этом, каждый пакет проходит от сетевого интерфейса, в который он прибыл и далее по определенному маршруту цепочек, в зависимости от того, предназначен он локальной системе или "нелокальной". Каждая цепочка состоит из набора таблиц, содержащих последовательный набор правил. Каждое правило состоит из определенного критерия/критериев отбора сетевого пакета и какого-то действия с пакетом, соответствующего данным критериям. В соответствии с заданными правилами над пакетом может быть совершено какое-либо действие (Например, передача следующей/другой цепочке, сброс пакета, модификация содержимого или заголовков и др.).  Каждая цепочка и каждая таблица имеет свое назначение, функциональность и место в пути следования пакета. Например для фильтрации пакетов используется таблица filter, которая содержится в трех стандартных цепочках и может содержаться в цепочках, заданных пользователем. Завершается путь пакета либо в выходящем сетевом интерфейсе, либо доставкой локальному процессу/приложению.

 

Литература

 

Довольно много интересной информации на русском содержится тут:

 

• http://www.opennet.ru/docs/RUS/iptables/
• http://ru.wikibooks.org/wiki/Iptables

 

Более глубоко материал доступен на буржуйском вот тут:

 

• http://www.frozentux.net/documents/ipsysctl-tutorial/
• http://www.netfilter.org/documentation/index.html

оригинал тут http://www.k-max.name/linux/iptables-v-primerax/

Настройка netfilter/iptables для рабочей станции

 

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

 

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

 

netfilter:~# iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

 

Chain FORWARD (policy ACCEPT)

target prot opt source destination

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

 

Это значит, что политика по умолчанию для таблицы filter во всех цепочках - ACCEPT и нет никаких других правил, что-либо запрещающих. Поэтому давайте сначала запретим ВСЁ входящие, исходящие и проходящие пакеты (не вздумайте это делать удаленно-тут же потеряете доступ):

 

netfilter:~# iptables -P INPUT DROP

netfilter:~# iptables -P OUTPUT DROP

netfilter:~# iptables -P FORWARD DROP

 

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

 

netfilter:~# ping -c2 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

 

--- localhost ping statistics ---

2 packets transmitted, 0 received, 100% packet loss, time 1004ms

 

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

 

netfilter:~# iptables -A INPUT -i lo -j ACCEPT 

netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT

 

После этого пинг на локалхост заработает:

 

netfilter:~# ping -c1 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

64 bytes from 127.0.0.1 (127.0.0.1): icmp_seq=1 ttl=64 time=0.116 ms

 

--- 127.0.0.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 116ms

rtt min/avg/max/mdev = 0.116/0.116/0.116/0.116 ms

 

Если подходить к настройке файервола не шибко фанатично, то можно разрешить работу протокола ICMP:

 

netfilter:~# iptables -A INPUT -p icmp -j ACCEPT

netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT

 

Более безопасно будет указать следующую аналогичную команду iptables:

 

netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT

netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT

netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT

 

Данная команда разрешит типы ICMP пакета эхо-запрос и эхо-ответ, что повысит безопасность.

 

Зная, что наш комп не заражен (ведь это так?) и он устанавливает только безопасные исходящие соединения. А так же, зная, что безопасные соединения - это соединения из т.н. эфимерного диапазона портов, который задается ядром в файле /proc/sys/net/ipv4/ip_local_port_range, можно разрешить исходящие соединения с этих безопасных портов:

 

netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range

32768 61000

netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT

netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT

 

Если подходить к ограничению исходящих пакетов не параноидально, то можно было ограничиться одной командой iptables, разрешающей все исхолящие соединения оп всем протоколам и портам:

 

netfilter:~# iptables -A OUTPUT -j ACCEPT

netfilter:~# # или просто задать политику по умолчанию ACCEPT для цепочки OUTPUT

netfilter:~# iptables -P OUTPUT ACCEPT

 

Далее, зная что в netfilter сетевые соединения имеют 4 состояния (NEW, ESTABLISHED, RELATED и INVALID) и новые исходящие соединения с локального компьютера (с состоянием NEW) у нас разрешены в прошлых двух командах iptables, что уже установленные соединения и дополнительные имеют состояния ESTABLISHED и RELATED, соответственно, а так же зная, что входящие соединения к локальной системе приходят через цепочку INPUT, можно разрешить попадание на наш компьютер только тех TCP- и UDP-пакетов, которые были запрошены локальными приложениями:

 

netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

 

Это собственно, все! Если на десктопе все же работает какая-то сетевая служба, то необходимо добавить соответствующие правила для входящих соединений и для исходящих. Например, для работы ssh-сервера, который принимает и отправляет запросы на 22 TCP-порту, необходимо добавить следующие iptables-правила:

 

netfilter:~# iptables -A INPUT -i eth0 -p TCP --dport 22 -j ACCEPT 

netfilter:~# iptables -A OUTPUT -o eth0 -p TCP --sport 22 -j ACCEPT

 

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

 

Настройка netfilter/iptables для подключения нескольких клиентов к одному соединению.

 

Давайте теперь рассмотрим наш Linux в качестве шлюза для локальной сети во внешнюю сеть Internet. Предположим, что интерфейс eth0 подключен к интернету и имеет IP 198.166.0.200, а интерфейс eth1 подключен к локальной сети и имеет IP 10.0.0.1. По умолчанию, в ядре Linux пересылка пакетов через цепочку FORWARD (пакетов, не предназначенных локальной системе) отключена. Чтобы включить данную функцию, необходимо задать значение 1 в файле /proc/sys/net/ipv4/ip_forward:

 

netfilter:~# echo 1 > /proc/sys/net/ipv4/ip_forward

 

Чтобы форвардинг пакетов сохранился после перезагрузки, необходимо в файле /etc/sysctl.conf раскомментировать (или просто добавить) строку net.ipv4.ip_forward=1.

 

Итак, у нас есть внешний адрес (198.166.0.200), в локальной сети имеется некоторое количество гипотетических клиентов, которые имеют адреса из диапазона локальной сети и посылают запросы во внешнюю сеть. Если эти клиенты будут отправлять во внешнюю сеть запросы через шлюз "как есть", без преобразования, то удаленный сервер не сможет на них ответить, т.к. обратным адресом будет получатель из "локальной сети". Для того, чтобы эта схема корректно работала, необходимо подменять адрес отправителя, на внешний адрес шлюза Linux. Это достигается за счет действия MASQUERADE (маскарадинг) в цепочке POSTROUTING, в таблице nat.

 

netfilter:~# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

netfilter:~# iptables -A FORWARD -m conntrack --ctstate NEW -i eth1 -s 10.0.0.1/24 -j ACCEPT

netfilter:~# iptables -P FORWARD DROP

netfilter:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

 

Итак, по порядку сверху-вниз мы разрешаем уже установленные соединения в цепочке FORWARD, таблице filter, далее мы разрешаем устанавливать новые соединения в цепочке FORWARD, таблице filter, которые пришли с интерфейса eth1 и из сети 10.0.0.1/24. Все остальные пакеты, которые проходят через цепочку FORWARD - отбрасывать. Далее, выполняем маскирование (подмену адреса отправителя пакета в заголовках) всех пакетов, исходящих с интерфейса eth0.

 

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

 

netfilter:~# iptables -P INPUT DROP

netfilter:~# iptables -P OUTPUT DROP

netfilter:~# iptables -A INPUT -i lo -j ACCEPT 

netfilter:~# iptables -A OUTPUT -o lo -j ACCEPT

netfilter:~# iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT

netfilter:~# iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT

netfilter:~# iptables -A OUTPUT -p icmp -j ACCEPT

netfilter:~# cat /proc/sys/net/ipv4/ip_local_port_range

32768 61000

netfilter:~# iptables -A OUTPUT -p TCP --sport 32768:61000 -j ACCEPT

netfilter:~# iptables -A OUTPUT -p UDP --sport 32768:61000 -j ACCEPT

netfilter:~# iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

netfilter:~# iptables -A INPUT -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT

 

В результате, если один из хостов локальной сети, например 10.0.0.2, попытается связаться с одним из интернет-хостов, например, 93.158.134.3 (ya.ru), при проходе его пакетов через шлюз, их исходный адрес будет подменяться на внешний адрес шлюза в цепочке POSTROUTING таблице nat, то есть исходящий IP  10.0.0.2 будет заменен на 198.166.0.200. С точки зрения удаленного хоста (ya.ru), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 198.166.0.200. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 10.0.0.2, после чего пакеты будут передаваться настоящему получателю в локальной сети. Для такого обратного преобразования никаких дополнительных правил указывать не нужно — это будет делать все та же операция MASQUERADE, которая помнит какой хост из локальной сети отправил запрос и какому хосту необходимо вернуть пришедший ответ.

 

Примечание: желательно негласно принято, перед всеми командами iptables очищать цепочки, в которые будут добавляться правила:

 

netfilter:~# iptables -F ИМЯ_ЦЕПОЧКИ

 

Предоставление доступа к сервисам на шлюзе

 

Предположим, что на нашем шлюзе запущен некий сервис, который должен отвечать на запросы поступающие из сети интернет. Допустим он работает на некотором TCP порту nn. Чтобы предоставить доступ к данной службе, необходимо модифицировать таблицу filter в цепочке INPUT (для возможности получения сетевых пакетов, адресованных локальному сервису) и таблицу filter в цепочке OUTPUT (для разрешения ответов на пришедшие запросы).

 

Итак, мы имеем настроенный шлюз, который маскарадит (заменяет адрес отправителя на врешний) пакеты во внешнюю сеть. И разрешает принимать все установленные соединения. Предоставление доступа к сервису будет осуществляться с помощью следующих разрешающих правил:

 

netfilter:~# iptables -A INPUT -p TCP --dport nn -j ACCEPT 

netfilter:~# iptables -A OUTPUT -p TCP --sport nn -j ACCEPT

 

Данные правила разрешают входящие соединения по протоколу tcp на порт nn и исходящие соединения по протоколу tcp с порта nn. Кроме этого, можно добавить дополнительные ограничивающие параметры, например разрешить входящие соединения только с внешнего интерфейса eth0 (ключ -i eth0) и т.п.

 

Предоставление доступа к сервисам в локальной сети

 

Предположим, что в нашей локальной сети имеется какой-то хост с IP X.Y.Z.1, который должен отвечать на сетевые запросы из внешней сети на TCP-порту xxx. Для того чтобы при обращении удаленного клиента ко внешнему IP на порт xxx происходил корректный ответ сервиса из локальной сети, необходимо направить запросы, приходящие на внешний IP порт xxx на соответствующий хост в локальной сети. Это достигается модификацией адреса получателя в пакете, приходящем на указанный порт. Это действие называется DNAT и применяется в цепочке PREROUTING в таблице nat. А так же разрешить прохождение данный пакетов в цепочке FORWARD в таблице filter.

 

Опять же, пойдем по пути прошлого раздела. Итак, мы имеем настроенный шлюз, который маскарадит (заменяет адрес отправителя на врешний) пакеты во внешнюю сеть. И разрешает принимать все установленные соединения. Предоставление доступа к сервису будет осуществляться с помощью следующих разрешающих правил:

 

netfilter:~# iptables -t nat -A PREROUTING -p tcp -d 198.166.0.200 --dport xxx -j DNAT --to-destination X.Y.Z.1

netfilter:~# iptables -A FORWARD -i eth0 -p tcp -d X.Y.Z.1 --dport xxx -j ACCEPT

 

Сохранение введенных правил при перезагрузке

 

Все введенные в консоли правила - после перезагрузки ОС будут сброшены в первоначальное состояние (читай - удалены). Для того чтобы сохранить все введенные команды iptables, существует несколько путей. Например, один из них - задать все правила брандмауэра в файле инициализации rc.local. Но у данного способа есть существенный недостаток: весь промежуток времени с запуска сетевой подсистемы, до запуска последней службы и далее скрипта rc.local из SystemV операционная система будет не защищена. Представьте ситуацию, например, если какая-нибудь служба (например NFS) стартует последней и при ее запуске произойдет какой-либо сбой и до запуска скрипта rc.local. Соответственно, rc.local так и не запуститься, а наша система превращается в одну большую дыру.

 

Поэтому самой лучшей идеей будет инициализировать правила netfilter/iptables при загрузке сетевой подсистемы. Для этого в Debian есть отличный инструмент - каталог /etc/network/if-up.d/, в  который можно поместить скрипты, которые будут запускаться при старте сети. А так же есть команды iptables-save и iptables-restore, которые сохраняют создают дамп правил netfilter из ядра на стандартный вывод и восстанавливают в ядро правила со стандартного ввода соответственно.

 

Итак, алгоритм сохранения iptables примерно следующий:

 

• Настраиваем сетевой экран под свои нужны с помощью команды iptables
• создаем дамп созданный правил с помощью команды iptables-save > /etc/iptables.rules
• создаем скрипт импорта созданного дампа при старте сети (в каталоге /etc/network/if-up.d/) и не забываем его сделать исполняемым:

 

# cat /etc/network/if-up.d/firewall

#!/bin/bash

/sbin/iptables-restore < /etc/iptables.rules

exit 0

# chmod +x /etc/network/if-pre-up.d/firewall

 

Дамп правил, полученный командой iptables-save имеет текстовый формат, соответственно пригоден для редактирования. Синтаксис вывода команды iptables-save следующий:

 

# Generated by iptables-save v1.4.5 on Sat Dec 24 22:35:13 2011

*filter

:INPUT ACCEPT [0:0] 

:FORWARD ACCEPT [0:0]

.......

# комментарий

-A INPUT -i lo -j ACCEPT

-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

...........

-A FORWARD -j REJECT

COMMIT

# Completed on Sat Dec 24 22:35:13 2011

# Generated by iptables-save v1.4.5 on Sat Dec 24 22:35:13 2011

*raw

......

COMMIT

 

Строки, начинающиеся на # - комментарии, строки на * - это название таблиц, между названием таблицы и словом COMMIT содержатся параметры, передаваемые команде iptables. Параметр COMMIT - указывает на завершение параметров для вышеназванной таблицы. Строки, начинающиеся на двоеточие задают цепочки, в которых содержится данная таблица в формате:

 

:цепочка политика [пакеты:байты]

 

где цепочка - имя цепочки, политика - политика цепочки по-умолчанию для данной таблицы, а далее счетчики пакетов и байтов на момент выполнения команды.

 

В RedHat функции хранения команд iptables выполняемых при старте и останове сети выполняет файл /etc/sysconfig/iptables. А управление данным файлом лежит на демоне iptables.

 

Как еще один вариант сохранения правил, можно рассмотреть использование параметра up в файле /etc/network/interfaces с аргументом в виде файла, хранящего команды iptables, задающие необходимые правила.

 

Итог

 

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

оригинал тут http://www.k-max.name/linux/nastrojka-i-upravlenie-setevoj-podsistemoj-linux-paket-iproute2/

 

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

 

 

 

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

 

 

 

В старых версиях ядер Linux (2.4 и ниже) существовали инструменты настройки сети из пакета net-tools, которые включали в себя такие команды, как ifconfig - для управления сетевыми интерфейсами, route - управление таблицей маршрутизации, arp - управление таблицей разрешения имен, netstat - сетевая статистика, mii-tool - статус сетевых устройств и др. В дистрибутивах, использующих современные ядра внедряется пакет iproute2 (иногда называется iproute) и net-tools оставлен, как некоторые утверждают, для совместимости. В пакет iproute входят 3 основных утилиты: ip - команда для просмотра параметров и настройки сетевых интерфейсов, IP-адресов, таблиц маршрутизации, правил маршрутизации, таблиц ARP преобразования, IP-туннелей и т.д. tc (traffic control) - команда для просмотра и настройки параметров управления трафиком (классификация трафика, дисциплины управления очереди для различных классов трафика), ss - команда для просмотра текущих соединений и открытых портов (аналог netstat).

 

 

 

Управление сетевыми интерфейсами в Linux

 

 

 

Сетевые интерфейсы в линух представляют собой физические устройства, которые взаимодействуют с ядром, а деле и с пользователем через соответствующий драйвер (например Ethernet-драйвера именуют интерфейсы как eth0, eth1 ...). Чтобы сетевой интерфейс функционировал, на нем нужно задать настройки какого-либо протокола сетевого уровня (IP, IPX или др.). В современных сетях используется протокол IP. Для управления сетью используется команда ip. Давайте рассмотрим общие параметры команды ip, данные параметры отлично иллюстрирует википедия:

 

 

 

 

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

 

 

 

Давайте разберем некоторые аспекты данных команд. Начнем с аналога команды ifconfig - команда ip с параметром link управляет свойствами сетевого интерфейса: 

 

 

 

[proxy ~]# ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN

        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP

        qlen 1000 link/ether 00:1d:72:01:ab:93 brd ff:ff:ff:ff:ff:ff

3: irda0: <NOARP> mtu 2048 qdisc noop state DOWN qlen 8

        link/irda 00:00:00:00 brd ff:ff:ff:ff

4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000

        link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff

5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3

        link/ppp

 

 

Вывод данной команды содержит пронумерованный список интерфейсов, присутствующих в системе. Информация об интерфейсе содержит две строки: в первой указывается имя интерфейса (lo, eth0 и др.), установленные флаги состояния (в фигурных скобках < и >), MTU (Maximum Transmission Unit, максимально допустимый размер фрейма в байтах), тип и размер очереди фреймов; во второй строке — тип соединения, MAC-адрес, широковещательный адрес и т. п.

 

 

 

Некоторые флаги состояния:

 

 

 

• UP — устройство подключено и готово принимать и отправлять фреймы;
• LOOPBACK — интерфейс является локальным и не может взаимодействовать с другими узлами в сети;
• BROADCAST - устройство способно отправлять широковещательные фреймы;
• POINTTOPOINT — соединение типа "точка-точка"
• PROMISC — устройство находится в режиме "прослушивания" и принимает все фреймы.
• NOARP — отключена поддержка разрешения имен сетевого уровня.
• ALLMULTI — устройство принимает все групповые пакеты.
• NO-CARRIER — нет связи (не подключен кабель).
• DOWN — устройство отключено.

 

 

 

Можно также вывести информацию о выбранном интерфейсе, задав его имя в параметре dev:

 

 

 

[proxy ~]# ip link show dev eth0

 

 

 

или просто:

 

 

 

[proxy ~]# ip link show eth0

 

 

 

Команда ip link также позволяет изменять свойства сетевого интерфейса. Для этого используется параметр set:

 

 

 

iproute:~# ip link show dev eth2

3: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000

    link/ether 08:00:27:c9:00:f0 brd ff:ff:ff:ff:ff:ff

iproute:~# # установка значения MTU

iproute:~# ip link set mtu 1400 eth2

iproute:~# # установка MAC адреса

iproute:~# ip link set address 00:11:11:12:FE:09 eth2

iproute:~# # "поднятие" интерфейса

iproute:~# ip link set up eth2

iproute:~# ip link show dev eth2

3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP qlen 1000

    link/ether 00:11:11:12:fe:09 brd ff:ff:ff:ff:ff:ff

iproute:~# # отключение интерфейса

iproute:~# ip link set down eth2

iproute:~# ip link show dev eth2

3: eth2: <BROADCAST,MULTICAST> mtu 1400 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 00:11:11:12:fe:09 brd ff:ff:ff:ff:ff:ff

 

 

 

Указанные тут команды являются аналогами "классических" команд из пакета  net-tools:

 

 

 

# ifconfig eth2 mtu 1400

# ifconfig eth2 hw ether 00:11:12:13:14:15

# ifconfig eth2 up

# ifconfig eth2 down

 

 

 

Управление физическими параметрами интерфейса

 

 

 

Физические параметры (скорость, технология Ethernet, тип дуплекса) сетевого подключения зависят от используемого оборудования и обычно настраиваются автоматически при подключении компьютера к сети. Но иногда из- за несогласованной работы оборудования и драйверов адаптера параметры необходимо выставить вручную, используя утилиту ethtool. Данная утилита включена в стандартные репозитории Debian и устанавливается из пакетного менеджера. Пример использования утилиты:

 

 

 

iproute:~# ethtool eth2

Settings for eth2:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 1000Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 0

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: Unknown

        Supports Wake-on: umbg

        Wake-on: d

        Current message level: 0x00000007 (7)

        Link detected: no

iproute:~# ethtool -i eth2

driver: e1000

version: 7.3.21-k5-NAPI

firmware-version: N/A

bus-info: 0000:00:08.0

 

 

 

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

 

 

 

Напомню, что протокол IP является маршрутизируемым протоколом без установления соединения. IP адрес представляет собой комбинацию номера сети и номера узла в данной сети. Количество бит, используемых для номера сети определяется по классу адреса или задается маской подсети. Итого, как я уже говорил, чтобы сетевой интерфейс начал функционировать в соответствии со своим прямым назначением, необходимо на нем задать параметры соответствующего сетевого протокола. Для протокола IP минимально необходимые параметры - это IP адрес и маска подсети. Для настройки параметров протокола IP на сетевом интерфейсе с помощью командной строки необходимо использовать команду ip address (она же ip addr).

 

 

 

user@nout:~$ ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000

    link/ether 00:25:d3:3f:3e:87 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.148/24 brd 192.168.1.255 scope global wlan0

    inet6 fe80::225:d3ff:fe3f:3e87/64 scope link

       valid_lft forever preferred_lft forever

 

 

 

Параметр show отображает текущую конфигурацию. Каждая запись о сетевом адресе может содержать информацию о типе адреса (inet — адрес IPv4, inet6 — IPv6 и т. д.), непосредственно адрес, маску подсети (количество сетевых бит), широковещательный адрес данной сети, область видимости (scope global — действителен везде, scope link — только для данного устройства, scope host — для данного узла, доступные области приведены в /etc/iproute2/rt_scopes) и имя логического интерфейса.

 

 

 

user@nout:~$ # добавление адреса выполняется параметром add

user@nout:~$ # при этом необходимо задать широковещательный адреc

user@nout:~$ # (параметр brd + задает автоматический рассчет широковещательного адреса)

user@nout:~$ # данная операция требует прав суперпользователя

user@nout:~$ ip address add 192.168.1.3/25 brd + dev eth0

RTNETLINK answers: Operation not permitted

user@nout:~$ sudo -s

[sudo] password for user:

nout:~# ip address add 192.168.1.3/25 brd + dev eth0

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.3/25 brd 192.168.1.127 scope global eth0

nout:~# # удаление адреса производится параметром del

nout:~# ip address del 192.168.1.3/25 dev eth0

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

 

 

 

C помощью ip можно задать несколько IP адресов на одном интерфейсе:

 

 

 

nout:~# ip address add 192.168.1.11/25 brd + dev eth0

nout:~# ip address add 192.168.1.12/25 brd + dev eth0

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.11/25 brd 192.168.1.127 scope global eth0

    inet 192.168.1.12/25 brd 192.168.1.127 scope global secondary eth0

nout:~# ip address del 192.168.1.11/25 dev eth0

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

nout:~# ip address add 192.168.1.12/25 brd + dev eth0

nout:~# ip address add 192.168.1.212/25 brd + dev eth0

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.12/25 brd 192.168.1.127 scope global eth0

    inet 192.168.1.212/25 brd 192.168.1.255 scope global eth0

 

 

 

При добавлении адреса из той же сети, что и существующий, новый адрес становится дополнительным к существующему (secondary), и если удалить основной адрес, то будет удален и дополнительный. При этом, команда ifconfig не умеет отображать второй Ip:

 

 

 

nout:~# ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 90:e6:ba:2f:c1:d4

          inet addr:192.168.1.12  Bcast:192.168.1.127  Mask:255.255.255.128

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:1

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

          Interrupt:43

 

 

 

Возможно создать ifconfig - совместимую реализацию способа использования нескольких IP-адресов на одном сетевом интерфейсе. Для этого следует в команде ip addr add использовать параметр label:

 

 

 

nout:~# ip address add 192.168.12.212/25 brd + dev eth0 label eth0:newdev

nout:~# ifconfig

eth0      Link encap:Ethernet  HWaddr 90:e6:ba:2f:c1:d4

          inet addr:192.168.1.12  Bcast:192.168.1.127  Mask:255.255.255.128

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:1

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

          Interrupt:43 

eth0:newdev Link encap:Ethernet  HWaddr 90:e6:ba:2f:c1:d4

          inet addr:192.168.12.212  Bcast:192.168.12.255  Mask:255.255.255.128

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          Interrupt:43

 

 

 

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.12/25 brd 192.168.1.127 scope global eth0

    inet 192.168.1.212/25 brd 192.168.1.255 scope global eth0

    inet 192.168.12.212/25 brd 192.168.12.255 scope global eth0:newdev

nout:~# ip address flush dev eth0

nout:~# ip address show dev eth0

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000

    link/ether 90:e6:ba:2f:c1:d4 brd ff:ff:ff:ff:ff:ff

 

 

 

Как видно, параметр flush очищает все установленные на интерфейсе IP адреса.

 

 

 

Управление ARP-таблицей

 

 

 

В локальной сети текущий хост для определения физических адресов (MAC-адресов) по IP-адресам удаленных узлов использует протокол ARP и локальный ARP -кэш (ARP-таблицу). Управление ARP-таблицей осуществляется командой ip neigh. Каждый узел локальной сети (в том числе и хабы/свичи) содержат свою локальную ARP-таблицу (кэш), которая устанавливает соответствие между IP и MAC-адресами узлов подсетей, в которые входит данную сеть. В ARP-таблице имеются два вида записей:

 

 

 

• Динамические записи, которые периодически обновляются с использованием протокола ARP (если запись "устаревает", то она удаляется).
• Статические записи, которые создаются пользователем с помощью соответствующих команд и существуют до тех пор, пока текущий узел не будет выключен/перезагружен.

 

 

 

nout:~# # отображение содержимого таблицы ARP

nout:~# ip neigh show

192.168.1.1 dev wlan0 lladdr bc:ae:c5:c3:c9:31 REACHABLE

nout:~# # добавление статической записи в ARP таблицу

nout:~# ip neigh add 192.168.1.100 lladdr 00:00:00:11:00:22 dev wlan0

nout:~# ip neigh show

192.168.1.100 dev wlan0 lladdr 00:00:00:11:00:22 PERMANENT

192.168.1.1 dev wlan0 lladdr bc:ae:c5:c3:c9:31 REACHABLE

nout:~# # удаление записи

nout:~# ip neigh del 192.168.1.100 dev wlan0

nout:~# ip neigh show

192.168.1.1 dev wlan0 lladdr bc:ae:c5:c3:c9:31 REACHABLE

 

 

 

Управление маршрутизацией с помощью iproute2

 

 

 

Из статьи Основные понятия сетей мы знаем, что если текущему узлу необходимо куда-либо отправить IP пакет, то сетевая подсистема ядра использует таблицу маршрутизации. Если пакет отправляется в ту же подсеть, которой принадлежит хост, то с помощью ARP определяется физический адрес хоста назначения и пакет отправляется напрямую хосту назначения. Если адрес назначения принадлежит не "локальной сети", то пакет отправляется на шлюз (читай - направляется по маршруту), который указан в таблице маршрутизации для сети, которой принадлежит хост назначения. При этом, выбирается та сеть, в которой адрес сети наиболее заполнен (читай - меньше хостов в подсети). Если для хоста назначения не найден маршрут, то пакет отправляется на "шлюз по умолчанию". Все шлюзы должны находиться в той же подсети, что и исходный хост.

 

 

 

Допустим, в локальной сети есть некоторый хост с адресом 192.168.1.100/24, а так же есть хост 192.168.1.1, который является шлюзом в глобальную сеть, а так же есть хост с адресом 192.168.1.2, который является связующим маршрутизатором с сетью 192.168.24.0/24. Для того, чтобы хост с адресом 192.168.1.100/24 имел доступ в сеть Интернет и к локальной сети 192.168.24.0/24, необходимо внести в таблицу маршрутизации соответствующие записи, например с помощью команды ip route add:

 

 

 

# ip route add default via 192.168.1.1

# ip route add 192.168.24.0/24 via 192.168.1.2

# ip route show

192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.100

192.168.24.0/24 via 192.168.1.2 dev eth1

default via 192.168.1.1 dev eth

 

 

 

Первая команда добавляет маршрут по умолчанию (default) через узел 192.168.1.1 (параметр via ). Вторая команда устанавливает маршрут на сеть 192.168.24.0/24 через узел 192.168.1.2.

 

 

 

Для вывода на экран содержимого таблицы маршрутизации используется команда ip route show. В данном случае в таблице маршрутизации три записи: первая о том, что сеть 192.168.1.0/24 доступна непосредственно на интерфейсе eth1 (запись добавляется автоматически), и две записи, добавленные пользователем: альтернативный маршрут и маршрут по умолчанию.

 

 

 

Добавление постоянного статического маршрута при инициализации сети

 

 

 

О настройке сети через конфигурационные файлы я рассказывал в статье  Настройка сети в Linux, диагностика и мониторинг, в сегодняшней статье я немного дополню эту информацию. С помощью файла /etc/network/interfaces есть возможность задать постоянные маршрута при поднятии интерфейса и удаление маршрута при выключении интерфейса. Это делается с помощью параметра up и down соответственно. Нижеприведенная конфигурация позволяет задать маршрут до сети 192.168.100.0/24 через шлюз 192.168.1.1:

 

 

 

iface eth1 inet static

      address 192.168.1.100

      netmask 255.255.255.0

      up ip route add 192.168.100.0/24 via 192.168.1.1

      down ip route del 192.168.100.0/24

      gateway 192.168.1.3

 

 

 

Выводы

 

 

 

На этом, данную заметку заканчиваю. Подведу краткие итоги. Для управления физическими интерфейсами применяется команда ip link из пакета iproute. Для настройки свойств физического подключения (скорость, технология, тип дуплекса используется команда ethtool. Для того, чтобы хост мог взаимодействовать с другими узлами подсети в рамках локального сегмента (широковещательного домена) на нем должен быть установлен IP-адрес и определена маска подсети. Для управления IP-адресами в Linux можно использовать команду ip addr. В локальной сети данный узел для определения физических адресов(MAC) по IP - адресам других узлов использует протокол ARP и локальный ARP -кэш (таблица). Управление ARP -таблицей осуществляется командой ip neigh. Для взаимодействия с удаленными подсетями на данном узле необходимо определить шлюз по умолчанию или/и альтернативные шлюзы. Все шлюзы должны находиться в той же подсети, что и исходный узел. Управление таблицей маршрутизации на узле может осуществляться командой ip route. У параметров команд пакета iproute2 есть сокращенный синтаксис, например, ip link show eth0 можно записать как ip l sh eth0.