The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Имя интерфейса в качестве параметра фильтрации пакетов pfSense, !*! trng, 24-Июн-20, 18:54  [смотреть все]
Здравствуйте,

Не могу понять аналогию для одного и того же правила в iptables и pfSense.

Правило в iptables:

# Enable LAN to WAN forward
iptables -A FORWARD -i $LANiface -o $WANiface -j ACCEPT


При этом в правилах файровола pfSense нет понятия "output interface".
source/destination - это ip-адреса из соответствующих полей заголовка ip-пакета попавшего в фильтр.

Опция
pfctl -i имя_интерфейса
это не фильтр по источниюку/приемнику пакета, а привязка правила к определенному интерфейсу (без привязки к направлению движения).


Понятно что в pfSense то же самое реализуется но другими правилами (используя source/destination).
Непонятно почему в pf нельзя фильровать пакеты по "получателю" в виде интерфейса, а не в виде ip-адреса.

  • Имя интерфейса в качестве параметра фильтрации пакетов pfSense, !*! муу, 22:12 , 24-Июн-20 (1)
    1) не пытайся накладывать линуксовые мерки на бсдю, бсд другая совсем, я сам этим страдал пока не понял - что если работаешь с бсд - линуксовые привычки надо просто отбрасывать в сторону и забывать на время работы с бсд.

    2) в голом pf можно указывать интерфейс и направление, как там это делается в pfsense, я не в куГсе, юзаю только голую фрю и ipfw.
    что-то вроде
    pass out on igb0 proto tcp и-далее-по-вкусу


  • Имя интерфейса в качестве параметра фильтрации пакетов pfSense, !*! Аноним, 15:47 , 25-Июн-20 (2)
    > Здравствуйте,
    > Не могу понять аналогию для одного и того же правила в iptables
    > и pfSense.

    Файрволы linux и bsd устроены по-разному

    > Правило в iptables:
    > # Enable LAN to WAN forward
    > iptables -A FORWARD -i $LANiface -o $WANiface -j ACCEPT

    Примерно так это выглядит

    rc.conf

    gateway_enable="YES"

    pf.conf

    ext_if="em0"
    int_if="em1"

    block all
    pass out on $ext_if keep state
    pass out on $int_if keep state

    в bsd нет цепочки forward. У каждого интерфейса есть in и out, что у одного на out, может быть у другого на in и наоборот. Параметр gateway_enable задается либо в rc.conf либо через sysctl, он и определяет, разрешено ли пакетам гулять между интерфейсами (forward)

    > Непонятно почему в pf нельзя фильровать пакеты по "получателю" в виде интерфейса,
    > а не в виде ip-адреса.

    Задачу свою опиши, а то может, опять сову на глобус натягиваешь.

    • Имя интерфейса в качестве параметра фильтрации пакетов pfSense, !*! trng, 23:09 , 25-Июн-20 (3)
      > в bsd нет цепочки forward.

      Понял! Спасибо! Именно этого слона я и не заметил (отсутствие цепочки forward).


      > pass out on $ext_if keep state
      > pass out on $int_if keep state

      Для "pass out on xxx" в GUI pfSense-а предусмотрены "Floating rules"
      Попробовал. не подходит для моей задачи (ниже)


      > Задачу свою опиши, а то может, опять сову на глобус натягиваешь.

      ========== Задача ==============
      В офисе ~15 vlan-ов. На шлюзе они распределены между тремя физическими сетевушками.
      Все должны ходить в интернет и никто не должнен ходить друг к другу (за редкими исключениями под которые прописаны отдельные правила для каждого конкретного source/destination).
      Локальные сервера, которые должны быть видны во всех (или в некоторых) vlan-ах собраны в отдельную подсеть. Под каждый сервер прописаны свои правила (либо nat1:1, либо фильтр по source/destination с указанием портов).

      На шлюзе два WAN (два провайдера). Под них сделана "Gateway Group" (load balancing).

      Кроме того, поднят OpenVPN-сервер для "удаленщиков" (в основном для проброса RDP)

      ================================

      Собственно почему я интересуюсь in-out фильтрацией.
      В pfSense для доступа в интернет на каждом VLAN обязательно прописывается правило где destination "any" (последнее в ruleset каждого из vlan).

      pass in quick on igb0.8 inet from 192.168.8.0/24 to any flags S/SA keep state label "USER_RULE: from vlan8 to world"
      pass in quick on igb1.4 inet from 192.168.4.0/24 to any flags S/SA keep state label "USER_RULE: from vlan4 to world"

      Но! "to any" подразумевает и локальные vlan-ы тоже.
      Поэтому для каждого vlan прописывается дополнительное правило, запрещающее "локальный роутинг"
      ...
      block drop in quick on igb0.8 inet from any to <All_LAN_Networks> label "USER_RULE"
      block drop in quick on igb0.8 inet6 from any to <All_LAN_Networks> label "USER_RULE"
      block drop in quick on igb1.4 inet from any to <All_LAN_Networks> label "USER_RULE"
      block drop in quick on igb1.4 inet6 from any to <All_LAN_Networks> label "USER_RULE"
      ...
      и так далее для каждого vlan.

      <All_LAN_Networks> - алиас в котором перечислены все локальные подсети.


      Аналогично (из за того же "to any") приходится отдельными правилами блокировать доступ к самому шлюзу (вебинтерфейс и т.п.). А потом делать исключения из этих блокировок (локальный dns например).


      В результате одно простое линуксовое правило
      iptables -A FORWARD -i $LANiface -o $WANiface -j ACCEPT

      разрастается в минимум 4-5 правил pf.
      И все потому (насколько я понял), что в pf нет цепочки forward.

      Соответственно, правило
      pass out on $int_if keep state

      тоже не очень подходит, потому что они слишком много разрешает.

      Как то так.
      Или я опять какого то слона пропустил?





Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру