Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Запрет пробрасывания пакетов между внутренними интерфейсами  (Прочитано 28567 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« : 04-08-2009 15:03 » 

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

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

Как побороть данное явление?
Записан
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #1 : 04-08-2009 15:54 » 

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

Цитата
Так же эта машина является шлюзом по умолчанию для локальной сети. Проброс пакетов между интерфейсами выключен.
Ээээ это как понять?. Или она есть шлюз или она не шлюз?
« Последнее редактирование: 04-08-2009 15:56 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 04-08-2009 15:58 » 

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

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

Вот как отключить это поведение я и пытаюсь определить.
Записан
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #3 : 04-08-2009 16:06 » 

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

Не будите спашяго дракона.
             Джаффар (Коша)
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 04-08-2009 16:13 » 

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

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

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 04-08-2009 19:28 » 

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 строк. Работал на ура с полной нагрузкой интерфейсов.

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

Некогда я тоже занимался перекомпиляцией ядер, убирал лишнее, перенастраивал. Потом понял, чьто фигней занимаюсь - ядра из дистрибутива заточены нормально и в таком виде их проще обновлять из репозитория. Управление машиной - очень важная вещь.
« Последнее редактирование: 04-08-2009 19:39 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 05-08-2009 06:07 » 

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
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 05-08-2009 06:45 » 

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

Попробуй net.ipv4.conf.all.rp_filter=1
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Rulik
Помогающий

ru
Offline Offline

« Ответ #8 : 14-12-2009 10:13 » 

Коннектится к определенному сервису?
Если да, то задай в настройках этого сервиса, на каком IP слушать.
Видимо, у тебя там стоит 0.0.0.0, что значит принимать подключение с любого локального IP.
Если туда конкретно прописать IP, то коннекты будут приниматься только с интерфейса с этим IP.
« Последнее редактирование: 14-12-2009 11:01 от Sel » Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #9 : 14-12-2009 11:28 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #10 : 24-06-2010 16:29 » 

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

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #11 : 24-06-2010 17:13 » 

По моей практике: канал 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
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #12 : 24-06-2010 18:15 » 

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #13 : 24-06-2010 18:24 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #14 : 24-06-2010 18:25 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #15 : 24-06-2010 18:27 » 

Тебе исключительно для подсчета трафика нужно?
Нет, это по работе. А подсчет трафика это для души.)))
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #16 : 24-06-2010 18:33 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #17 : 24-06-2010 18:51 » new

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #18 : 24-06-2010 19:09 » 

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines