|
| 1.2, sunTechnic (?), 17:26, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Во Фре есть очень полезная фича: переименование сетевых интерфейсов, так, например, {iif} и {oif} лучше сразу писать типа internal, external.
Делается это в /etc/rc.conf так:
ifconfig_em0_name="internal"
ifconfig_em1_name="external"
Это удобно тем, что вне зависимости какого производителя у вас карточка и на какую вы её в случае чего замените, вам потребуется поменять всего лишь обозначение в /etc/rc.conf, а не отлавливать все скрипты на предмет изменения названия интерфейса.
Плюс размещение в файле строчек типа:
${fwcmd} add allow ip from any to ${MyLan} in via {oif}
не очень удобно в плане дальнейшего модифицирования файрволла на ходу без перезагрузки всех правил, гораздо удобнее всё-таки писать /sbin/ipfw вместо {fwcmd} (благо его не часто переносят):
/sbin/ipfw table 1 add 10.10.10.0/24
/sbin/ipfw add allow ip from any to table(1) in via external
Таким образом можно после редактирования файлика сразу исполнить эту строчку и тем самым добавить в файрволл новое правило.
Всё ИМХО, основанное на продолжительном опыте эксплуатации фри в качестве роутера.
| | |
| |
| 2.3, B.O.B.A.H. (??), 20:06, 24/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
а почему народ не любит стандартный
/etc/rc.firewall
и старается писать свои правила?
| | |
| |
| 3.13, Дмитрий Ю. Карпов (?), 11:19, 25/10/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Например, в /etc/rc.firewall адреса внутренней сетИ заданы внутри скрипта, а их надо задавать в /etc/rc.conf - этого уже достаточно, чтобы делать свой набор правил.
А вот подгружать правила из текстового файла тоже не очень хорошо, т.к. конструкция с проверкой необходимости natd очень разумна, и $natd_interface берётя из /etc/rc.conf.
| | |
|
| 2.11, JJF (?), 09:16, 25/10/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Во Фре есть очень полезная фича: переименование сетевых интерфейсов
Это таки хорошая фича, да, но есть одно но (не знаю, пофиксили ли это в 7 ветке, но на 6.2 этот баг все еще есть) - NETGRAPH очень странно работает с переименованными интерфейсами. Например, у меня mpd категорически отказывается подключаться по pppoe через переименованный интерфейс. Погуглил - оказалось, таки да. Судя по всему, валится ng_ether, который собран с ядром. По идее, его нужно подгружать уже после переименования интерфейса, тогда может быть все и будет нормально, но пока руки не дошли проверить. Кто-то уже боролся?
| | |
| |
| |
| 4.22, JJF (?), 11:51, 26/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
Так я об этом же и говорю.
Но все равно это своеобразный косяк, с которым еще попританцовывать надо. Может быть кому-то и пригодится, потому как в нете не сильно много об этой проблеме написано.
| | |
|
|
|
| 1.4, Аноним (4), 20:32, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Замечание к статье.
В /etc/rc.conf в firewall_type="" можно указать просто имя файла, из которого стандартный rc.firewall и считает правила, и в самом rc.firewall ничего править не нужно.
| | |
| 1.5, belkin (?), 20:35, 24/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
В очередной раз можно сказать "читайте man" (man ipfw) - лучший источник знаний.
1. Правила загружать правильней не скриптом, который для добавления каждого правила вызывает ipfw, а из текстового файла: /sbin/ipfw /etc/ipfwrules.txt.
2. Для сложных случаев с переменными пользуемся препроцессором:
/sbin/ipfw -p /usr/bin/m4 /etc/ipfwrules.m4 .
| | |
| |
| 2.6, sk (??), 20:44, 24/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
 а если маленькая ошибочка в этом текстовом файле?
по умолчанию таки в виде скрипта все сделано. Разработчики кто по вашему тогда? идиоты чтоль? ;)
| | |
| |
| 3.7, belkin (?), 21:14, 24/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>а если маленькая ошибочка в этом текстовом файле?
>по умолчанию таки в виде скрипта все сделано. Разработчики кто по вашему
>тогда? идиоты чтоль? ;)
Разработчики чего ? Скрипта rc.firewall ?
А если ошибочка в скрипте - тогда что делать ?
Читаем man ipfw и узнаём о ipfw -n . Позволяет проверить правила без реальной загрузки.
| | |
| 3.8, SunTech (?), 22:16, 24/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
Для этого есть set, сначала правила загружаются в неактивный, потом проверяются, потом он делается активным. Есть пример в examples
| | |
| |
| 4.9, Просто человек (?), 03:27, 25/10/2007 [^] [^^] [^^^] [ответить]
| +/– | |
ммм....у меня к ночи мозги клинят или я непойму....откуда в правилах 7 и 8 айпишники внутренней сетки появяться на внешнем интерфейсе?
| | |
|
|
| 2.24, northbear (??), 18:48, 26/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>2. Для сложных случаев с переменными пользуемся препроцессором:
>/sbin/ipfw -p /usr/bin/m4 /etc/ipfwrules.m4 .
Только не m4... в прочем если вы используете sendmail и в ручную пишите sendmail.cf, то m4 вам понравится.
| | |
|
| 1.10, nuclight (?), 06:41, 25/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Автор, как всегда, в своем репертуаре... Экспериментально устанавливал, что происходит с пакетом после divert, тогда как это есть в мане, даже в двух - и divert(4), и natd(8)/
| | |
| |
| 2.25, cat (??), 10:17, 27/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Автор, как всегда, в своем репертуаре...
Мы не знакомы, это моя первая статья чтобы говорить о моём репертуаре.
Очень рад что заставил лишний раз перечитать MAN.
| | |
|
| 1.15, Аноним (15), 13:52, 25/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Да ладно вам автору респект - я сам часто методом научного тыка все пытаюсь выявить а уж если совсе бяд -вот тогда мана. Да я уверен что 70% админов сами с усами...народ у нас такой...
| | |
| 1.16, Осторожный (?), 18:17, 25/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не в тему.
Если уж начали изучать firewall-ы на FreeBSD то
лучше СРАЗУ изучайте pf !
После него на ipfw,iptables смотреть даже не будете :)
Вот только с документацией и примерами не густо но есть хорошие статьи про pf для OpenBSD ( со списком отличий в FreeBSD )
| | |
| |
| 2.17, belkin (?), 21:54, 25/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Не в тему.
>Если уж начали изучать firewall-ы на FreeBSD то
>лучше СРАЗУ изучайте pf !
>После него на ipfw,iptables смотреть даже не будете :)
>Вот только с документацией и примерами не густо но есть хорошие статьи
>про pf для OpenBSD ( со списком отличий в FreeBSD )
>
Не всё так как кажется.
1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.
Ну и ещё всякое разное.
| | |
| |
| 3.19, Serg (??), 04:22, 26/10/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> 1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
Ничего не понял, как это скриптами запуска? А при старте ядра загрузить модуль религия не дает?
> 2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
Аналогично и в pf
> 3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.
PF замечательно умеет делить канал как вашей душе угодно.
Ничего не имею против IPFW, но прежде чем говорить что какая-то из служб что-то не умеет все же стоит документацию хотя бы глянуть.
Оба фильтра замечательно выполняют свои функции, и могут полностью заменить друг друга.
Тут дело вкуса, и кто к чему привык/лучше знает.
| | |
| |
| 4.20, raistlin (??), 09:38, 26/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Уважаемый серг, а какая-нить альтернатива natd есть в OpenBSD? Я согласен что, ПФ Опенка гораздо приятнее ipfw, но вот када нада извраты с натд...
| | |
| |
| 5.26, cadmi (?), 09:11, 28/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Уважаемый серг, а какая-нить альтернатива natd есть в OpenBSD? Я согласен что,
>ПФ Опенка гораздо приятнее ipfw, но вот када нада извраты с
>натд...
там слава богу нет этого угребищного natd, там nat в ядре и сделан прямыми руками, в отличие от возни с divert и левой программой, которая поднимается отдельно.
| | |
|
| 4.21, belkin (?), 10:39, 26/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> 1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
>
>Ничего не понял, как это скриптами запуска? А при старте ядра загрузить
>модуль религия не дает?
Если PF по каким-либо причинам не загрузится, то будет дыра. Без IPFW в таких случаях будет Deny All.
>> 2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
>
>Аналогично и в pf
"Удобно".
>
>> 3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.
>
>PF замечательно умеет делить канал как вашей душе угодно.
pipe 1 config bw 10Mbit/s
pipe 2 config bw 10Mbit/s
pipe 3 config bw 768Kbit/s mask dst-ip 0xFFFFFFFF
queue 1 config pipe 1 mask src-ip 0xFFFFFFFF
queue 2 config pipe 2 mask dst-ip 0xFFFFFFFF
add pipe 3 all from 192.168.15.1 to any src-port 3128 out
add queue 1 all from any to any out xmit vlan0
add queue 2 all from 192.168.15.1 to any out
Для каждого клиентского IP-адреса по маске динамически создаёт по одной очереди в каждом направлении и справедливо распределяет пропускную способность между ними не требуя указания пропускной способности канала Internet. Сделайте подобное на FreeBSD с помощью PF.
>Ничего не имею против IPFW, но прежде чем говорить что какая-то из
>служб что-то не умеет все же стоит документацию хотя бы глянуть.
Это вы товарищу Осторожный скажите. Я ему хотел сказать, что если он не знает недостатки PF значит он его плохо знает.
>Оба фильтра замечательно выполняют свои функции, и могут полностью заменить друг друга.
Отличия есть и потому использую оба в разных ситуациях.
>Тут дело вкуса, и кто к чему привык/лучше знает.
Не согласен. Знать надо оба три :-) (ipfw,pf,ipf) чтобы выбрать и использовать лучшее или более подходящее к конкретной ситуации.
| | |
|
|
|
| |
| |
| 3.28, DaemonBSD (?), 10:51, 05/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Эта "лажа" как раз и работает без всяких проблем.
А если у Вас есть Ваша "не лажа" - будьте добры поделиться с остальными (В чем я сильно сомневаюсь ...)
| | |
|
|
|
