https://opennet.ru/openforum/vsluhforumID1/92093.html Посоветуйте правильное решение:<br><br>В небольшом офисе в качестве шлюза стоит старенький компьютер с FreeBSD и прозрачным Squid, каши не просит и все такое.<br><br>У нас часто бывают проблемы с электричеством (UPS не спасает, т.к. задержки питания на 2-3 часа, а на UPS сидят еще и другие компы), поэтому я хочу заменить этот компьютер на:<br>--- 1. маленький простой роутер (типа Asus WL-500gP);<br>--- 2. между этим роутером и локальной сетью поставить обычный компьютер в режиме моста (или как это назвать???) для тихого и прозрачного подсчета трафика.<br><br>В случае необходимости я просто кабель из локалки буду втыкать в LAN Asus WL-500gP, т.е. просто в обход моста, при этом никто в сети ничего не заметит и все будут работать.<br><br>Кроме этого, плюсом схемы будет максимальная простота с сохранением учета трафика и независимость от того, какую железку за 2000-3000 р. поставить "в мир".<br><br>Вопрос: как называется режим работы компьютера в прозрачном режиме для посчета трафика и как это реализовать? Интересует также возможность у https://opennet.ru/openforum/vsluhforumID1/92093.html#10 Wed, 17 Aug 2011 09:55:16 GMT &gt; Задействуется так net.link.ether.ipfw=1 <br>&gt; И не забыть net.link.ether.bridge_ipfw=1 <br><br>Спасибо за ответ!<br> https://opennet.ru/openforum/vsluhforumID1/92093.html#9 Tue, 16 Aug 2011 01:51:54 GMT &gt;&gt; DEFAULT_TO_ACCEPT - это, конечно, не гуд, но в данной <br>&gt;&gt; ситуации это не влияет на безопасность системы...<br>&gt; Ну, парадоксальным образом ИПФВ, работая в сетевом и транспортном уровнях, умеет резать <br>&gt; арп-пакеты, которые ходят в канальном уровне, но при этом не имеет <br>&gt; средств для управления этим уровнем. ИМХО, это некрасивый архитектурный косяк, но, <br>&gt; с другой стороны, понятно, откуда он возник - неявная обработка канальных <br>&gt; пакетов здорово упрощает конфиг ипфв в 99% случаев. Сильно подозреваю, что <br>&gt; подобная же политика имеет место и в других фаерволлах, это нужно <br>&gt; иметь в виду.<br><br>А я всегда думал, что ARP- это L3. По теме, я бы поставил свич, настроил порт-мирроринг и с помощью нетфлоу снимал бы с этого порта (хотя такого не делал, возможно что-то упустил).<br> https://opennet.ru/openforum/vsluhforumID1/92093.html#8 Mon, 15 Aug 2011 21:34:28 GMT &gt; Задействуется так net.link.ether.ipfw=1 <br>&gt; И не забыть net.link.ether.bridge_ipfw=1 <br><br>И не забыть net.link.bridge.ipfw_arp=1<br><br>Спасибо за дополнение!<br><br><br> https://opennet.ru/openforum/vsluhforumID1/92093.html#7 Mon, 15 Aug 2011 14:25:51 GMT &gt;[оверквотинг удален]<br>&gt; проходят пакеты. Но, обычно, на один из интерфейсов вешается адрес для <br>&gt; возможности удаленно рулить девайсом.<br>&gt; На фре man bridge довольно подробно описывает все нюансы. Из неописанного замечу, <br>&gt; что далеко не все сетевухи одинаково хорошо объединяются в бридж. Могут <br>&gt; быть проблемы как из-за зоопарка сетевух, так и из-за кривизны отдельных <br>&gt; железок. Еще для полностью прозрачного бриджа придется пересобрать ядро со статически <br>&gt; вкомпиленным ИПФВ, которому нужно будет указать дисциплину DEFAULT_TO_ACCEPT. Простое <br>&gt; добавление правила "pass any to any" не поможет бриджевать ARP-пакеты.<br>&gt; Установить на бридже сквид можно - в одноголовой конфигурации, когда входной интерфейс <br>&gt; будет одновременно и исходящим.<br><br>Сие неправда.<br>Существует нотация "mac-type".<br>В т.ч. mac-type arp/rarp.<br><br>Задействуется так net.link.ether.ipfw=1<br><br>И не забыть net.link.ether.bridge_ipfw=1<br> https://opennet.ru/openforum/vsluhforumID1/92093.html#6 Mon, 15 Aug 2011 13:57:42 GMT &gt; Это нужно иметь в виду с той точки зрения, что сетевое взаимодействие <br>&gt; хостов не ограничивается вторым-третьим уровнями тцп/ип, и для корректного бриджевания <br>&gt; нужна корректная отработка первого, канального уровня. Что, обычно, в файрволлах реализовано <br>&gt; специфично. Поскольку вы собираетесь ставить прозрачный сквид с принудительным заворотом <br>&gt; портов средствами файрволла, поведение файрволла на канальном уровне учитывать придется <br>&gt; непременно.<br><br>Ясно! Спасибо за пояснение!<br><br> https://opennet.ru/openforum/vsluhforumID1/92093.html#5 Fri, 12 Aug 2011 14:44:22 GMT &gt; Я не совсем понял, с какой точки зрения это надо иметь ввиду? <br>&gt; Ipfw не пропускает arp-опросы? Или что-то другое?<br><br>Это нужно иметь в виду с той точки зрения, что сетевое взаимодействие хостов не ограничивается вторым-третьим уровнями тцп/ип, и для корректного бриджевания нужна корректная отработка первого, канального уровня. Что, обычно, в файрволлах реализовано специфично. Поскольку вы собираетесь ставить прозрачный сквид с принудительным заворотом портов средствами файрволла, поведение файрволла на канальном уровне учитывать придется непременно. <br> https://opennet.ru/openforum/vsluhforumID1/92093.html#4 Fri, 12 Aug 2011 07:10:09 GMT &gt; Ну, парадоксальным образом ИПФВ, работая в сетевом и транспортном уровнях, умеет резать <br>&gt; арп-пакеты, которые ходят в канальном уровне, но при этом не имеет <br>&gt; средств для управления этим уровнем. ИМХО, это некрасивый архитектурный косяк, но, <br>&gt; с другой стороны, понятно, откуда он возник - неявная обработка канальных <br>&gt; пакетов здорово упрощает конфиг ипфв в 99% случаев. Сильно подозреваю, что <br>&gt; подобная же политика имеет место и в других фаерволлах, это нужно <br>&gt; иметь в виду.<br><br>Я не совсем понял, с какой точки зрения это надо иметь ввиду? Ipfw не пропускает arp-опросы? Или что-то другое?<br> https://opennet.ru/openforum/vsluhforumID1/92093.html#3 Thu, 11 Aug 2011 14:17:03 GMT &gt; DEFAULT_TO_ACCEPT - это, конечно, не гуд, но в данной <br>&gt; ситуации это не влияет на безопасность системы... <br><br>Ну, парадоксальным образом ИПФВ, работая в сетевом и транспортном уровнях, умеет резать арп-пакеты, которые ходят в канальном уровне, но при этом не имеет средств для управления этим уровнем. ИМХО, это некрасивый архитектурный косяк, но, с другой стороны, понятно, откуда он возник - неявная обработка канальных пакетов здорово упрощает конфиг ипфв в 99% случаев. Сильно подозреваю, что подобная же политика имеет место и в других фаерволлах, это нужно иметь в виду. <br> https://opennet.ru/openforum/vsluhforumID1/92093.html#2 Thu, 11 Aug 2011 11:49:15 GMT Большое спасибо!<br><br>Bridge - это мост по-нашенски. То, что DEFAULT_TO_ACCEPT - это, конечно, не гуд, но в данной ситуации это не влияет на безопасность системы...<br><br>С сетевухами проблем быть не должно, в крайнем случае поставлю 3Com 905 и всех делов, благо их в изобилии (у меня, а не в магазине ;)).<br><br>В общем, пошел гуглить на тему "bridge linux squid"...<br>