Victor Sudakov wrote:
> Mykola Dzham wrote:
> > > > Попробовал изобразить то же самое на pf вместо ipfw. Только что nat не
> > > > путается под ногами (хотя это большое облегчение на самом деле), а так
> > > > примерно те же яйца.
> > > >
> > > > В freebsd-questions посоветовали использовать в pf тэги ("This can be
> > > > used,
> > > > for example, to provide trust between interfaces"), может с ними
> > > > красивый получится. С другой стороны, в ipfw тоже тэги есть.
> > >
> > > В общем с тэгами наиболее красиво получается. Странно, что сразу в
> > > голову не пришло.
> >
> > Это обманчивое впечатление. Вообще тэги в pf в данном случае это костыль
> > для решения проблемы что в pf в out правиле нельзя проверить через какой
> > интерфейс трафик попал в сервер.
> >
> > > pass in on $dmz from any to any tag FROMDMZ
> > > pass in on $inside from any to any
> > > block out on $inside tagged FROMDMZ
> >
> > Для полной красоты надо было from any to any опустить (pf это позволяет).
>
> Согласен, тем более что парсер всё равно заменяет "from any to any" на "all".
>
> > А так во первых прямым аналогом этих правил на ipfw будет что-то типа
> >
> > permit ip from any to any in recv $dmz
> > permit ip from any to any in recv $inside
> > deny ip from any to any out recv $dmz xmit $inside
>
> У тебя keep-state нет, IMHO твои правила не пропустят возвратный трафик
> из dmz в inside.
Ну да, нужно добавить еще keep-state (который в pf тоже есть, просто
автоматически добавляется)
> >
> > Что, менее красиво? по моему один фиг.
>
> Это пока не начнешь голову ломать, куда бы теперь приткнуть nat и
> keep-state.
keep-state в конце правил, nat там, где надо натить. Ничего сложного там
нет.
Вот когда что-то пытаешься приткнуть в pf, вот тогда точно сломаешь
голову. nat еще ладно, а шейп нарисовать это будет полный капец. Начнем
с того, что tag в pf обязательно требует keep state. queue из правила,
создающего state, запоминается в динамическом правиле. В результате
добавить в эту схему с tag элементерное: раздельный шейп на трафик
изнутри наружу и на трафик снаружи внутрь становится не реально.
> > А во вторых эти правила не описывают поведение pix с тремя интерфейсами.
>
> Ну вот эти вроде уже описывают:
>
>
> pass in on $dmz tag FROMDMZ
> pass in on $inside
> block out on $inside tagged FROMDMZ
> block in on $outside all
> pass out on $outside all
>
> Правила типа "pass in on $outside proto tcp ..." расставить по вкусу.
Я бы не писал вперемешу in и out правила - все-равно на входе будут
проверяться только in правила, а на выходе только out, но в то же время
такой перемешанные порядок создаёт ложное впечатление что пакет будет
проверяться по этим правилам последовательно, как они написаны.
Эти правила переводятся практически дословно на ipfw, только без
костылей с tag, а прямым указанием recv <ifname> xmit <ifname>
--
LEFT-(UANIC|RIPE)
JID: [email protected]
PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
