Запрет пробрасывания пакетов между внутренними интерфейсами

[Serg79]

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

Ситуация такая, машина полностью отрезает локальную сеть от внешнего мира, т.к. форвардинг отключен. Но дает цепляться к своему внешнему интерфейсу из локальной сети. Т.е. например интерфейс всмотрящий во внутреннюю сеть имеет адрес 192.168.21.1/24 а интерфейс смотрящий во внешний мир имеет адрес 192.168.234.32/24. И шлюз дает возможность из внутренней сети 192.168.21.0/24 подцепиться к машине на адрес 192.168.234.32.

Как побороть данное явление?

[Finch]

У тебя шлюз настроен на файрволе iptables? ‏‎Если да, покажи выдачу iptables-save.

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

Ээээ это как понять?. Или она есть шлюз или она не шлюз?

[Serg79]

iptables вообще не используется. Его поддержка даже в ядро не в компилирована.

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

Вот как отключить это поведение я и пытаюсь определить.

[Finch]

Самый легкий способ фиксить такие веши это файрвол.

[Serg79]

Finch, да должно быть какое то стандартное средство типа '/proc/sys/net/ipv4/ip_forward' который отключает глобальный форвардинг. А iptables это дополнительная нагрузка на стек протоколов.

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

Я уже весь '/proc/sys/net/ipv4' облазил, не пойму где эта функция включается.

[RXL]

Serg79, iptables - это фильтр/файрвол. Форвардинг пакетов определяется маршрутизатором.
Виртуальный файл /proc/sys/net/ipv4/ip_forward определяет, включен ли форвардинг.

Узнать: cat /proc/sys/net/ipv4/ip_forward
Включить: echo 1 >/proc/sys/net/ipv4/ip_forward
Выключить: echo 0 >/proc/sys/net/ipv4/ip_forward

Состояние не сохраняется при перезагрузке. Обычно скрипт настройки сети это настраивает.

А iptables это дополнительная нагрузка на стек протоколов.

Если у тебя 10Гбит каналы, то конечно нагрузка.
По моей практике: канал 100Мбит iptables вообще никак не нагружает - загрузка процессора 0.3%.
Еще из давней практики: роутер на базе Pentium 100, 4 интерфейса 10Мбит, iptables - ~300 строк. Работал на ура с полной нагрузкой интерфейсов.

Понятия "глобальный форвардинг" нету. Пакеты пропускаются в обе стороны всегда! Остальное определяется только файрволом.

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

[Serg79]

RXL, все что Ты выше описал это я знаю. Насчет 'ip_forward' и всего сопутствующего я описал выше.

Проблема не в том, что невозможно отключить форвардинг, как Ты уже выше описал, установка значений в файле '/proc/sys/net/ipv4/ip_forward' решает эту проблему.

Проблема в том, что Linux машина имея несколько IP адресов на разных интерфейсах отвечает на все пакеты приходящие на данные адреса в независимости от поступающего интерфейса (уже запутался в своих словах). Т.е. есть [eth0 -> 12.23.34.45] и [eth1 -> 45.34.23.12], если пакет конект приходит на адрес 12.23.34.45 через интерфейс eth1 то она отвечает на этот конект. Необходимо отключить данную возможность. Т.е. разрешить доступ к IP: 12.23.34.45 только через сеть доступную через eth0, а к 45.34.23.12 только через сеть доступную через eth1.

[RXL]

http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt

Попробуй net.ipv4.conf.all.rp_filter=1

[Rulik]

Коннектится к определенному сервису?
Если да, то задай в настройках этого сервиса, на каком IP слушать.
Видимо, у тебя там стоит 0.0.0.0, что значит принимать подключение с любого локального IP.
Если туда конкретно прописать IP, то коннекты будут приниматься только с интерфейса с этим IP.

[RXL]

Rulik, почитай внимательнее: входящий пакет с dst ip, принадлежащим текущему хосту, будет принят вне зависимости от интерфейса, через который он вошел. Управляет этим rt_filter. Вопрос был в том, как отключить такое поведение и запретить принимать такие пакеты.

[Serg79]

Rulik, почитай внимательнее: входящий пакет с dst ip, принадлежащим текущему хосту, будет принят вне зависимости от интерфейса, через который он вошел. Управляет этим rt_filter.

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

На ситуацию описанную выше, данный параметр никак не влияет.

[Serg79]

По моей практике: канал 100Мбит iptables вообще никак не нагружает - загрузка процессора 0.3%.

На счет влияния iptables на сетевой стек.

Сервер HP ProLiant DL165G, 2 четырех ядерных Opertron-a, 8G памяти, ядро 2.6.27.41, четырех портовая e1000 два порта которой объединены в бридж (br0).

Записи добавляются в таблицу 'raw' и имеют следующий вид:

Код:

iptables -t raw -A PREROUTING -p tcp -s 1.2.3.4 -d 0.0.0.0/0 -dport 11 -j RETURN

1) 500 записей - 112 Mb/s скорость прокачки через бридж ~ 94% от номинальной пропускной способности интерфейсов.
2) 1000 - 64,4 Mb/s ~ 54%
3) 2000 - 35,3 Mb/s ~ 29%
4) 10000 - 3,64 Mb/s ~ 3%
5) 20000 - 1,81 Mb/s ~ 1,5%

Так что говорить о незначительной нагрузки iptables на сетевой стек не приходиться.

[RXL]

Сереж, а на практике тебе нужно тысяча и более записей?
И я бы сперва отсеял каким-либо грубым фильтром, а потом уже проверял поштучно. Например, отсеять сетку. Дерево все же оптимальнее, чем список.

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

[Serg79]

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

[RXL]

Тебе исключительно для подсчета трафика нужно?
Посмотри match account.

[Serg79]

Тебе исключительно для подсчета трафика нужно?

Нет, это по работе. А подсчет трафика это для души.)))

[RXL]

Если не секрет, какая задача стоит?

[Serg79]

Железка работает в качестве VAS сервера для Cisco и должна обрабатывать потоки с определенных IP. При этом железка должна просаживать гигабитный трафик не более чем на 15%. IP на контроле может стоять действительно много а на iptables завязан основной функционал.

[RXL]

Попробуй еще ebtables - возможно он будет оптимальнее по нагрузке.

Еще проверь - этот трафик минует connection tracking?

Оптимизация по цепочкам: сперва ступенчато отсеить тестируемые IP (ступенчато наращивая маску от сети до 32 с шагом 4 или 8 ), а потом уже их тестировать. В твоем варианте для нужных пакетов будет использовано N/2 правил, а для прочих пакетов - все N! В случае дерева можно снизить число тестов для прочих пакетов до единиц-десятков, а для нужных - до десятков-сотен.