| |
| 2.3, mma (?), 07:02, 28/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
а вот поэтому и не стоит использовать BSD на шлюзах общего назначения, там с pf сюрпризов ой как много вылазит
| | |
| |
| 3.7, F.Y. (?), 00:26, 29/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>а вот поэтому и не стоит
... а вот по этому и не стоит говорить о чём не ведаешь :)
| | |
| |
| 4.8, mma (?), 08:06, 29/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
ну да, ну да....
SIP и GRE via NAT, route-to и 3-4 линка. Это то что вспомнил с ходу. Сам использую PF(OpenBSD) но только там где заранее знаю требуемый набор функций.
| | |
|
|
|
| 1.2, iZEN (ok), 23:00, 27/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Макросы/переменные нужно выносить в первые строчки!
Флажки "flags S/SA" и "keep state" можно не указывать — оно и так подразумевается по умолчанию.
Конструкцию "block in log all" нужно ставить ПЕРЕД разрешающими правилами, сразу после описания трансляций NAT, и лучше заменить на тупое и беспринципное "block all", когда всё отлажено и логи ни к чему.
Набор правил:
pass in quick on lo0 all
pass out quick on lo0 all
достаточно заменить на одну ОПЦИЮ:
set skip on { lo }
"scrub in all" до описания очередей ОБЯЗАТЕЛЬНО!
| | |
| 1.9, netc (??), 21:52, 29/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 из того, что вспомнил
не работает synproxy на tun интерфейсах, по крайней мере в 7.0-7.2 не работало, а это означает что если повесить на внешний интерфейс(tun) ssh то контроллировать средствами pf атаки bruteforce - не представляеться возможным.
а вообще соглашусь что подводных камней ой как много, лучше использовать ipfw, но он не так "красив" и легок для начинающих.
с работой ftp есть проблемы в определенных режимах
| | |
| |
| 2.13, User294 (ok), 18:33, 30/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> sudo modprobe nf_nat_sip
Некоторым простые решения кажутся неспортивными :-)
| | |
|
| 1.12, Князь (??), 16:41, 30/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Как вариант - натить SIP и GRE трафик с помощью IPFW, а остальное гонять через PF.
З.Ы. Для кричащих "нахрена два фаерволла" - каждый фаер делает то что он умеет, pf - плюшки вроде route-to и reply-to, IPFW - натить проблемный трафик.
| | |
| |
| |
| 3.15, Князь (??), 12:37, 01/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
если покажете как сделать аналог reply-to в ipfw буду век вам благодарен
| | |
| |
| 4.16, Добрый Дохтур (?), 00:49, 02/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
отошлю к статье Вадима Гончарова:
http://nuclight.livejournal.com/124348.html
Тот факт, что на самом деле "перепрыгивание" выполняется на параметры
действия, позволяет использовать это для интересных вещей. В частности, с
использованием появившегося во FreeBSD 6.2 параметра tag на каждый пакет можно
навешивать внутриядерный тег, что в применении со skipto позволяет сделать, к
примеру, запоминание, с какого шлюза пришел входящий пакет на машине с каналами
к двум разным провайдерам, и ответные пакеты отправлять в тот канал, откуда они
пришли (допустим, у вашей машины только один IP-адрес, и сделать fwd на базе
внешнего адреса не получится), т.е. реализовать аналог reply-to из pf:
ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 } # входящие снаружи
ipfw add 400 allow in recv $int_if # разрешить ответы на внутреннем проходе
ipfw add 500 fwd $gw1 tagged 1 # остались ответы на внешнем интерфейсе,
ipfw add 600 fwd $gw2 tagged 2 # зарулим их куда надо
| | |
|
|
|
|