Subnets.ru

День добрый!

Есть вопросик который спать не дает по ночам, фаервол на pf, а в pf нельзя задать ng*, как например в ipfw:

Код: Выделить всё

$ipfw add pass ip from any to any in recv ng*
$ipfw add pass ip from any to any out xmit ng*

, приходится извращаться в mpd с if-up и if-down скриптами типа:

Код: Выделить всё

#!/bin/sh
echo "pass quick on $1 all" | pfctl -a PPPoE/$1 -f -

и

Код: Выделить всё

#!/bin/sh
pfctl -a PPPoE/$1 -F rules


Так вот в якоре получается куча правил, а если их не 10 и не 100, а где-нить с 1000 будет, читал что pf оптимизирует прохождение по правилам, но все же интересна как будет расти нагрузка от количества правил. Может кто использует данную схему?

Привет!

Увы, PF в продакшене мы перестали использовать уже как года два (у нас сейчас все работает на ipfw), соответственно, и сказать мне на эту тему нечего

borin писал(а):фаервол на pf, а в pf нельзя задать ng*

нельзя, сколько раз перелистывал маны PF, столько раз убежданся что этого там нет

borin писал(а):приходится извращаться в mpd с if-up и if-down скриптами

именно так все и делают - через таблицы в PF

lehisnoe писал(а):PF в продакшене мы перестали использовать уже как года два (у нас сейчас все работает на ipfw)

ага, в этом плане ipfw практичнее и понятнее чем PF. ИМХО.

а в чем проблема пользовать это для pfctl:

-t vpn -T add UIP/UBITS - добавить разрешение для ng_IP/32 (или какая у вас маска)

-t vpn -T delete UIP/UBITS - удалить разрешение для ng_IP/32 (или какая у вас маска)

И определяем таблицу в pf.conf:

Код: Выделить всё

table <vpn> persist

один и кривописателей биллинга пользует такое. Даже в у них доке это есть. Вот только их программулина криво работает с файрволлом. Через костыль именуемый sudo.

Да и вам надо демона, который бы от радиуса получал верные установки - открыть сессию или нет и передвал в управление pf, опять же, если сессий ожидается много.

Андрей писал(а):а в чем проблема пользовать это для pfctl:

-t vpn -T add UIP/UBITS - добавить разрешение для ng_IP/32 (или какая у вас маска)

-t vpn -T delete UIP/UBITS - удалить разрешение для ng_IP/32 (или какая у вас маска)

И определяем таблицу в pf.conf:

Код: Выделить всё

table <vpn> persist

один и кривописателей биллинга пользует такое. Даже в у них доке это есть. Вот только их программулина криво работает с файрволлом. Через костыль именуемый sudo.

Да и вам надо демона, который бы от радиуса получал верные установки - открыть сессию или нет и передвал в управление pf, опять же, если сессий ожидается много.

Думал про это уже, но отсутствие привязки к интерфейсу думаю не совсем гуд будет.

root писал(а):нельзя, сколько раз перелистывал маны PF, столько раз убежданся что этого там нет

Pf хорош, но отсутствием группировки интерфейсов (почему не реализовать столько удобную фишку, не понятно ), в данной конкретной ситуации однозначно сливает ipfw.

lehisnoe писал(а):Увы, PF в продакшене мы перестали использовать уже как года два (у нас сейчас все работает на ipfw), соответственно, и сказать мне на эту тему нечего

root писал(а):ага, в этом плане ipfw практичнее и понятнее чем PF. ИМХО.

Вот тоже думаю ipfw использовать на шлюзе. Правила одинаково просто писать, что для pf, что для ipfw. Нормализация пакетов, вроде красиво написано, насколько реально оно помогает не известно, опять же как то и без нормализации люди обходятся. Кстати попутно вопрос, блокировать или нет фрагментированные пакеты на шлюзе или нет?

borin писал(а):Думал про это уже, но отсутствие привязки к интерфейсу думаю не совсем гуд будет.

Может я чего не понял, но mpd5, в прочем как и вся линейка mpd, не предполагает закрепление определенного ng ифейса за определенным ip, да и нерационально это.

borin писал(а):Нормализация пакетов, вроде красиво написано, насколько реально оно помогает не известно, опять же как то и без нормализации люди обходятся.

Только не на сервере доступа. Политика нормализации пакетов похожа больше на некие ограничения. А вот их потом уже надо подгонять под себя.
Без нормализации я обойтись не смог, а вот без настройки sysctl пока обхожусь.

У самого 2 сервера доступа, на обоих mpd5 + pf + pf(nat). Ко всему этому есть еще 2 сервера, которые смотрят в инет и на них тоже собран pf.

borin писал(а):Кстати попутно вопрос, блокировать или нет фрагментированные пакеты на шлюзе или нет?

Мы спецом не блочим фраги, но и не реассемблим пакеты (т.е. у юзов с реальниками все хорошо, а серые адреса за натом с фрагами обломываются).

Андрей писал(а):Может я чего не понял, но mpd5, в прочем как и вся линейка mpd, не предполагает закрепление определенного ng ифейса за определенным ip, да и нерационально это.

Я про то что в ipfw можно забить всего два правила:

Код: Выделить всё

$ipfw add pass ip from any to any in recv ng*
$ipfw add pass ip from any to any out xmit ng*

и все mpd5 создает интерфейс, пользователь получает доступ в интернет, ни надо ни каких костылей, а в pf к сожелению такого функционала нет.

borin писал(а):Я про то что в ipfw можно забить всего два правила:

Код: Выделить всё

$ipfw add pass ip from any to any in recv ng*
$ipfw add pass ip from any to any out xmit ng*

Объясните что делают эти правила? В ipfw я не силен.

Андрей писал(а):

borin писал(а):Я про то что в ipfw можно забить всего два правила:

Код: Выделить всё

$ipfw add pass ip from any to any in recv ng*
$ipfw add pass ip from any to any out xmit ng*

Объясните что делают эти правила? В ipfw я не силен.

1) Разрешить любой пакет неважно откуда и куда, если это входящий пакет, полученный с интерфейса ng* (где ng*, любой ng, тобишь ng0 ng1 ng2....)
2) Разрешить любой пакет неважно откуда и куда, если это исходящий пакет, отправленный ng* интерфейсом

как то так, грубо говоря разрешаем трафик на ng* интерфейсе.