NAT и исходная IP-фильтрация в PF с использованием OpenBSD> = 4.7

Я только что прочитал книгу о ПФ (Книга ПФ, без крахмала), но есть один вопрос, на который он не ответил.

Если у меня есть компьютер шлюза, использующий два интерфейса, $ int_if и $ ext_if, и я NAT пакеты, идущие от $ int_if: net (который, скажем, 10.0.0.0/24) к $ ext_if, используя match, когда применяется NAT ? До или после правил фильтрации?

Пример:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
pass out on $ext_if from 10.0.0.0/24
block drop out on $ext_if from 10.0.0.23

Это работает? Или получает исходный IP-адрес пакета, пришедшего с 10.0.0.23 NAT, по адресу $ ext_if до того, как будет проверена проверка, что он с 10.0.0.23?

Думаю, эта диаграмма не поможет ответить на этот вопрос, но, тем не менее, она интересна: [ http://www.benzedrine.cx/pf_flow.png ]

Если вы прочитаете FAQ по PF NAT [ http://www.openbsd.org/faq/pf/nat.html ], особенно раздел «Настройка NAT», вы увидите следующие предложения:

Когда пакет выбирается правилом соответствия, параметры (например, nat-to) в этом правиле запоминаются и применяются к пакету, когда достигается правило прохода, соответствующее пакету. Это позволяет обрабатывать целый класс пакетов одним правилом сопоставления, а затем конкретные решения о том, разрешать ли трафик, могут приниматься с помощью правил блокировки и прохождения.

Я думаю, это звучит так, как будто это не так, как я указывал в предыдущем параграфе, поэтому исходный IP-адрес «запоминается» до тех пор, пока не будет принято решение о действии, которое должно быть выполнено с пакетом. Если решение принято, применяется NATting.

Что вы думаете?

PS: это довольно теоретический вопрос. Если вы немного прагматичны, вы сделаете это так:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop from 10.0.0.23
# or, explicitly,
# block drop in on $int_if from 10.0.0.23

Таким образом, blockправило уже применяется, когда пакет входит в $ int_if.

РЕДАКТИРОВАТЬ: Другая возможность, конечно, решить до NAT:

pass from 10.0.0.0/24
block drop from 10.0.0.23
match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)

Если приходит пакет из .23, он сначала соответствует первому правилу, затем соответствует второму правилу и третьему «правилу». Но так как второе правило является последним при принятии решения о передаче / блокировке, пакет блокируется. Правильно?

Да, это довольно теоретически, как вы и просили, но очень интересный вопрос.

matchПравило будет получить применяется , когда он действует на последнем правиле согласования. matchправила "липкие", как вы упомянули. Основное их назначение - иметь возможность устанавливать такие вещи, как правило NAT, и при этом не нужно помещать nat-to в конец набора правил, касающихся вашего исходящего трафика.

В вашем примере пакет будет сброшен. Я должен был бы взглянуть на код или попросить Хеннинга Брауэра быть уверенным, что они полностью пропустят проверку NAT в случае сброса, но она не вылетит.

Я думаю , что ваше правило будет покрыто Книгой PF (получил 2 - е издание?), Но я не думаю , что они явно об этом с правилом соответствия.

Пожалуйста, исправьте меня, если я ошибся, вы хотите передать все исходящие пакеты с 10.0.0.0/24, но хотите заблокировать 10.0.0.23? Если это так, измените ваше правило на:

match out on $ext_if from 10.0.0.0/24 nat-to ($ext_if)
block drop out quick on $ext_if from 10.0.0.23
pass out on $ext_if from 10.0.0.0/24

Просто используйте quickдля предотвращения продолжения фильтрации брандмауэром (аналогично breakнекоторым языкам программирования).

http://www.openbsd.org/faq/pf/filter.html#quick

Быстрое ключевое слово

Как указывалось ранее, каждый пакет оценивается по набору правил фильтрации сверху вниз. По умолчанию пакет помечен для прохождения, который может быть изменен любым правилом и может быть изменен несколько раз до конца правил фильтрации. Последнее подходящее правило «выигрывает». Есть исключение: быстрый параметр правила фильтрации приводит к отмене любой дальнейшей обработки правила и вызывает выполнение указанного действия. Давайте посмотрим на пару примеров:

Неправильно:

block in on fxp0 proto tcp to port ssh
pass  in all 

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

Лучше:

block in quick on fxp0 proto tcp to port ssh
pass  in all 

Эти правила оцениваются немного по-другому. Если строка блока совпадает, из-за быстрой опции пакет будет заблокирован, а остальная часть набора правил будет проигнорирована.