Посоветуйте правильное решение:В небольшом офисе в качестве шлюза стоит старенький компьютер с FreeBSD и прозрачным Squid, каши не просит и все такое.
У нас часто бывают проблемы с электричеством (UPS не спасает, т.к. задержки питания на 2-3 часа, а на UPS сидят еще и другие компы), поэтому я хочу заменить этот компьютер на:
--- 1. маленький простой роутер (типа Asus WL-500gP);
--- 2. между этим роутером и локальной сетью поставить обычный компьютер в режиме моста (или как это назвать???) для тихого и прозрачного подсчета трафика.В случае необходимости я просто кабель из локалки буду втыкать в LAN Asus WL-500gP, т.е. просто в обход моста, при этом никто в сети ничего не заметит и все будут работать.
Кроме этого, плюсом схемы будет максимальная простота с сохранением учета трафика и независимость от того, какую железку за 2000-3000 р. поставить "в мир".
Вопрос: как называется режим работы компьютера в прозрачном режиме для посчета трафика и как это реализовать? Интересует также возможность уставновки на нем Squid для подробной статистики.
Схема сети на картинке: http://i.piccy.info/i5/64/32/1843264/set_s_prozrachnym_mosto...
> Вопрос: как называется режим работы компьютера в прозрачном режиме для посчета трафика
> и как это реализовать? Интересует также возможность уставновки на нем Squid
> для подробной статистики.Это называется бридж. Объединение нескольких сетевых интерфейсов в одно устройство, являющееся полным эквивалентом свитча. Т.е. бридж принимает пакет на одном порту, и либо шлет его во все другие порты, если во внутренних таблицах нет соответствия между маком получателя и портом, либо в конкретный порт, ассоциированный с маком получателя.
Достоинством бриджа перед обычным свитчом есть возможность обрабатывать пакеты произвольным образом в процессе его следования со входного порта на выходной - считать, шейпить, фильтровать, подменять, дублировать етц. По факту, компу, все порты которого объединены в бридж, даже не нужен ИП адрес для работы - обработку пакетов можно производить по именам интерфейсов, через порты которых проходят пакеты. Но, обычно, на один из интерфейсов вешается адрес для возможности удаленно рулить девайсом.
На фре man bridge довольно подробно описывает все нюансы. Из неописанного замечу, что далеко не все сетевухи одинаково хорошо объединяются в бридж. Могут быть проблемы как из-за зоопарка сетевух, так и из-за кривизны отдельных железок. Еще для полностью прозрачного бриджа придется пересобрать ядро со статически вкомпиленным ИПФВ, которому нужно будет указать дисциплину DEFAULT_TO_ACCEPT. Простое добавление правила "pass any to any" не поможет бриджевать ARP-пакеты.
Установить на бридже сквид можно - в одноголовой конфигурации, когда входной интерфейс будет одновременно и исходящим.
Большое спасибо!Bridge - это мост по-нашенски. То, что DEFAULT_TO_ACCEPT - это, конечно, не гуд, но в данной ситуации это не влияет на безопасность системы...
С сетевухами проблем быть не должно, в крайнем случае поставлю 3Com 905 и всех делов, благо их в изобилии (у меня, а не в магазине ;)).
В общем, пошел гуглить на тему "bridge linux squid"...
> DEFAULT_TO_ACCEPT - это, конечно, не гуд, но в данной
> ситуации это не влияет на безопасность системы...Ну, парадоксальным образом ИПФВ, работая в сетевом и транспортном уровнях, умеет резать арп-пакеты, которые ходят в канальном уровне, но при этом не имеет средств для управления этим уровнем. ИМХО, это некрасивый архитектурный косяк, но, с другой стороны, понятно, откуда он возник - неявная обработка канальных пакетов здорово упрощает конфиг ипфв в 99% случаев. Сильно подозреваю, что подобная же политика имеет место и в других фаерволлах, это нужно иметь в виду.
> Ну, парадоксальным образом ИПФВ, работая в сетевом и транспортном уровнях, умеет резать
> арп-пакеты, которые ходят в канальном уровне, но при этом не имеет
> средств для управления этим уровнем. ИМХО, это некрасивый архитектурный косяк, но,
> с другой стороны, понятно, откуда он возник - неявная обработка канальных
> пакетов здорово упрощает конфиг ипфв в 99% случаев. Сильно подозреваю, что
> подобная же политика имеет место и в других фаерволлах, это нужно
> иметь в виду.Я не совсем понял, с какой точки зрения это надо иметь ввиду? Ipfw не пропускает arp-опросы? Или что-то другое?
> Я не совсем понял, с какой точки зрения это надо иметь ввиду?
> Ipfw не пропускает arp-опросы? Или что-то другое?Это нужно иметь в виду с той точки зрения, что сетевое взаимодействие хостов не ограничивается вторым-третьим уровнями тцп/ип, и для корректного бриджевания нужна корректная отработка первого, канального уровня. Что, обычно, в файрволлах реализовано специфично. Поскольку вы собираетесь ставить прозрачный сквид с принудительным заворотом портов средствами файрволла, поведение файрволла на канальном уровне учитывать придется непременно.
> Это нужно иметь в виду с той точки зрения, что сетевое взаимодействие
> хостов не ограничивается вторым-третьим уровнями тцп/ип, и для корректного бриджевания
> нужна корректная отработка первого, канального уровня. Что, обычно, в файрволлах реализовано
> специфично. Поскольку вы собираетесь ставить прозрачный сквид с принудительным заворотом
> портов средствами файрволла, поведение файрволла на канальном уровне учитывать придется
> непременно.Ясно! Спасибо за пояснение!
>> DEFAULT_TO_ACCEPT - это, конечно, не гуд, но в данной
>> ситуации это не влияет на безопасность системы...
> Ну, парадоксальным образом ИПФВ, работая в сетевом и транспортном уровнях, умеет резать
> арп-пакеты, которые ходят в канальном уровне, но при этом не имеет
> средств для управления этим уровнем. ИМХО, это некрасивый архитектурный косяк, но,
> с другой стороны, понятно, откуда он возник - неявная обработка канальных
> пакетов здорово упрощает конфиг ипфв в 99% случаев. Сильно подозреваю, что
> подобная же политика имеет место и в других фаерволлах, это нужно
> иметь в виду.А я всегда думал, что ARP- это L3. По теме, я бы поставил свич, настроил порт-мирроринг и с помощью нетфлоу снимал бы с этого порта (хотя такого не делал, возможно что-то упустил).
>[оверквотинг удален]
> проходят пакеты. Но, обычно, на один из интерфейсов вешается адрес для
> возможности удаленно рулить девайсом.
> На фре man bridge довольно подробно описывает все нюансы. Из неописанного замечу,
> что далеко не все сетевухи одинаково хорошо объединяются в бридж. Могут
> быть проблемы как из-за зоопарка сетевух, так и из-за кривизны отдельных
> железок. Еще для полностью прозрачного бриджа придется пересобрать ядро со статически
> вкомпиленным ИПФВ, которому нужно будет указать дисциплину DEFAULT_TO_ACCEPT. Простое
> добавление правила "pass any to any" не поможет бриджевать ARP-пакеты.
> Установить на бридже сквид можно - в одноголовой конфигурации, когда входной интерфейс
> будет одновременно и исходящим.Сие неправда.
Существует нотация "mac-type".
В т.ч. mac-type arp/rarp.Задействуется так net.link.ether.ipfw=1
И не забыть net.link.ether.bridge_ipfw=1
> Задействуется так net.link.ether.ipfw=1
> И не забыть net.link.ether.bridge_ipfw=1И не забыть net.link.bridge.ipfw_arp=1
Спасибо за дополнение!
> Задействуется так net.link.ether.ipfw=1
> И не забыть net.link.ether.bridge_ipfw=1Спасибо за ответ!
