URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 73565
[ Назад ]
Исходное сообщение
"pf.conf rdr на сервер со squid"
Отправлено slider , 17-Апр-07 12:50 
возник затык, не могу рассмотреть, где и что пропускаю... буду рад помощи.
стоял (и стоит) файрвол, на нем крутился кальмар. в какой-то момент решил разгрузить файрвол и поставить сквида на другую машину.
на файрволе используется PF. было правило (192.168.1.66 это файрвол):
rdr on $int_if proto tcp from $internal_net to !192.168.1.66 port http -> localhost port 3128
это правило работало.
изменил на (155-й - машина со сквидом, опцию pass добавил позже, но с ней тоже не работает):
rdr pass on $int_if proto tcp from $internal_net to !192.168.1.66 port http -> 192.168.1.155 port 3128

и вот так не работает. что я вижу:

(на файрволе):
#pfctl -ss
self tcp 192.168.1.64:1080 -> 192.168.1.155:3128       SYN_SENT:CLOSED
self tcp 192.168.1.64:1081 -> 192.168.1.155:3128       SYN_SENT:CLOSED

(на файрволе):
# tcpdump -i fxp0 -n -nn host 192.168.1.155
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
12:46:09.594672 IP 192.168.1.64.1087 > 192.168.1.155.3128: S 245580897:245580897(0) win 64512 <mss 1460,nop,nop,sackOK>
12:46:12.576370 IP 192.168.1.64.1087 > 192.168.1.155.3128: S 245580897:245580897(0) win 64512 <mss 1460,nop,nop,sackOK>
12:46:18.613289 IP 192.168.1.64.1087 > 192.168.1.155.3128: S 245580897:245580897(0) win 64512 <mss 1460,nop,nop,sackOK>

(на сквиде):
# tcpdump -i fxp0 -n -nn port 3128
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
12:45:41.148064 IP 192.168.1.64.1091 > 192.168.1.155.3128: S 2511498740:2511498740(0) win 64512 <mss 1460,nop,nop,sack                  OK>
12:45:41.148159 IP 192.168.1.155.3128 > 192.168.1.64.1091: S 1611866890:1611866890(0) ack 2511498741 win 65535 <mss 14                  60,sackOK,eol>
12:45:41.148493 IP 192.168.1.64.1091 > 192.168.1.155.3128: R 2511498741:2511498741(0) win 0
12:45:44.162855 IP 192.168.1.64.1091 > 192.168.1.155.3128: S 2511498740:2511498740(0) win 64512 <mss 1460,nop,nop,sack                  OK>
12:45:44.162957 IP 192.168.1.155.3128 > 192.168.1.64.1091: S 2075788944:2075788944(0) ack 2511498741 win 65535 <mss 14                  60,sackOK,eol>
12:45:44.163070 IP 192.168.1.64.1091 > 192.168.1.155.3128: R 2511498741:2511498741(0) win 0
12:45:50.299418 IP 192.168.1.64.1091 > 192.168.1.155.3128: S 2511498740:2511498740(0) win 64512 <mss 1460,nop,nop,sackOK>
12:45:50.299572 IP 192.168.1.155.3128 > 192.168.1.64.1091: S 2946723940:2946723940(0) ack 2511498741 win 65535 <mss 1460,sackOK,eol     >
12:45:50.299688 IP 192.168.1.64.1091 > 192.168.1.155.3128: R 2511498741:2511498741(0) win 0

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

Содержание
Сообщения в этом обсуждении
"pf.conf rdr на сервер со squid"
Отправлено reader , 17-Апр-07 13:49 
помоему происходит так:

клиент обратился на 192.168.1.64 , с 192.168.1.64 пакет перебросили на 192.168.1.155,
а ответ 192.168.1.155 отправил прямо клиенту, и клиент отбросил этот пакет, так как ждет ответа от 192.168.1.64

"pf.conf rdr на сервер со squid"
Отправлено Xela , 17-Апр-07 14:08 
>помоему происходит так:
>
>клиент обратился на 192.168.1.64 , с 192.168.1.64 пакет перебросили на 192.168.1.155,
>а ответ 192.168.1.155 отправил прямо клиенту, и клиент отбросил этот пакет, так
>как ждет ответа от 192.168.1.64


Именно так и происходит.

Автору оригинального поста: вам надо занатить подобный редирект адресом файрвола. Что бы от прокси трафик возвращался на файрвол, а не на прямую клиентам.

"pf.conf rdr на сервер со squid"
Отправлено slider , 17-Апр-07 14:31 
Спасибо. Смысл проблемы я понял, но боюсь, решение для меня неприемлемо :( Ведь тогда сквид будет обслуживать только один адрес, а у меня по адресам делается и контроль доступа, и ограничение канала (delay_pools)...
Но по крайней мере, сдвинулся с мертвой точки, вы конечно правы, клиент действительно "не узнает" своего запроса.

>>помоему происходит так:
>>
>>клиент обратился на 192.168.1.64 , с 192.168.1.64 пакет перебросили на 192.168.1.155,
>>а ответ 192.168.1.155 отправил прямо клиенту, и клиент отбросил этот пакет, так
>>как ждет ответа от 192.168.1.64
>
>
>Именно так и происходит.
>
>Автору оригинального поста: вам надо занатить подобный редирект адресом файрвола. Что бы
>от прокси трафик возвращался на файрвол, а не на прямую клиентам.
>


"pf.conf rdr на сервер со squid"
Отправлено reader , 17-Апр-07 14:41 
>Спасибо. Смысл проблемы я понял, но боюсь, решение для меня неприемлемо :(
>Ведь тогда сквид будет обслуживать только один адрес, а у меня
>по адресам делается и контроль доступа, и ограничение канала (delay_pools)...
>Но по крайней мере, сдвинулся с мертвой точки, вы конечно правы, клиент
>действительно "не узнает" своего запроса.
>
а если отправить squid в другую подсеть?

"pf.conf rdr на сервер со squid"
Отправлено slider , 17-Апр-07 14:54 
мне кажется, что смысл от этого не меняется. нужно понять, есть ли решение без nat

>а если отправить squid в другую подсеть?


"pf.conf rdr на сервер со squid"
Отправлено slider , 17-Апр-07 15:08 
да, все верно. предыдущая проблема решена посредством nat. осталось решить, как можно донести ip настоящего клиента до squid и при этом заставить его ответить на адрес файрвола.

>мне кажется, что смысл от этого не меняется. нужно понять, есть ли
>решение без nat
>
>>а если отправить squid в другую подсеть?


"pf.conf rdr на сервер со squid"
Отправлено reader , 17-Апр-07 15:24 
если машина со squid будет в другой логической подсети, и в той же физической, то ответы squid будет отправлять согласно таблицы маршрутизации, тоесть через фаервол.

"pf.conf rdr на сервер со squid"
Отправлено slider , 18-Апр-07 10:35 
>если машина со squid будет в другой логической подсети, и в той
>же физической, то ответы squid будет отправлять согласно таблицы маршрутизации, тоесть
>через фаервол.

видимо вчера день такой был. не догонял ничерта.
всем ответившим большое спасибо. разобрался.

"pf.conf rdr на сервер со squid"
Отправлено Tuxper , 13-Май-07 12:30 
>видимо вчера день такой был. не догонял ничерта.
>всем ответившим большое спасибо. разобрался.
Товарищ, опиши пожалуйста как вышел из положения у меня подобная ситуация...


"pf.conf rdr на сервер со squid"
Отправлено slider , 14-Авг-07 08:38 
>>видимо вчера день такой был. не догонял ничерта.
>>всем ответившим большое спасибо. разобрался.
>Товарищ, опиши пожалуйста как вышел из положения у меня подобная ситуация...

извини, коллега, долго не заглядывал в форум... думаю ты уже сам разобрался (в принципе по ветке ответов все понятно, я и впрямь тогда не сразу догнал, в чем смысл), но если кому-то еще понадобится: решение, которое здесь посоветовали и которое было использовано такое:
если в упомянутой ситуации машина гейтвей имеет адрес 192.168.1.66 (т.е. находится в сети 192.168.1.0/24), то сервер со squid выносится (ну к примеру) в сеть 192.168.100.0/24. На сетевом интерфейсе гейта описывается алиас (ну его ведь тоже надо в эту "сотую" сеть как-то отправить) и правила в случае pf получаются такими:
$cat /etc/pf.conf
...
internal_net1 = "192.168.1.0/24"
internal_net2 = "192.168.100.0/24"
squid = "192.168.100.2"
...
rdr on $int_if proto tcp from $internal_net1 to !(self) port {80 8080} -> $squid port 3128
...