СОбственно не могу разобраться почему не работает правило редиректа в pf.
Исходные данные:
Inet -> 95.173.x.x GW(Nat) 10.1.1.1-> $Ext_if (bridge with pf) $int_if ->10.1.1.2 client
На клиенте прописан default gateway 10.1.1.1Собственно само соединение через мост работает нормально, pf фильтрует трафик, все Ок.
Для организации антивирусной проверки на bridge пытаюсь прикрутить Squid+AV (DrWeb)+rdr правила вида
rdr on $int_if inet proto tcp from any to any port 80 -> 127.0.0.1 port 3128
pass in quick on $int_if route-to lo0 inet proto tcp from any to 127.0.0.1 port 3128 keep stateSquid соответственно слушает 127.0.0.1:3128 intercept.
(К слову если сделать на бридже адрес и явно прописать его на клиенте все опять же работает, AV фильтрует)Правило даже вроде как работает, т.к. pfctl -ss дает кучу записей типа
all tcp 127.0.0.1:3128 <- 82.204.218.126:80 <- 10.1.1.2:35550 CLOSED:SYN_SENTНе пойму в чем проблема. Читал, что где то еще нат нужен, но в данной конфигурации непонятно где. К тому же tcpdump на lo0 вообще пустой. По статусу соединения проблема где-то в роутинге, но вот где?
>[оверквотинг удален]
> Исходные данные:
> Inet -> 95.173.x.x GW(Nat) 10.1.1.1-> $Ext_if (bridge with pf) $int_if ->10.1.1.2 client
> На клиенте прописан default gateway 10.1.1.1
> Собственно само соединение через мост работает нормально, pf фильтрует трафик, все Ок.
> Для организации антивирусной проверки на bridge пытаюсь прикрутить Squid+AV (DrWeb)+rdr
> правила вида
> rdr on $int_if inet proto tcp from any to any port 80
> -> 127.0.0.1 port 3128
> pass in quick on $int_if route-to lo0 inet proto tcp from any
> to 127.0.0.1 port 3128 keep stateА зачем последнее правило? В прозрачном перенаправлении трафика на сквид хватает первого.
rdr pass on $int_if inet proto tcp from any to any port 80
-> 127.0.0.1 port 3128
> Squid соответственно слушает 127.0.0.1:3128 intercept.
> (К слову если сделать на бридже адрес и явно прописать его на
> клиенте все опять же работает, AV фильтрует)
> Правило даже вроде как работает, т.к. pfctl -ss дает кучу записей типа
> all tcp 127.0.0.1:3128 <- 82.204.218.126:80 <- 10.1.1.2:35550
> CLOSED:SYN_SENT
> Не пойму в чем проблема. Читал, что где то еще нат нужен,
> но в данной конфигурации непонятно где. К тому же tcpdump на
> lo0 вообще пустой. По статусу соединения проблема где-то в роутинге, но
> вот где?А tcpdump что говорит на интерфейсах
tcpdump -nqtttti _IF_NAME_
> А зачем последнее правило? В прозрачном перенаправлении трафика на
> сквид хватает первого.
> rdr pass on $int_if inet proto tcp from any to any port
> 80
> -> 127.0.0.1 port 3128Т.к. в Pf при rdr трафик проходит через фильтры, поэтому если его явно не разрешить то он будет дропнут на последнем правиле deny.
> А tcpdump что говорит на интерфейсах
> tcpdump -nqtttti _IF_NAME_А он весь http трафик прекрасно видит, и на int_if и на bridge0. Более того в логах pf отрабатывает именно второе правило pass in log quick...
Вот только на lo0 ничего нет, вообще...
Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if. Т.е. по логике уходя с клиента они попадают на int_if, но потом должно сработать правило редиректа, и оно как бы даже срабатывает, но этот же пакет появляется и логируется на bridge0 по второму разу.
>> А зачем последнее правило? В прозрачном перенаправлении трафика на
>> сквид хватает первого.
>> rdr pass on $int_if inet proto tcp from any to any port
>> 80
>> -> 127.0.0.1 port 3128
> Т.к. в Pf при rdr трафик проходит через фильтры, поэтому если его
> явно не разрешить то он будет дропнут на последнем правиле deny.Так вы посмотрите внимательнее. Там опция pass зачем по-вашему?
>[оверквотинг удален]
>> tcpdump -nqtttti _IF_NAME_
> А он весь http трафик прекрасно видит, и на int_if и на
> bridge0. Более того в логах pf отрабатывает именно второе правило pass
> in log quick...
> Вот только на lo0 ничего нет, вообще...
> Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if.
> Т.е. по логике уходя с клиента они попадают на int_if, но
> потом должно сработать правило редиректа, и оно как бы даже срабатывает,
> но этот же пакет появляется и логируется на bridge0 по второму
> разу.
>[оверквотинг удален]
>> tcpdump -nqtttti _IF_NAME_
> А он весь http трафик прекрасно видит, и на int_if и на
> bridge0. Более того в логах pf отрабатывает именно второе правило pass
> in log quick...
> Вот только на lo0 ничего нет, вообще...
> Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if.
> Т.е. по логике уходя с клиента они попадают на int_if, но
> потом должно сработать правило редиректа, и оно как бы даже срабатывает,
> но этот же пакет появляется и логируется на bridge0 по второму
> разу.В догонку. Сразу забыл дописать. Если у вас мост, то нет необходимости фильтровать на всех интерфейсах. Во фре можно фильтровать на самом бридже (в опенке по-моему на бридже фильтровать нельзя). Регулируется такое поведение с помощью sysctl
Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса.
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.pfil_bridge: 1
net.link.bridge.pfil_onlyip: 1Посмотрите, может поможет.
>[оверквотинг удален]
> фильтровать на всех интерфейсах. Во фре можно фильтровать на самом бридже
> (в опенке по-моему на бридже фильтровать нельзя). Регулируется такое поведение с
> помощью sysctl
> Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса.
> net.link.bridge.log_stp: 0
> net.link.bridge.pfil_local_phys: 0
> net.link.bridge.pfil_member: 0
> net.link.bridge.pfil_bridge: 1
> net.link.bridge.pfil_onlyip: 1
> Посмотрите, может поможет.Спасибо, такие параметры есть, фильтрую и на бридже и на интерфейсах, в принципе пробовал и чисто на бридж правило редиректа повесить, точно так же эффекта нет.
>[оверквотинг удален]
>> Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса.
>> net.link.bridge.log_stp: 0
>> net.link.bridge.pfil_local_phys: 0
>> net.link.bridge.pfil_member: 0
>> net.link.bridge.pfil_bridge: 1
>> net.link.bridge.pfil_onlyip: 1
>> Посмотрите, может поможет.
> Спасибо, такие параметры есть, фильтрую и на бридже и на интерфейсах, в
> принципе пробовал и чисто на бридж правило редиректа повесить, точно так
> же эффекта нет.Значит, что-то не так делаете.
Попробуйте что-то вроде этого:Включите фильтрацию только на бридже. Squid "слушает" на интерфейсе моста.
set skip on {lo $int_if $ext_if}
set state-policy if-boundrdr on bridge0 inet proto tcp from $client to !(self) port {80 443} -> 127.0.0.1 port 3128
block in all
block out allpass in quick on bridge0 inet proto tcp from $client to bridge0
pass out quick on bridge0 from bridge0 to anyФорвардинг включать не надо.
> Включите фильтрацию только на бридже. Squid "слушает" на интерфейсе моста.Он не может слушать на интерфейсе моста, у моста нет ip.
К тому же в правилах ниже Вы предлагаете редирект на 127.0.0.1
> set skip on {lo $int_if $ext_if}
> set state-policy if-bound
> rdr on bridge0 inet proto tcp from $client to !(self) port {80
> 443} -> 127.0.0.1 port 3128
> block in all
> block out all
> pass in quick on bridge0 inet proto tcp from $client to bridge0
> pass out quick on bridge0 from bridge0 to anyИ данные правила так же не применимы no IP address found for bridge0
>[оверквотинг удален]
>> set skip on {lo $int_if $ext_if}
>> set state-policy if-bound
>> rdr on bridge0 inet proto tcp from $client to !(self) port {80
>> 443} -> 127.0.0.1 port 3128
>> block in all
>> block out all
>> pass in quick on bridge0 inet proto tcp from $client to bridge0
>> pass out quick on bridge0 from bridge0 to any
> И данные правила так же не применимы no IP address found for
> bridge0))). Наверное надо немного доки почитать. Макрос вы не определили.
Удачи.
> ))). Наверное надо немного доки почитать. Макрос вы не определили.
> Удачи.Ээээ... в каком месте макрос и при чем здесь они. вот целиком правила сейчас:
loopback = "{ lo0 }"
WAN = "{ igb3 }"
LAN = "{ igb0 }"
OPT1 = "{ igb2 }"
BRIDGE = "{ bridge0 }"
set skip on $loopback
set skip on $OPT1
set skip on $WAN
set state-policy if-bound
rdr on bridge0 inet proto tcp from 10.111.111.2 to !(self) port {80, 443} -> 127.0.0.1 port 3128
pass in log quick on bridge0 from any to bridge0
pass out log quick on bridge0 from bridge0 to anyЕсли нет Ip на bridge правила не загружаются. Ставлю 10.x.x.x на бридж правила загружаются.
Однако проблему это не решает.
pfctl -ss
all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37710 CLOSED:SYN_SENT
all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37711 CLOSED:SYN_SENTtcpdump bridge0
2012-02-10 11:40:19.889628 IP 10.111.111.2.44362 > 194.67.33.62.80: tcp 0
2012-02-10 11:40:20.657694 IP 10.111.111.2.38670 > 62.213.71.224.80: tcp 0
2012-02-10 11:40:20.657702 IP 10.111.111.2.38671 > 62.213.71.224.80: tcp 0
>[оверквотинг удален]
> Однако проблему это не решает.
> pfctl -ss
> all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37710
> CLOSED:SYN_SENT
> all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37711
> CLOSED:SYN_SENT
> tcpdump bridge0
> 2012-02-10 11:40:19.889628 IP 10.111.111.2.44362 > 194.67.33.62.80: tcp 0
> 2012-02-10 11:40:20.657694 IP 10.111.111.2.38670 > 62.213.71.224.80: tcp 0
> 2012-02-10 11:40:20.657702 IP 10.111.111.2.38671 > 62.213.71.224.80: tcp 0а ipfw часом не запущен?
подозреваю, что так оно и есть, ибо у вас CLOSED:SYN_SENT
очень даже может мешать (
на всякий пожарный дайте ему ipfw flush
и проверьте
>>[оверквотинг удален]
> а ipfw часом не запущен?
> подозреваю, что так оно и есть, ибо у вас CLOSED:SYN_SENT
> очень даже может мешать (
> на всякий пожарный дайте ему ipfw flush
> и проверьтевозможно, я лично подозреваю, что проблема где-то в роутинге, т.к. есть отдельный линк в интернет для управления. и там статик роут прописан.
Попробую от него избавиться и на ipfw посмотрю.