Firewall rules для пакетов

dvserg

Умеет
http://www.samag.ru/art/02.2007/02.2007_09.html

acl subnet1 src 192.168.0.0/255.255.255.240
acl subnet2 stc 192.168.0.128/255.255.255.240
tcp_outgoing_address 10.0.1.2 subnet1
tcp_outgoing_address 10.1.1.2 subnet2

Mailer

Извиняюсь за свою тупость, но в приведенном выше примере в качестве tcp_outgoing_adress указан интерфейс не модема, а сетевухи, подключенной к модему. Я подумал что это ошибка автора и поставил интерфейс модема - получил от сквида ошибку сокета. Поставил интерфейс карты - получил пакеты на карте, а не модеме. Дополнительный НАТ порт форвард чтоли нужен?

dvserg

@Mailer:

Извиняюсь за свою тупость, но в приведенном выше примере в качестве tcp_outgoing_adress указан интерфейс не модема, а сетевухи, подключенной к модему. Я подумал что это ошибка автора и поставил интерфейс модема - получил от сквида ошибку сокета. Поставил интерфейс карты - получил пакеты на карте, а не модеме. Дополнительный НАТ порт форвард чтоли нужен?

Если в указаном примере ИП совпал с адресом модема - это случайность
там должно быть ИП нужного интерфейса есс-нно

Mailer

интерфейс WAN - 192.168.187.190
интерфейс OPT1 - 192.168.186.190
добавил

acl subnet1 src 192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.186.190 subnet1
tcp_incoming_address 192.168.186.190 subnet1

сквид судя по логам стартанул без сбоев. Но при этом пакеты где-то застряют. Фаервол молчит. Я сидел долго думал.
Попробовал проверить не игнорит ли он эти строки… Заменил вышеприведенный блок на

acl subnet1 src 192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.187.190 subnet1
tcp_incoming_address 192.168.187.190 subnet1

Сразу прокс заработал. Поменял обратно 187 на 186 - сразу же он заткнулся. Сижу думаю дальше. Где застряют пакеты?

dvserg

@Mailer:

интерфейс WAN - 192.168.187.190
интерфейс OPT1 - 192.168.186.190
добавил
acl subnet1 src 192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.186.190 subnet1
tcp_incoming_address 192.168.186.190 subnet1
сквид судя по логам стартанул без сбоев. Но при этом пакеты где-то застряют. Фаервол молчит. Я сидел долго думал.
Попробовал проверить не игнорит ли он эти строки… Заменил вышеприведенный блок на
acl subnet1 src 192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.187.190 subnet1
tcp_incoming_address 192.168.187.190 subnet1
Сразу прокс заработал. Поменял обратно 187 на 186 - сразу же он заткнулся. Сижу думаю дальше. Где застряют пакеты?

инкомин адрес зачем?
Сквид догадается слушать на 186 подсети?

Mailer

после удаления incoming squid все равно не пашет через OPT1 интерфейс. Он просто вообще не работает. Чего-то не хватает…
Любого кто лично сможет его запустить через OPT1 и скажет мне как, назову учителем. Самое смешное, что в Ubuntu вышеуказанная схемка с tcp_outgoing заработала без проблем.

dvserg

Сквид какой адрес слушает?

Mailer

dvserg
Вы любите говорить загадками… ::) Необходимо что, поднимать второй процесс сквида на OPT1-интерфейсе? Или это как-то можно задать рулезами или доп.опциями сквида?

dvserg

@Mailer:

dvserg
Вы любите говорить загадками… ::) Необходимо что, поднимать второй процесс сквида на OPT1-интерфейсе? Или это как-то можно задать рулезами или доп.опциями сквида?

Угу, особенно когда не видно полного конфига сквида. Ты хочешь понять смысл моих вопросов, а я твоих ))
Вопрос кстати не загадочный и означает "на каком интерфейсе squid слушает входящие запросы"
Это прописывается в конфиге.

Mailer

http_port 192.168.186.190:8080;
acl subnet1 src 192.168.185.0/255.255.255.0;
tcp_outgoing_address 192.168.186.190 subnet1;

добавил в доп. опции. Не работает. Извини, я тупой, это наверное у меня в ДНК.

dvserg

@Mailer:

http_port 192.168.186.190:8080;
acl subnet1 src 192.168.185.0/255.255.255.0;
tcp_outgoing_address 192.168.186.190 subnet1;
добавил в доп. опции. Не работает. Извини, я тупой, это наверное у меня в ДНК.

Гы И тебя тоже природа наградила ;D
Давай попробуем разобраться - сквид слушает интерфейс на 192.168.186.х подсети Если убрать все дополнительные оутгоин опции - обе сети (186/187) имеют доступ к прокси?
В идеале нужно будет чтобы обе подсети подключались на один адрес а потом сквид их раскидывал на разные внешние интерфейсы - поэтому опция инкомин не нужна.
–-
Какие IP внешних интерфейсов WAN/OPT ?

Mailer

Вот полный squid.conf

# Do not edit manually !
http_port 192.168.185.254:3128
icp_port 0

pid_filename /var/run/squid.pid
cache_effective_user proxy
cache_effective_group proxy
error_directory /usr/local/etc/squid/errors/Russian-1251
icon_directory /usr/local/etc/squid/icons
visible_hostname localhost
cache_mgr admin@localhost
access_log /var/squid/log/access.log
cache_log /var/squid/log/cache.log
cache_store_log none
logfile_rotate 30
shutdown_lifetime 3 seconds
# Allow local network(s) on interface(s)
acl localnet src  192.168.185.0/255.255.255.0
forwarded_for off
uri_whitespace strip

cache_dir aufs /var/squid/cache 100 16 256
cache_mem 8 MB
maximum_object_size 10 KB
minimum_object_size 0 KB
cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
offline_mode off

# No redirector configured

# Setup some default acls
acl all src 0.0.0.0/0.0.0.0
acl localhost src 127.0.0.1/255.255.255.255
acl safeports port 21 70 80 210 280 443 488 563 591 631 777 901  3128 1025-65535
acl sslports port 443 563 
acl manager proto cache_object
acl purge method PURGE
acl connect method CONNECT
acl dynamic urlpath_regex cgi-bin \?
acl allowed_subnets src 192.168.185.0/24 
cache deny dynamic
http_access allow manager localhost

http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !safeports
http_access deny CONNECT !sslports

# Always allow localhost connections
http_access allow localhost

request_body_max_size 0 KB
reply_body_max_size 0 allow all
delay_pools 1
delay_class 1 2
delay_parameters 1 -1/-1 -1/-1
delay_initial_bucket_level 100
delay_access 1 allow all

# Allow local network(s) on interface(s)
http_access allow localnet
http_access allow allowed_subnets
# Custom options
http_port 192.168.186.190:8080
acl subnet1 src 192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.186.190 subnet1

# Default block all to be sure
http_access deny all

1. WAN-интерфейс 192.168.187.190(шлюз 192.168.187.199)
2. OPT1-интерфейс 192.168.187.190 (шлюз 192.168.186.199)

dvserg

А теперь подробнее плиз про LAN У тебя получается LAN 185 подсеть, она одна и ты ее целиком хочешь зарулить на OPT - так?

Mailer

Да, LAN=192.168.185.0/24, она одна, хочу чтобы все запросы которые приходят из неё на шлюз(192.168.185.254) по порту 3128 заруливались СКВИДОМ на OPT1.

dvserg

@Mailer:

Да, LAN=192.168.185.0/24, она одна, хочу чтобы все запросы которые приходят из неё на шлюз(192.168.185.254) по порту 3128 заруливались СКВИДОМ на OPT1.

Вот так тогда

# Allow local network(s) on interface(s)
acl localnet src  192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.186.190 localnet

Mailer

Не работает. Вообще в смысле не работает. А вот если сделать так

acl localnet src  192.168.185.0/255.255.255.0
tcp_outgoing_address 192.168.187.190 localnet

то работает на ура через первый интерфейс.
:'( Куда еще можно глядеть? Какой из логов сквида?

dvserg

А через OPT вообще работает? Правила там какие нужны - сделаны?

Mailer

Э…. а какие правила там должны быть? Через первый-то интерфейс без всяких правил сквозит ведь.

Вот делаю для LAN правило - TCP * * => DEST * PORT 80 (HTTP) GW192.168.186.199
После этого из любого компа в сети напрямую инет шпарит через OPT1, если в браузере включить направление через прокси - нихрена не работает.

dvserg

@Mailer:

Э…. а какие правила там должны быть? Через первый-то интерфейс без всяких правил сквозит ведь.

Вот делаю для LAN правило - TCP * * => DEST * PORT 80 (HTTP) GW192.168.186.199
После этого из любого компа в сети напрямую инет шпарит через OPT1, если в браузере включить направление через прокси - нихрена не работает.

Тогда ой… хотя по идее все для работы есть

Вот только что проверил на squidNT и тачке с несколькими IP на одном интерфейсе - все замечательно работает, скорее всего дело в правилах фаера

Mailer

Ну так я тоже на Убунте запускал - всё прекрасно работало. Если бы на мой взгляд дело в сквиде было, я бы на форуме сквида спросил. Но тут явно чего-то не то с pfsense. Возможно на уровне ядра. Возможно я просто не могу сконфигурировать правильное правило.