Firewall rules для пакетов
-
Без пакетов openVPN и squid сетка очень просто разруливается на два WAN-интерфейса правилами по целевым портам (INTlan SOURCElansubnet PORTany ==> DESTany PORT*XXXX)
а вот к примеру squid ВСЕГДА при любых правилах бросает все на первый WAN-интерфейс… Это можно как-нибудь забороть? -
Тааааак… Полазил по английским веткам. squid оказывается в принципе нельзя перевести на OPT1.
-
Умеет
http://www.samag.ru/art/02.2007/02.2007_09.htmlacl 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
-
Извиняюсь за свою тупость, но в приведенном выше примере в качестве tcp_outgoing_adress указан интерфейс не модема, а сетевухи, подключенной к модему. Я подумал что это ошибка автора и поставил интерфейс модема - получил от сквида ошибку сокета. Поставил интерфейс карты - получил пакеты на карте, а не модеме. Дополнительный НАТ порт форвард чтоли нужен?
-
Извиняюсь за свою тупость, но в приведенном выше примере в качестве tcp_outgoing_adress указан интерфейс не модема, а сетевухи, подключенной к модему. Я подумал что это ошибка автора и поставил интерфейс модема - получил от сквида ошибку сокета. Поставил интерфейс карты - получил пакеты на карте, а не модеме. Дополнительный НАТ порт форвард чтоли нужен?
Если в указаном примере ИП совпал с адресом модема - это случайность
там должно быть ИП нужного интерфейса есс-нно -
интерфейс 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 - сразу же он заткнулся. Сижу думаю дальше. Где застряют пакеты?
-
интерфейс 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 подсети? -
после удаления incoming squid все равно не пашет через OPT1 интерфейс. Он просто вообще не работает. Чего-то не хватает…
Любого кто лично сможет его запустить через OPT1 и скажет мне как, назову учителем. Самое смешное, что в Ubuntu вышеуказанная схемка с tcp_outgoing заработала без проблем. -
Сквид какой адрес слушает?
-
dvserg
Вы любите говорить загадками… ::) Необходимо что, поднимать второй процесс сквида на OPT1-интерфейсе? Или это как-то можно задать рулезами или доп.опциями сквида? -
dvserg
Вы любите говорить загадками… ::) Необходимо что, поднимать второй процесс сквида на OPT1-интерфейсе? Или это как-то можно задать рулезами или доп.опциями сквида?Угу, особенно когда не видно полного конфига сквида. Ты хочешь понять смысл моих вопросов, а я твоих ))
Вопрос кстати не загадочный и означает "на каком интерфейсе squid слушает входящие запросы"
Это прописывается в конфиге. -
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;
добавил в доп. опции. Не работает. Извини, я тупой, это наверное у меня в ДНК.
-
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 ? -
Вот полный 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) -
А теперь подробнее плиз про LAN У тебя получается LAN 185 подсеть, она одна и ты ее целиком хочешь зарулить на OPT - так?
-
Да, LAN=192.168.185.0/24, она одна, хочу чтобы все запросы которые приходят из неё на шлюз(192.168.185.254) по порту 3128 заруливались СКВИДОМ на OPT1.
-
Да, 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
-
Не работает. Вообще в смысле не работает. А вот если сделать так
acl localnet src 192.168.185.0/255.255.255.0 tcp_outgoing_address 192.168.187.190 localnet
то работает на ура через первый интерфейс.
:'( Куда еще можно глядеть? Какой из логов сквида? -
А через OPT вообще работает? Правила там какие нужны - сделаны?
-
Э…. а какие правила там должны быть? Через первый-то интерфейс без всяких правил сквозит ведь.
Вот делаю для LAN правило - TCP * * => DEST * PORT 80 (HTTP) GW192.168.186.199
После этого из любого компа в сети напрямую инет шпарит через OPT1, если в браузере включить направление через прокси - нихрена не работает.