Ooops...I should have added the wccp2_server_info setting from
squid.conf:
wccp2_service_info 80 protocol=tcp flags=src_ip_hash priority=240
ports=80
wccp2_service_info 90 protocol=tcp flags=dst_ip_hash,ports_source
priority=240 ports=80
-----Original Message-----
From: Ritter, Nicholas
Sent: Thursday, July 24, 2008 12:20 PM
To: 'Amos Jeffries'
Cc: 'squid-dev_at_squid-cache.org'
Subject: RE: squid3HEAD/TPROXY: interception log entries
Amos-
Thanks for your reply.
Ok...I think I am understanding what you are saying. Now translating
that to the situation at hand, I am not sure which route to take. I
switched my setting for http_port to:
http_port 3128 tproxy intercept disable-pmtu-discovery=always
Which I understand doesn't address the issue you commented below about
seperating intercept and tproxy traffic. If I take out the intercept, I
get an error on the client. I can't take tproxy out because that is what
is being redirected via iptables rules and provides the client IP
preservation to the remote site. I am confused as to how to seperate
what with where given incoming WCCP traffic from the router.
On the router I have wccp redirection rules as note on the squid wiki
(note: the squid box is 10.48.33.2, clients are 10.48.1.0/24):
ip wccp 80 redirect-list 121
ip wccp 90 redirect-list 121
interface FastEthernet0/1.1
encapsulation dot1Q 1 native
ip address 10.48.1.1 255.255.255.0
ip helper-address 10.2.5.101
ip wccp 80 redirect in
ip wccp 90 redirect out
!
interface FastEthernet0/1.33
encapsulation dot1Q 33
ip address 10.48.33.1 255.255.255.0
ip wccp redirect exclude in
On the squid box I have TProxy and GRE related rules:
TPROXY rules:
-A PREROUTING -p tcp -m socket -j DIVERT -A PREROUTING -p tcp -m tcp
--dport 80 -j TPROXY --on-port 3128 --on-ip 0.0.0.0 --tproxy-mark
0x1/0x1 -A DIVERT -j MARK --set-mark 0x1 -A DIVERT -j ACCEPT
GRE and WCCP rules:
-A INPUT -i gre0 -j ACCEPT
-A INPUT -i gre0 -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -i eth0 -p gre -j ACCEPT
-A FORWARD -j LocalFW
-A LocalFW -i lo -j ACCEPT
-A LocalFW -s 10.48.33.1/32 -p udp -m udp --dport 2048 -j ACCEPT
Given what you are saying, am I to assuming correctly that my iptables
rules would need to be adjusted? I understand in principle that I would
need to create a redirection rule to squid on one port with TPROXY, and
another redirection/NAT/DNAT rule to a squid port with intercept. Is
this correct?
Thanks in advance for any help. I apologize if this discussion should be
on the squid-users list, I assumed this list was the place given it was
squid3HEAD.
Nick
-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Thursday, July 24, 2008 12:05 AM
To: Ritter, Nicholas
Cc: squid-dev_at_squid-cache.org
Subject: RE: squid3HEAD/TPROXY: interception log entries
>
> I should have added some specifics...here are the log items in
> cache.log:
>
> 2008/07/23 13:35:34| IPInterception.cc(171) NetfilterTransparent: NF
> getsockopt(IP_TRANSPARENT) failed: (92) Protocol not available
> 2008/07/23 13:36:37| IPInterception.cc(137) NetfilterInterception: NF
> getsockopt(SO_ORIGINAL_DST) failed: (11) Resource temporarily
> unavailable
These can often be cleared up by correct use of 'intercept' and 'tproxy'
options in http_port. The old 'transparent' option is deprecated and
will to be backward-compatible, turn both on when often only one lookup
type is needed on that port.
>
> ....and occasionally the client browser sees an error page from squid
> stating a connection to the server failed, and the system returns a
> "(99) Cannot assign requested address"
This may be related to the above. If a tproxy receiving port is also
used for DNAT/REDIRECT reception the tproxy kernel sub-system may not
have records to correctly handle the apparent client address.
The getsockopt() failures should not be a problem, just annoying.
The assign failure, may be a problem. Squid will use its normal outgoing
address I think in those cases. But I'm not certain on the network
routing behavior when transparent squid become visible.
To solve both the the above. I recommend using seperate http_port's to
receive each type of traffic and setting specific 'intercept' or
'tproxy'
options to match the expected traffic types.
Amos
Received on Thu Jul 24 2008 - 18:50:15 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 25 2008 - 12:00:03 MDT