section 17 show abnormail thing:
(the outgoing address to the server is the client address and not one
of the server address)
2012/01/06 04:28:36.782| store_client::copy:
7DEA6A0583B90AB461F576C6AEE4AA50, from 0, for length 4096, cb 1,
cbdata 0x882b5b8
2012/01/06 04:28:36.783| storeClientCopy2:
7DEA6A0583B90AB461F576C6AEE4AA50
2012/01/06 04:28:36.784| store_client::doCopy: Waiting for more
2012/01/06 04:28:36.785| FwdState::start() 'http://link
2012/01/06 04:28:36.787| fwdStartComplete: http://link
2012/01/06 04:28:36.789| fwdConnectStart: http://1link
2012/01/06 04:28:36.791| fwdConnectStart: got outgoing addr
192.168.102.100, tos 0
"outgoing addr" is the address Squid assigns to its end of the
squid->server connection. This appears to be correct for TPROXY.
2012/01/06 04:28:36.791| fwdConnectStart: got TCP FD 13
so the main problem is that the request that comes from squid is not
using the right address in tproxy mode.
Thanks
Eliezer
On 05/01/2012 17:20, Eliezer Croitoru wrote:
i made a squid url_rewriter for cache purposes and it works on ubunut
and on fedora 16(i686).
also it works on fedora 15 with the 3.2.0.12 rpm from fedora 16 repo.
the problem is that when the re_rewriter is replying with the address to
squid the session that squid is creating is : from the client to the
server instead from the squid machine to the web server.
what is see using ss is:(tproxy is port 8081)
SYN-SENT 0 1 192.168.102.100:38660 192.168.102.3:tproxy
I'm unclear what this is and what you mean by "squid session". I assume
that is the details Squid sent to the helper?
If so that is a second strong sign of the loop mentioned below.
but using the 3.2.0.12 and on other systems i see from
192.168.102.3:high_port_number 192.168.102.3:tproxy
or
127.0.0.1:hight_port_number 127.0.0.1:tproxy
and everything works fine.
Er, this looks like the TPROXY looping traffic like so:
Client --(TPROXY)> ... Internet
. |
\..... Squid --> Rewriter --(TPROXY)> ... Internet
| \-------<<--------|
|
\---> Internet
well i do know how tproxy works and
the redirected address is 127.0.0.1 on ports other then the tproxy.
on the squid 3.2 branch it dosnt happens.
by the way the rewriter makes it without sending headers to the client
and it shouldnt bind 127.0.0.1 adress to access the localhost.
it's not a tproxy issue because it works on the 3.2 branch and also
there is no trace for the looping in the log.
the log shows two different requests just to show the concepts of the
problem.
as i mentioned tproxy works on http (port 80) and the tproxy target
mentioned in ss is port 8081 so this is not looping but something in
squid while getting the file from the server.
Thanks
Eliezer
Because, the re-writer is not sending its background fetch requests out
of a socket the kernel has marked as Squids for TPROXY. It needs Squid
or the rewriter to bypass the rewriter fetch if the request was coming
from the re-writer on a Squid IP (or, localhost). Or to byass TPROXY
globally traffic generated internally by the Squid box.
the rewritter has a log function build-in and only when it's redirecting
and with tproxy squid is doing this thing.
on regular forward proxy everything is working fine.
my config is the basic one with the exception of tproxy and the
rewritter
#start lines added
http_port 3129 tproxy
url_rewrite_program /opt/nginx.cache.rb
url_rewrite_host_header off
If the domain is being changed in the URL Host: header re-writing ON is
critical if the traffic is going back to a tproxy or intercept port.
Given the above loop is likely, this could be the problem.
#end lines added
so : with the 3.2 branch it works but not on 3.1.(3.1.10-3.1.18)
also i cant compile the 3.2 branch on fedora 15 cause always it ends up
with some error.
i need to know the list of dependencies for compilation.
Your guess is as good as mine. It is specific to the features you are
building. The official Fedora RPM or its documentation should be a good
guideline for what Fedora packages are related or needed.
i had some sasl problem and i installed the sasl dev libs but now its
stuck on ftp error:
g++: warning: switch ג-fhuge-objectsג is no longer supported
ftp.cc: In function גvoid ftpReadEPSV(FtpStateData*)ג:
ftp.cc:2371:9: error: variable גnג set but not used
[-Werror=unused-but-set-variable]
cc1plus: all warnings being treated as errors
Aha. That was fixed as part of a later update. There was a missing
condition in the if() statement around line 2440. The code there should
contain the following, with line 2371 the definition of "int n;" moved
down as shown:
char h1, h2, h3, h4;
unsigned short port;
int n = sscanf(buf, "(%c%c%c%hu%c)", &h1, &h2, &h3, &port, &h4);
if (n < 4 || h1 != h2 || h1 != h3 || h1 != h4) {
debugs(9, DBG_IMPORTANT, "Invalid EPSV reply from " <<
Amos
