LINUX.ORG.RU
ФорумAdmin

Pfsense внутри Proxmox

 , , ,


0

1

Привет!

Возникла непонятная ситуация, над которой я сломал уже всю голову и, скорее всего, судя по отсутствию результата, не замечаю чего-то очевидного, посему прошу коллективный разум о помощи.

Есть сервер с двумя сетевыми картами, на нём стоит proxmox, в proxmox в kvm-виртуалку проброшены бриджи: vmbr0, который на хосте является eth0, и имеет внутренний адрес сети и vmbr1(eth1), для которого адрес не настроен и который предполагается использовать для внешнего адреса в proxmox:

[root@proxmox ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
vmbr0           8000.0cc47a40c1f8       no              eth0
                                                        tap101i1
vmbr1           8000.0cc47a40c1f9       no              eth1
                                                        tap101i0
[root@proxmox ~]# cat /etc/network/interfaces
# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto vmbr0
iface vmbr0 inet static
        address  10.0.70.4
        netmask  255.255.255.0
#       gateway  10.0.70.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0

auto vmbr1
iface vmbr1 inet manual
        bridge_ports eth1
        bridge_stp off
        bridge_fd 0


В KVM для сетевых карт используются драйверы vitio, конфигурация имеет следующий вид:

[2.2-RELEASE][root@pfSense.localdomain]/root: ifconfig
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6c00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether ea:17:c5:2e:7b:dc
        inet6 fe80::e817:c5ff:fe2e:7bdc%vtnet0 prefixlen 64 scopeid 0x1
        inet XXX.XXX.XX2 netmask 0xfffffff8 broadcast XXX.XXX.XX7
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
vtnet1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6c00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 22:ea:8a:16:73:0f
        inet6 fe80::20ea:8aff:fe16:730f%vtnet1 prefixlen 64 scopeid 0x2
        inet 10.0.70.3 netmask 0xffffff00 broadcast 10.0.70.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
pflog0: flags=100<PROMISC> metric 0 mtu 33172
pfsync0: flags=0<> metric 0 mtu 1500
        syncpeer: 224.0.0.240 maxupd: 128 defer: on
        syncok: 1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0<> metric 0 mtu 1536
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>


Вообще, то что я организовываю, практически 1 в 1 совпадает со схемой в https://forum.pfsense.org/index.php?topic=50013.0

Pfsense как роутер работает без проблем, но возникло дикое непонимание того, как там устроен NAT. Для начала давайте попробуем разобраться в некоторых простых ситуациях. Во всех них есть proxmox-хост (PM) с адресом 10.0.70.4, pfsense (PF) в нём, с внутренним интерфейсом 10.0.70.3 и внешним интерфейсом XXX.XXX.XXX.XXX и компьютер в локальной сети(userhost) с адресом 10.0.70.118. Настройки PF практически из-коробки, только отключён ipv6, на всякий случай отключены блокировки bogon networks и private networks

Маршруты на PM:

[root@proxmox ~]# ip r
10.0.70.0/24 dev vmbr0  proto kernel  scope link  src 10.0.70.4

на PF:

[2.2-RELEASE][root@pfSense.localdomain]/root: netstat -r
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            XXX.XXX.XXX      UGS      vtnet0
10.0.70.0          link#2             U        vtnet1
pfSense            link#2             UHS         lo0
localhost          link#5             UH          lo0
XXX.XXX.XX0/29   link#1             U        vtnet0
XXX.XXX.XX2      link#1             UHS         lo0

на userhost:

$ ip r
default via 10.0.70.3 dev eth0
10.0.70.0/24 dev eth0  proto kernel  scope link  src 10.0.70.118  metric 1

Таблицы файрволлов на PM и userhost пусты.

1. Я хочу пробросить порт 22 с userhost на внутренний адрес шлюза, на такой же порт, pfctl эта запись выглядит так:

nat on vtnet1 inet proto tcp from 10.0.70.0/24 to 10.0.70.118 port = ssh -> (vtnet1) round-robin

Всё хорошо, nmap показывает, что порт открыт, подключение работает.

Теперь я хочу пробросить 22 порт с userhost на порт шлюза 4022:

http://i.imgur.com/aNLxG6m.png

nat on vtnet1 inet proto tcp from 10.0.70.0/24 to 10.0.70.118 port = 4022 -> (vtnet1) round-robin rdr on vtnet1 inet proto tcp from any to any port = 4022 -> 10.0.70.118 port 22

И вот первая фигня: 4022 порт не виден, не открывается. В pfsense есть умолчательно правило, разрешающее всё на всё внутри локальной сети, отдельное правило было добавлено автоматом при создании перенаправления:

http://i.imgur.com/9KfHNia.png

Что делать?

2. Но вообще-то надо пробросить порт на внешний интерфейс, делаю всё то же самое, но теперь для WAN:

http://i.imgur.com/eqMdhYJ.png

Не работает.

Со словами “может я совсем дурак?” отдельно открываю ssh на WAN:

http://i.imgur.com/iIfWxmx.png

Не работает.

Психанув, создаю ещё правило, разрешающее на WAN всё:

http://i.imgur.com/H10d2Sn.png

Работает.

Меняю на WAN пробрашиваемый порт с 22 на 4022 - работает.

Пробую сделать подобное для LAN (22-4022) - не работает.

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

В итоге получается два вопроса:

- Что нужно чтобы перенаправить порты (22-4022) внутри локалки?

- Как правильно сделать перенаправление на WAN не открывая жопу всему миру всех портов?

ЗЫ: Поведедение повторяется на pfsense 2.1.5 и 2.2

casr val-amart за тему Виртуальный роутер под KVM - как настроить сеть? (комментарий)

Окосевая иду спать.

По пробросу из LAN в LAN у вас вышла обычная асимметричная маршрутизация:

lanhost -> pfsense -> userhost -> ??? Как и любой SPI-firewall, pfSense желает видеть и прямые и обратные пакеты, иначе связи не будет. У вас же обратные пакеты летят напрямую от userhost к lanhost. Чтобы все работало, нужно делать Outbound NAT на vtnet1:

Interface: LAN Protocol: TCP Source: 10.0.70.0/24 Destination address: 10.0.70.118/32 Destination port: 22 Translation: Interface address

- теперь пакеты на userhost будут попадать с адресом источника = IP LAN и обратные пакеты тоже пойдут через pfSense.

Вот эта вот штуковина, которую pfSense создает сама при пробросе порта:

nat on vtnet1 inet proto tcp from 10.0.70.0/24 to 10.0.70.118 port = 4022 -> (vtnet1) round-robin

- она либо вообще не о том, либо таки о том, но тогда это баг, ибо порт в ней должен быть не 4022, а 22, т.к. к моменту работы NAT Port Forward уже сделал свое чиорное дело.

rubic ()

Стесняюсь спросить, зачем нужен велосипед для iptables для проброса 2-4 портов? В iptables это было бы сделано за 1 минуту.

invokercd ★★★★ ()

Рубик в целом правильно все обьяснил. Насчет проброса на внешнем интерфейсе: в нормальном пф'е, в нормальном openbsd, это делается так:

pass in on vtnet1 proto tcp to any port ssh rdr-to 10.0.70.118

теперь весь вопрос как это повторить на pfsense. честно, не знаю — pfsense это дикая модификация дикого (и очень старого!) фрибсдшного порта пф'а, который у них всегда вообще работал как-то не так. тебе в сущности надо две вещи: сам редирект и pass in для нужного порта.

предлогаю состредоточиться на внешнем интерфейсе — я так понимаю на внутреннем это все игры с целью разобраться и попробовать, и в реальности использоваться не будет? если будет, надо либо транслировать source address, как предложил Рубик, либо делать no-state или sloppy-state. а лучше всего использовать другую подсеть.

для внешнего интерфейса: ты можешь показать `pfctl -s rules`?

val-amart ★★★★★ ()

Зачем в pfSense задавать настройки руками через pfctl, в обход системного конфигуратора и web-морды? Не проще ли тогда уж поставить голую *BSD?

whoami ()
Ответ на: комментарий от rubic

Ага! Стало понятно, почему проброс 4022-22 WAN-LAN работал, а проброс LAN-LAN нет,

в outbound nat были дефолтные правила:

http://wstaw.org/m/2015/02/18/plasma-desktopzo2313.png

Добавление правила по образу и подобию для LAN решило проблему.

overmind88 ★★★★★ ()
Ответ на: комментарий от invokercd

Сейчас как раз всё с iptables работает и есть не просит, но хочется же узнать, где собака порылась.

overmind88 ★★★★★ ()
Ответ на: комментарий от whoami

Я задавал всё через веб-морду, строчки из pfctl приводил для облегчения разбора.

overmind88 ★★★★★ ()
Ответ на: комментарий от overmind88

Вы могли сделать проброс WAN-LAN и включить в правиле NAT Reflection. В этом случае обращение к WAN адресу из LAN вело бы к тому же пробросу из LAN в LAN.

pfSense - это компромисс между простотой конфигурирования и сложностью подлежащих сетевых дел. Нужно вникать в существующие практики. Нести свое понимание - плохая идея. Там столько всего делается неявно для «пользы» пользователя, что продвинутых все это обычно ставит в тупик. Для начинающих же - неоценимая польза))

rubic ()
Ответ на: комментарий от rubic

Вы могли сделать проброс WAN-LAN и включить в правиле NAT Reflection

Разобраться с работой nat reflection это следующее, чем я хотел заняться :)

Там столько всего делается неявно для «пользы» пользователя, что продвинутых все это обычно ставит в тупик. Для начинающих же - неоценимая польза))

У меня как раз стоит задача настроить и чтобы потом технически грамотные, но далёкие от линуксов и сетей люди могли, если что, обойтись без меня.

overmind88 ★★★★★ ()
Ответ на: комментарий от val-amart

А вот не могли бы вы пояснить на какой версии pf OpenBSD и FreeBSD разошлись? Это без всякого сарказма вопрос, информацию трудно найти. Что изменилось принципиально с тех пор в pf OpenBSD, не синтаксис правил, а например в части PFIL хуков, Source Based Policy Routing? Просто хуков маловато по сравнению с netfilter, а SBPR в pfSense и, надо полагать в FreeBSD, выглядит диким костылем, дующим в интерфейс в обход системной таблицы маршрутизации.

rubic ()
Ответ на: комментарий от val-amart

Ok, сейчас привёл к состоянию в

2. Но вообще-то надо пробросить порт на внешний интерфейс, делаю всё то же самое, но теперь для WAN:

http://i.imgur.com/eqMdhYJ.png

Не работает.

В правилах внутренний интерфейс попадается только тут:

pass in quick on vtnet0 reply-to (vtnet0 XXX.XXX.XXX.XX1) inet proto tcp from any to 10.0.70.118 port = ssh flags S/SA keep state label «USER_RULE: NAT ssh»

В таблице NAT есть такое:

rdr on vtnet0 inet proto tcp from any to any port = ssh -> 10.0.70.118

Весь rules:

[2.2-RELEASE][root@pfSense.localdomain]/root: pfctl -sr
scrub on vtnet0 all fragment reassemble
scrub on vtnet1 all fragment reassemble
anchor "relayd/*" all
anchor "openvpn/*" all
anchor "ipsec/*" all
pass in quick on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out quick on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
block drop in log quick inet6 all label "Block all IPv6"
block drop out log quick inet6 all label "Block all IPv6"
block drop in log quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local"
block drop in log quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local"
block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"
block drop in log inet6 all label "Default deny rule IPv6"
block drop out log inet6 all label "Default deny rule IPv6"
pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echorep keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echorep keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
block drop log quick inet proto tcp from any port = 0 to any
block drop log quick inet proto udp from any port = 0 to any
block drop log quick inet proto tcp from any to any port = 0
block drop log quick inet proto udp from any to any port = 0
block drop log quick inet6 proto tcp from any port = 0 to any
block drop log quick inet6 proto udp from any port = 0 to any
block drop log quick inet6 proto tcp from any to any port = 0
block drop log quick inet6 proto udp from any to any port = 0
block drop log quick from <snort2c> to any label "Block snort2c hosts"
block drop log quick from any to <snort2c> label "Block snort2c hosts"
block drop in log quick proto tcp from <sshlockout> to (self) port = down label "sshlockout"
block drop in log quick proto tcp from <webConfiguratorlockout> to (self) port = http label "webConfiguratorlockout"
block drop in log quick from <virusprot> to any label "virusprot overload table"
block drop in log on ! vtnet0 inet from XXX.XXX.XXX.XX0/29 to any
block drop in log inet from XXX.XXX.XXX.XX2 to any
block drop in log on vtnet0 inet6 from fe80::e817:c5ff:fe2e:7bdc to any
block drop in log on ! vtnet1 inet from 10.0.70.0/24 to any
block drop in log inet from 10.0.70.3 to any
block drop in log on vtnet1 inet6 from fe80::20ea:8aff:fe16:730f to any
pass in on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass out on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass in on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
pass out route-to (vtnet0 XXX.XXX.XXX.XX1) inet from XXX.XXX.XXX.XX2 to ! XXX.XXX.XXX.XX0/29 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
pass in quick on vtnet1 proto tcp from any to (vtnet1) port = http flags S/SA keep state label "anti-lockout rule"
pass in quick on vtnet1 proto tcp from any to (vtnet1) port = down flags S/SA keep state label "anti-lockout rule"
anchor "userrules/*" all
pass in quick on vtnet0 reply-to (vtnet0 XXX.XXX.XXX.XX1) inet proto tcp from any to 10.0.70.118 port = ssh flags S/SA keep state label "USER_RULE: NAT ssh"
pass in quick on vtnet1 inet from 10.0.70.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
anchor "tftp-proxy/*" all

Весь nat:

[2.2-RELEASE][root@pfSense.localdomain]/root: pfctl -sn
no nat proto carp all
nat-anchor "natearly/*" all
nat-anchor "natrules/*" all
nat on vtnet0 inet from 127.0.0.0/8 to any port = isakmp -> XXX.XXX.XXX.XX2 static-port
nat on vtnet0 inet from 10.0.70.0/24 to any port = isakmp -> XXX.XXX.XXX.XX2 static-port
nat on vtnet0 inet from 127.0.0.0/8 to any -> XXX.XXX.XXX.XX2 port 1024:65535
nat on vtnet0 inet from 10.0.70.0/24 to any -> XXX.XXX.XXX.XX2 port 1024:65535
no rdr proto carp all
rdr-anchor "relayd/*" all
rdr-anchor "tftp-proxy/*" all
rdr on vtnet0 inet proto tcp from any to any port = ssh -> 10.0.70.118
rdr-anchor "miniupnpd" all

vtnet0 - WAN

vtnet - LAN

Создание отдельного правила, открывающего 22 порт (http://i.imgur.com/iIfWxmx.png) выглядит так:

pass in quick on vtnet0 reply-to (vtnet0 XXX.XXX.XXX.XX1) inet proto tcp from any to XXX.XXX.XXX.XX2 port = ssh flags S/SA keep state label «USER_RULE: Allow ssh on WAN»

Правило, разрешающее всё на WAN (и с которым всё работает) выглядит так:

pass in quick on vtnet0 reply-to (vtnet0 XXX.XXX.XXX.XX1) inet proto tcp from any to XXX.XXX.XXX.XX2 flags S/SA keep state label «USER_RULE: Allow all on WAN»

overmind88 ★★★★★ ()
Ответ на: комментарий от overmind88
nat on vtnet0 inet from 10.0.70.0/24 to any -> XXX.XXX.XXX.XX2 port 1024:65535

Не нужно здесь указывать порты (1024:65535). Как обратные пакеты от 10.0.70.118 с 22 порта будут наружу NAT-иться?

rubic ()
Ответ на: комментарий от rubic

во Фре если не ошибаюсь pf портирован с 4.1; openbsd 4.1 вышла в мае 2007-го. поменялось за столько времени как сам понимаешь очень много, в определенном смысле «все» потому что с тех пор pf пережил два major rewrite'а (не считая изменений в синтаксисе в 4.7 кажеться). я не теситировал производительность на 4.1, но только с 4.5 по 5.3 pps на тестовом рулсете поднялся в 20 раз (конечно, это в первую очередь говорит о проблемах в старых версиях). ну и просто хочется отметить что в Опене большой набор сетевых функций, в ядре и в юзерспейсе, и все они работают совместно, как одна интегрированная платформа; в этом имхо большое преимущество.

что касается sbpr, а что с ним не так? если не нравиться в обход rt (хотя в этом имхо весь смысл route-to), то можно использовать rtable чтобы назначить альтернативную таблицу маршрутизации. собственно так реализуется весь policy-based routing и vrf. а с недавнего времени (или уже давнего, время идет незаметно...) rtable отделили от rdomain в две раздельные концепции, и рулить роутингом стало намного удобнее.

вместо phil другой механизм — divert(4). divert отправляет полностью весь пакет в юзерспейс, весь поток, делай что хочешь. не в ядре, да. разумеется, можно представить случай когда его производительности не будет хватать, но дело просто в разнице подходов разработчиков: если появляется новый интересный юзкейс, то надо реализовать нативную фичу, прямо в пф в кернелспейсе, и дать ей нормальный синтаксис, а не сделать мощный движок для евалуации правил, и выдать апи администраторам «ваяйте что хотите на этом».

val-amart ★★★★★ ()
Ответ на: комментарий от rubic

Не нужно здесь указывать порты (1024:65535). Как обратные пакеты от 10.0.70.118 с 22 порта будут наружу NAT-иться?

ммм. а в чем проблема? rdr правило создаст запись в таблице ната при создании стейта, так что все должно быть нормально.

val-amart ★★★★★ ()
Ответ на: комментарий от overmind88

pass in quick on vtnet0 reply-to (vtnet0 XXX.XXX.XXX.XX1) inet proto tcp from any to 10.0.70.118 port = ssh flags S/SA keep state label «USER_RULE: NAT ssh»

откуда на vtnet0 пакеты для 10.0.70.118?

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

могу разве что порекомендовать включить логи и смотреть на pflog какие именно правила срабатывают.

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

ммм. а в чем проблема? rdr правило создаст запись в таблице ната при создании стейта, так что все должно быть нормально.

Туплю(

вместо phil другой механизм — divert(4). divert отправляет полностью весь пакет в юзерспейс, весь поток, делай что хочешь.

И в этом месте туплю тоже. Я прочел divert(4) и вынес из этого, что из pf можно отправить пакет во внешнее приложение и там его проинспектировать. Но вопрос в том как сам pf влезает в сетевой стэк OpenBSD. Вернее даже в каких точках. Ну например в netfilter есть 5 хуков: http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html на всех путях прохождения пакета. По сравнению с PHIL_HOOKS во FreeBSD, где пакет инспектируется и меняется только на входе и на выходе - это очень здорово.

Вот pfSense не использует множественные таблицы маршрутизации, за которые я обеими руками, но даже если бы использовал, как с двумя хуками заставить локальный процесс (возьмем SQUID) подчиняться им средствами pf? Нет хука между локальным процессом и routing decision как в netfilter. А SPBR на выходе (pass out route to) там кривой как турецкий ятаган. На форуме стоит вой, что SQUID перестал работать в новых версиях с MultiWAN Load Balansing. А раньше это достигалось таким извращением в pf.c, что не удивительно, что его убрали.

rubic ()
Ответ на: комментарий от rubic

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

val-amart ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.