 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, 13:49 , 17-Апр-07 (1)
помоему происходит так:клиент обратился на 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, 14:08 , 17-Апр-07 (2)
>помоему происходит так:
>
>клиент обратился на 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, 14:31 , 17-Апр-07 (3)
Спасибо. Смысл проблемы я понял, но боюсь, решение для меня неприемлемо :( Ведь тогда сквид будет обслуживать только один адрес, а у меня по адресам делается и контроль доступа, и ограничение канала (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, 14:41 , 17-Апр-07 (4)
>Спасибо. Смысл проблемы я понял, но боюсь, решение для меня неприемлемо :(
>Ведь тогда сквид будет обслуживать только один адрес, а у меня
>по адресам делается и контроль доступа, и ограничение канала (delay_pools)...
>Но по крайней мере, сдвинулся с мертвой точки, вы конечно правы, клиент
>действительно "не узнает" своего запроса.
>
а если отправить squid в другую подсеть?
- pf.conf rdr на сервер со squid, slider, 14:54 , 17-Апр-07 (5)
мне кажется, что смысл от этого не меняется. нужно понять, есть ли решение без nat>а если отправить squid в другую подсеть?
- pf.conf rdr на сервер со squid, slider, 15:08 , 17-Апр-07 (6)
да, все верно. предыдущая проблема решена посредством nat. осталось решить, как можно донести ip настоящего клиента до squid и при этом заставить его ответить на адрес файрвола. >мне кажется, что смысл от этого не меняется. нужно понять, есть ли
>решение без nat
>
>>а если отправить squid в другую подсеть?
- pf.conf rdr на сервер со squid, reader, 15:24 , 17-Апр-07 (7)
если машина со squid будет в другой логической подсети, и в той же физической, то ответы squid будет отправлять согласно таблицы маршрутизации, тоесть через фаервол.
- pf.conf rdr на сервер со squid, slider, 10:35 , 18-Апр-07 (8)
>если машина со squid будет в другой логической подсети, и в той
>же физической, то ответы squid будет отправлять согласно таблицы маршрутизации, тоесть
>через фаервол. видимо вчера день такой был. не догонял ничерта.
всем ответившим большое спасибо. разобрался.
- pf.conf rdr на сервер со squid, Tuxper, 12:30 , 13-Май-07 (9)
>видимо вчера день такой был. не догонял ничерта.
>всем ответившим большое спасибо. разобрался.
Товарищ, опиши пожалуйста как вышел из положения у меня подобная ситуация...
- pf.conf rdr на сервер со squid, slider, 08:38 , 14-Авг-07 (10)
>>видимо вчера день такой был. не догонял ничерта.
>>всем ответившим большое спасибо. разобрался.
>Товарищ, опиши пожалуйста как вышел из положения у меня подобная ситуация... извини, коллега, долго не заглядывал в форум... думаю ты уже сам разобрался (в принципе по ветке ответов все понятно, я и впрямь тогда не сразу догнал, в чем смысл), но если кому-то еще понадобится: решение, которое здесь посоветовали и которое было использовано такое:
если в упомянутой ситуации машина гейтвей имеет адрес 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
...
|
Версия для распечатки
