Есть сеть: ааа.ббб.ввв.ггг\24 нужно написать правило на IPFW для того что бы с любого АйПи этой сети можно было посылать\принмать данные на адресс(е) ааа.ббб.ввв.1\32(который далее переправит пакеты в другое место) и что бы было запрещено передавать\принимать любые данные из этой сети(ааа.ббб.ввв.ггг\24) в эту же сеть через адресс ааа.ббб.ввв.1\32.Предложения написать блок правил для каждого адресса отпадают. Правило должно быть малым, быстрым и конструктивным.
Что-то типа такого, но улучшеное:
100 deny ip from ааа.ббб.ввв.ггг\24 to ааа.ббб.ввв.ггг\24 via ааа.ббб.ввв.1\32
200 allow ip from ааа.ббб.ввв.ггг\24 to ааа.ббб.ввв.1\32 via ааа.ббб.ввв.1\32
>Есть сеть: ааа.ббб.ввв.ггг\24 нужно написать правило на IPFW
>для того что бы с любого АйПи этой сети можно было
>посылать\принмать данные на адресс(е) ааа.ббб.ввв.1\32(который далее переправит пакеты в другое
>место) и что бы было запрещено передавать\принимать любые данные из
>этой сети(ааа.ббб.ввв.ггг\24) в эту же сеть через адресс ааа.ббб.ввв.1\32.
>
>Предложения написать блок правил для каждого адресса отпадают. Правило должно быть малым,
>быстрым и конструктивным.
>
>Что-то типа такого, но улучшеное:
>100 deny ip from ааа.ббб.ввв.ггг\24 to ааа.ббб.ввв.ггг\24 via ааа.ббб.ввв.1\32
>200 allow ip from ааа.ббб.ввв.ггг\24 to ааа.ббб.ввв.1\32 via ааа.ббб.ввв.1\32Не сочтите за наглость, но вам бы доков сначала хоть чуть-чуть почитать не помешало бы.
Хотя бы man ipfw.
Прочитав (самую малость) ман, можно было бы понять, что файрвол ipfw - это файрвол, а не маршрутизатор (форвардинг не в счет). Т.е. пропускает или блокирует входящие и исходящие ip-пакеты на/с установленных в системе интерфейсах (читай - сетевых карт). Он никоим образом не занимается маршрутизацией пакетов из одной сети в другую через третью. И ему вообще до большой Ж эта маршрутизация, т.к. глобальный его удел совсем в другой (оттого он зовется огнестеной, а не каким-нибудь роутером).Далее, с того же мана можно было бы почерпнуть инфу о том, что правила типа
>100 deny ip from ааа.ббб.ввв.ггг\24 to ааа.ббб.ввв.ггг\24 via ааа.ббб.ввв.1\32
>200 allow ip from ааа.ббб.ввв.ггг\24 to ааа.ббб.ввв.1\32 via ааа.ббб.ввв.1\32
невозможны в принципе, т.к. опция via указывает на то, что файрвол также должен проверять с какого интерфейса он получил пакет и стоит ли его блокировать/пропускать.
В других словах, правило в общем виде должно выглядеть примерно так:
100 deny ip from 1.1.1.1/24 to 2.2.2.2/24 via rl0
что в переводе на русский язык значит "блокировать пакеты полученные с сетевой карты rl0, пришедшие по протоколу ip из сети 1.1.1.1 с сетевой маской 24 (255.255.255.0) и предназначенные для какого-нибудь адреса из сети 2.2.2.2 с сетевой маской 24".
Если придет аналогичный пакет из сети 1.1.1.1/24 в сеть 2.2.2.2/24, но через интерфейс, скажем bfe0, он будет пропущен, т.к. в правиле задана блокировка пакетов с интерфейса rl0.В общем-то вы и не виноваты, что манов не читали, и заставлять вас никто не будет (вас просто могут отфутболить к ним:).
Если вам поставили задачу найти такие правила или попросить кого-нибудь, кто мог бы написать их, то, похоже, не того попросили. Если же они вам самой нужны, то в любом случае _ИЗНАЧАЛЬНО_ нужно обращаться к литературе. Тогда вы хотя бы примерно поймете предметную область и вопросы будете задавать четче и правильнее. А то получается "хочу кастрюлю, разогревающую картошку микроволнами от батареек", не зная хотя бы, что кастрюля микроволны пускать не умеет...Да и вообще, ваш вопрос выглядит даже и не как вопрос или просьба, а скорее как приказ...
Ну ладно, ежели вы хотите
>что бы с любого АйПи этой сети можно было посылать\принмать данные на адресс(е) ааа.ббб.ввв.1\32
то наверное вам поможет
allow ip from а.б.в.г/24 to а.б.в.1/24
allow ip from а.б.в.1/24 to а.б.в.г/24>(который далее переправит пакеты в другое место)
тот сервер нужно отдельно просить, чтобы он переправил пакеты... файрвол с одного сервера не будет просить файрвол (или какой-либо демон) другого сервера сделать что-нибудь... типа послать пакеты дальше куда там нужно...А если же нужно
>что бы было запрещено передавать\принимать любые данные из этой сети(ааа.ббб.ввв.ггг\24) в эту же сеть через адресс ааа.ббб.ввв.1\32
то наверное поможет
add deny ip from а.б.в.г/24 to а.б.в.г/24 via <имя_интерфейса_который_смотрит_в_сеть_а.б.в.г/24>
с условием того, что это правило будет написано для файрвола, стоящего на машине а.б.в.1.Еще замечу, что сетевая маска (цифры через слеш после айпи-адреса) пишется через прямой слэш (/), а не обратный (\) как у вас, иначе конструкция \2 будет воспринята как просто символ "2" и вместо "а.б.в.г\24" вы получите "а.б.в.г24".
К тому же, сети с маской 32 (255.255.255.255) не существует (просто получится один ip-адрес, который, к тому же будет считаться широковещательным). Некоторые клиенты, как dhclient, клиент DHCP использует адрес вида 0.0.0.0/32, но на моей памяти это единственный случай использования маски такого рода (или память меня подводит...?).
Если вы имеете в виду какой-то конкретный адрес (а.б.в.1 в вашем случае), то маску писать не надо!Если а.б.в.1 находится в той же сети (а.б.в.г/24), то смысла приведенного выше мной правила я не вижу, т.к. маршрутизацией пакетов в пределах сети будет заниматься свитч (хаб) и если пакет не предназначен для а.б.в.1, то его он никогда и не получит (если только у вас не свитч, а хаб. Хотя, даже в этом случае пакет будет просто проигнорирован машиной)...
Ладно, хватит разглагольствовать, пару нравоучений я вам дал.
Если же вы знаете и понимаете о чем спрашивали, но просто не так выразили мысли, ваш вопрос имеет хоть какую-то практическую ценность и не является чепухой и полной фигней, читайте далее...............Теперь ВНИМАНИЕ! Намек на ответ на ваш вопрос:
копайте доки в сторону ipfw forwarding!
Насколько я понял суть вашего вопроса, думаю, вам это поможет...
:)))
Удачи!
Благодарю Вас любезнейший! :) особенно было интересно читать про кастрюлю излучающую микроволны от батареек! (жжешь однако!)Теперь по сути... С брандмауэром - знакома, но увы всего азы. Маны читали, знаем слышали... остаеться только перефразировать вопрос. Да он действительно задан был не корректно. и если вы уже не затруднились расписать такую лекцию для домохозяйки, тогда может вам не составит сложности прочесть еще немного... И так: пробуем еще раз.
Имееться Фри_6.1 на ней есть 2 интерфейса (скажем первый и второй) с адресами 1,1,1,1 и 2,2,2,2
к интерфейсу первому, тому у которого адресс 1,1,1,1 подключены пользователи в сети 1,1,1,0/24. есть одна особенность: трафик в сети 1,1,1,0/24 между компьютерами перекачиваеться через интерфейс сервера 1,1,1,1. И происходит это только лишь так и никак иначе, не будем удаваться в детали и думать от чего так.
Задача: запретить в Фаерволе это перекачивание трафика между клиентами сети 1,1,1,0/24 через интерфейс сервера 1,1,1,1. И одновременно оставить открытым канал для каждого пользователся сети 1,1,1,0/24 к интерфейсу сервера 1,1,1,1 для дальнейшего перенаправления\приема трафика(НЕ прохождения по этой же сети), скажем редирект на второй интерфейс определенных запросов(это уже не суть дела).
Все на что мне хватило смекалки:
add 100 allow ip from 1.1.1.0/24 to 1.1.1.1
add 110 allow ip from 1.1.1.1 to 1.1.1.0/24
(нужно ли писать эти 2 правила если пакеты сами по себе бегают через 1,1,1,1 ???
)
add 200 deny ip from 1.1.1.0/24 to 1.1.1.0/24 via 1.1.1.1 (насколько я знаю, тут можно указать АйПи интерфейса, так как при указании интерфейса он все-равно заменяеться его адрессом при загрузке и обработке правил брандмауера)
>Благодарю Вас любезнейший! :) особенно было интересно читать про кастрюлю излучающую микроволны
>от батареек! (жжешь однако!)
>
>Теперь по сути... С брандмауэром - знакома, но увы всего
>азы. Маны читали, знаем слышали... остаеться только перефразировать вопрос. Да
>он действительно задан был не корректно. и если вы уже
>не затруднились расписать такую лекцию для домохозяйки, тогда может вам не
>составит сложности прочесть еще немного... И так: пробуем еще раз.
>
>Имееться Фри_6.1 на ней есть 2 интерфейса (скажем первый и второй) с
>адресами 1,1,1,1 и 2,2,2,2
>
>к интерфейсу первому, тому у которого адресс 1,1,1,1 подключены пользователи в сети
>1,1,1,0/24. есть одна особенность: трафик в сети 1,1,1,0/24 между компьютерами
>перекачиваеться через интерфейс сервера 1,1,1,1. И происходит это только лишь так
>и никак иначе, не будем удаваться в детали и думать от
>чего так.
> Задача: запретить в Фаерволе это перекачивание трафика
>между клиентами сети 1,1,1,0/24 через интерфейс сервера 1,1,1,1. И
>одновременно оставить открытым канал для каждого пользователся сети 1,1,1,0/24 к интерфейсу
>сервера 1,1,1,1 для дальнейшего перенаправления\приема трафика(НЕ прохождения по этой же сети),
>скажем редирект на второй интерфейс определенных запросов(это уже не суть дела).
>
>
>
>Все на что мне хватило смекалки:
>add 100 allow ip from 1.1.1.0/24 to 1.1.1.1
>add 110 allow ip from 1.1.1.1 to 1.1.1.0/24
>(нужно ли писать эти 2 правила если пакеты сами по себе бегают
>через 1,1,1,1 ???
>)
>add 200 deny ip from 1.1.1.0/24 to 1.1.1.0/24 via 1.1.1.1 (насколько
>я знаю, тут можно указать АйПи интерфейса, так как при указании
>интерфейса он все-равно заменяеться его адрессом при загрузке и обработке правил
>брандмауера)Хотелось бы увидеть схему сети в которой трафик внутри одной подсети идет через сервер. Просто ради интереса.
>
>Хотелось бы увидеть схему сети в которой трафик внутри одной подсети идет
>через сервер. Просто ради интереса.
Если очень и очень интересно - то могу рассказать как это происходит, если вернешся сюда еще раз...
>Теперь по сути... С брандмауэром - знакома, но увы всего
>азы. Маны читали, знаем слышали... остаеться только перефразировать вопрос. Да
>он действительно задан был не корректно. и если вы уже
>не затруднились расписать такую лекцию для домохозяйки, тогда может вам не
>составит сложности прочесть еще немного... И так: пробуем еще раз.Тут, понимаете, в чем сложность... Весьма не лишним, а я бы даже сказал необходимым, знаниям к файрволам нужно еще добавить про "принципы построения сетей и маршрутизации данных внутри и между ними".
>Имееться Фри_6.1 на ней есть 2 интерфейса (скажем первый и второй) с
>адресами 1,1,1,1 и 2,2,2,2
А давайте называть интерфейсы их именами, скажем, первый интерфейс 1.1.1.1 будет rl1(рл1), а второй 2.2.2.2 - rl2(рл2). Так и короче и кнопок на клаве мне нажимать меньше :).
>к интерфейсу первому, тому у которого адресс 1,1,1,1 подключены пользователи в сети
>1,1,1,0/24. есть одна особенность: трафик в сети 1,1,1,0/24 между компьютерами
>перекачиваеться через интерфейс сервера 1,1,1,1. И происходит это только лишь так
>и никак иначе, не будем удаваться в детали и думать от
>чего так.Пойдем с другой стороны. Прежде всего уясним, что скорее всего сеть у вас сделана на витой паре (пятой категории, наверное экранированная). Если это не так и у вас сеть на старом коаксиале, абзаца три-четыре можно не читать.
Так вот, сети на витой паре строятся по топологии звезда, т.е. есть много компов, они проводами (лучами) соединены в одной точке. Этой точкой является хаб (хуже) или свитч(лучше), они же концентратор и коммутатор соответственно. Когда пакет идет от компа, скажем, 1.1.1.1 до 1.1.1.2, то сперва пакет с 1.1.1.1 попадает на хаб/свитч. У хабов/свитчей есть много (от 4х и выше) портов, куда и подключаются все компы в сети. Так вот, если наш пакет попал на хаб, то электроникой хаба этот пакет будет транслирован на все порта хаба. Другими словами этот пакет пойдет сразу всем компам в сети. Если среди этих компов найдется с адресом 1.1.1.2, то нам повезло и пакет будет доставлен. Остальные компы, получая этот пакет и видя, что адрес получателя не совпадает с их собственным, просто игнорируют его (вот такие вот джентельмены, чужую корреспонденцию не читают...).
Если же на пути пакета попался свитч, то тут все немного по другому. Свитч - зверек поумнее хаба. У него есть немного мозгов и он активно пользуется _таблицей маршрутизации_. Будучи включенным в какую-либо сеть, он активно начинает пользоваться своими эвристическими анализаторскими методами и потихоньку составляет себе таблицу соответствий ip-адреса и номера портов, имеющихся у свитча в наличии. Значит, повав на свитч, заголовок нашего пакета будет проанализирован на предмет адреса получателя. Потом свитч посмотрит в своей таблице, какой же порт соответствует этому ip, а затем, соответственно, на найденый порт и отправит пакет. Если ничего свитч в своей таблице не найдет, то, обидевшись, пошлет пакет сразу на все буквы. Опс, не буквы, на все порта. А там дальше, кто откликнется, тот и владелец нужно ip...Во всей этой топологии сервер фактически является самым обычным, рядовым участником сети. Т.е. подключается точно также как и все остальные машины в сети, и, с точки зрения хаба/свитча, ничем выдающимся не является... Разве что айпи-адрес, как правило, козырной, на единичку оканчивается.
Из всего этого можно сделать вывод, что маршрутизацией в сегменте сети занимается хаб/свитч, а не сервер.
Следовательно,
>к интерфейсу первому, тому у которого адресс 1,1,1,1 подключены пользователи
>в сети 1,1,1,0/24.
является неверным утверждением, т.к. одному интерфейсу (рл1) не может быть подключено столько пользователей, т.к. порт у сетевой карты всего один. К этому интерфейсу может быть подключен хаб/свитч (лучик звезды, если смотреть на топологию), через который данный интерфейс общается со своими друзьями в пределах сети.>есть одна особенность: трафик в сети 1,1,1,0/24 между компьютерами
>перекачиваеться через интерфейс сервера 1,1,1,1.
Теперь, когда вы знаете про топологию сети, проследим путь пакета, идущего по пути, который вы только что указали.
комп(1.1.1.10) -> свитч -> сервер(1.1.1.1) -> свитч -> получатель (1.1.1.20)
Чтобы не замусоривать трафик в сети, снижая тем самым ее пропускную способность, маршрут сей нуждается в хорошей оптимизации. Мы видим, что отправленный пакет приходит на свитч, уходит с него, затем опять на него же возвращается. И зачем ему так петлять? Убираем этот кусок маршрута, и маршрут сразу сокращается вдвое. Пакет наш и так будет доставлен, а вдобавок и сервер избавлен от необходимости этот пакет обрабатывать. Может ему что поважнее шлют, а он тут глупостями занимается...>И происходит это только лишь так и никак иначе, не будем
>удаваться в детали и думать от чего так.
А ведь надо, никуда от этого не деться. Вы же ломаете типичное представление людей об организации сети. И всем интересно будет узнать, отчего так, ведь это скорее исключение из правил, нежели правило!
>Задача: запретить в Фаерволе это перекачивание трафика
>между клиентами сети 1,1,1,0/24 через интерфейс сервера 1,1,1,1. И
>одновременно оставить открытым канал для каждого пользователся сети 1,1,1,0/24 к интерфейсу
>сервера 1,1,1,1 для дальнейшего перенаправления\приема трафика(НЕ прохождения по этой же сети),
>скажем редирект на второй интерфейс определенных запросов(это уже не суть дела).Ну и, соответственно, задача, в свете изложенного выше, требует еще одного уточнения.
Единственное, что еще можно понять, так это то, что сервер ваш, 1.1.1.1, является еще и маршрутизатором (роутером), т.е. на нем есть два интерфейса - рл1, который смотрит в сеть 1.1.1.0/24, и рл2, смотрящую в сеть 2.2.2.0/24. Вот сервер и заставили маршрутить пакеты между этими двумя сетями. И компы из 1.1.1.0/24 спокойно будут болтать пакетами с компами из 2.2.2.0/24. Но они _не_ будут использовать сей маршрутизатор для того, чтобы болтать с компами из своей же сети!
>Все на что мне хватило смекалки:
>add 100 allow ip from 1.1.1.0/24 to 1.1.1.1
>add 110 allow ip from 1.1.1.1 to 1.1.1.0/24
>(нужно ли писать эти 2 правила если пакеты сами по себе бегают
>через 1,1,1,1 ???
Поскольку пакеты сами по себе через 1.1.1.1 не бегают, следовательно нет и необходимости в этих правилах. Если только ваш файрвол по умолчанию не блокирует все пакеты ("запрещать все, что не разрешено"), то эти правила нужны для того, чтобы можно было доставить пакеты серверу 1.1.1.1 с компов сети 1.1.1.0/24 и обратно, с сервера в сеть.>add 200 deny ip from 1.1.1.0/24 to 1.1.1.0/24 via 1.1.1.1 (насколько
>я знаю, тут можно указать АйПи интерфейса, так как при указании
>интерфейса он все-равно заменяеться его адрессом при загрузке и обработке правил
>брандмауера)
Так то оно так, только если у сетевой карты есть алиасы (т.е. на сетевую повесили несколько ip-адресов), можно запутаться и впасть в кому, пытаясь узнать, почему же не работает правило файрвола, ведь все вроде правильно (а в итоге оказывается, что правила составляли с учетом не того ip-адреса сетевой, алиасов то было несколько)...
Да и вообще, разве не короче написать rl0 вместо 1.1.1.1. К тому же, ip может поменяться, что повлечет за собой переписку всех существующих правил файрвола. А с именем интерфейса ничего менять не придется.Уфф, все, пошел отдыхать...
А можно я тоже глупый вопрос задам? Всего один, а?
Нужно чтобы пакеты, допустим на 20.20.20.0/24 (но не 20.20.20.2 и 20.20.20.9 ) заворачивались на нат, а все оставшиеся ( включая 20.20.20.(2|9) ) отправлялись сквиду.
Задача усложняется тем, что это нужно делать с таблицами. То есть исключить из таблицы несколько адресов.
>А можно я тоже глупый вопрос задам? Всего один, а?
>Нужно чтобы пакеты, допустим на 20.20.20.0/24 (но не 20.20.20.2 и 20.20.20.9 )
>заворачивались на нат, а все оставшиеся ( включая 20.20.20.(2|9) ) отправлялись
>сквиду.
>Задача усложняется тем, что это нужно делать с таблицами. То есть исключить
>из таблицы несколько адресов.
На сколько тут понятно, то ты предлогаеш создать таблицы адрессов которые потом будут фильтроваться. Не замедлит ли это работу сервера? там ведь 254 АйПи будет?
Я не предлагаю, я спрашиваю.
Мне нужно из таблицы выкинуть несколько адресов.что-то навроде
table 1 add 20.20.20.0/24
table 1 add 30.30.30.0/24
table 2 add 20.20.20.13/32
table 2 add 30.30.30.56/32add pass all from {table(1) ( но исключая ) table(2)} to any
>А можно я тоже глупый вопрос задам? Всего один, а?
>Нужно чтобы пакеты, допустим на 20.20.20.0/24 (но не 20.20.20.2 и 20.20.20.9 )
>заворачивались на нат, а все оставшиеся ( включая 20.20.20.(2|9) ) отправлялись
>сквиду.
>Задача усложняется тем, что это нужно делать с таблицами. То есть исключить
>из таблицы несколько адресов.Зачем именно таблицами?
А такое не поможет? :
ipfw add 100 allow ip from { x or not y or z } to any
где x,y,z - ип-адреса.
в данном примере правило переводится как пропускать ip-трафик с адресов x или z, но не y.Можно пользоваться переменными.
Divert_ok = { 20.20.20.0/24 or not 20.20.20.2 or not 20.20.20.9 }
divert 8668 ip from ${Divert_ok} to any via <интерфейс ната>
>Нужно чтобы пакеты, допустим на 20.20.20.0/24 (но не 20.20.20.2 и 20.20.20.9 )
>заворачивались на нат, а все оставшиеся ( включая 20.20.20.(2|9) ) отправлялись
>сквиду.
А если применить правила логики (дискретка), то под утверждением "все оставшиеся" после первой части предложения будут пониматься только 20.20.20.(2|9). Ведь из множества 20.20.20.0/24 вы исключили два адреса, значит они - и есть "оставшиеся"...
>Зачем именно таблицами?
там список из 20 диапазонов.
>значит они - и есть "оставшиеся"
имелось в виду "прочие адреса включая оставшиеся"
>>Зачем именно таблицами?
>там список из 20 диапазонов.Ну, по крайней мере, правило для заворота на нат для всей сети кроме двоих можно написать с группировкой, как в прошлом посте.
>>значит они - и есть "оставшиеся"
>имелось в виду "прочие адреса включая оставшиеся"
А, понятно. Значит, имелось в виду "прочие адреса из 20 диапазонов плюс два оставшихся адреса, не завернутые на нат"?
>А, понятно. Значит, имелось в виду "прочие адреса из 20 диапазонов плюс
>два оставшихся адреса, не завернутые на нат"?Есть таблица с адресами сетей, подключенных к Нижегородской точке обмена трафиком (IX-NN) http://nnov.vt.ru/?id=6319
некоторые из адресов в него не входят - "213.177.96.0/19 (кроме 213.177.96.6/32, 213.177.96.8/32, 213.177.96.9/32, 213.177.96.221/32 и 213.177.97.26/32)"
Мне нужно просто заворачивать NAT'у все запросы которые идут к кольцу и пересылать на дальнейшую обработку сквиду все остальное.
PS чего-то ругается на add pass all from { 10.10.10.0/24 or not 10.10.10.12} to any
invalid OR block говорит. Совсем торможу уже.
>PS чего-то ругается на add pass all from { 10.10.10.0/24 or not
>10.10.10.12} to any
>invalid OR block говорит. Совсем торможу уже.add pass all from {<пробел>10.10.10.0/24 or not 10.10.10.12<пробел>} to any
Если набираете правило из шелла, то скобки (могут быть как фигурные, так и обычные круглые) лучше зеркалить слэшем, чтобы шелл воспринял это как одну команду, а не как свои собственные конструкции.
С таблицами можно обращаться также, как и с адресами, т.е.
допустим в таблице 100 есть адреса, которые надо заворачивать на нат.
ipfw table 100 add 213.177.96.1
ipfw table 100 add 213.177.96.2
ipfw table 100 add 213.177.96.3
и т.д.
ipfw add divert 8668 ip from table(100) to any
ipfw add fwd 127.0.0.1,3128 tcp from not table(100) to <куда-надо> 80,8080
или ipfw add fwd 127.0.0.1,3128 tcp from { table(99) or not table(100) } to <куда-надо> 80,8080
примерно так...
и про зеркалирование скобок не забудьте.
>Есть таблица с адресами сетей, подключенных к Нижегородской точке обмена трафиком (IX-NN)
>http://nnov.vt.ru/?id=6319
>некоторые из адресов в него не входят - "213.177.96.0/19 (кроме 213.177.96.6/32, 213.177.96.8/32,
>213.177.96.9/32, 213.177.96.221/32 и 213.177.97.26/32)"
>Мне нужно просто заворачивать NAT'у все запросы которые идут к кольцу и
>пересылать на дальнейшую обработку сквиду все остальное.
>PS чего-то ругается на add pass all from { 10.10.10.0/24 or not
>10.10.10.12} to any
>invalid OR block говорит. Совсем торможу уже.
>Я не предлагаю, я спрашиваю.
>Мне нужно из таблицы выкинуть несколько адресов.
>что-то навроде>table 1 add 20.20.20.0/24
>table 1 add 30.30.30.0/24
>table 2 add 20.20.20.13/32
>table 2 add 30.30.30.56/32>add pass all from {table(1) ( но исключая ) table(2)} to any
ааа, блин, я сам торможу.
Можно же сделать так:
в таблице 1 создаем всех, кого будем обрабатывать (адреса сетей полностью).
в таблице 2 создаем исключения из таблицы 1._Сначала_ пишем правила для исключений,
а затем вторым пишем правило для всей сети.
т.е.
>table 1 add 20.20.20.0/24
>table 1 add 30.30.30.0/24
>table 2 add 20.20.20.13/32
>table 2 add 30.30.30.56/32add deny ip from table(2) to any
add allow ip from table(1) to anyиз сетей 20.20.20.0/24 и 30.30.30.0/24 мы пропускаем пакеты, если только они не идут от 20.20.20.13 и 30.30.30.56.
Спасибо, на NOT наплевал, сделал как истинный индийский программистipfw table 100 add 213.177.96.0/19
ipfw table 200 add 213.177.96.2
...
...ipfw add fwd 127.0.0.1,3128 tcp from ${lan} to table(200) 80,8080
ipfw add divert 8668 ip from ${lan} to table(100)
ipfw add fwd 127.0.0.1,3128 tcp from ${lan} to any 80,8080
анекдот...
в архив!!кстати, Pentium4 ускоряет интернет.
хехехе,новички -берите на вооружение,стоит вам обозваться какой нибудь Машей или Дашей, как тут же получаете развернутые ответы(правильные, неправильные, неважно) по любым вопросам
>хехехе,новички -берите на вооружение,стоит вам обозваться какой нибудь Машей или Дашей, как
>тут же получаете развернутые ответы(правильные, неправильные, неважно) по любым вопросамСтоит ожидать бума псевдо-маш-даш...
>хехехе,новички -берите на вооружение,стоит вам обозваться какой нибудь Машей или Дашей, как
>тут же получаете развернутые ответы(правильные, неправильные, неважно) по любым вопросам+1