On 10/07/2013 2:12 a.m., x-man wrote:
Hello,
recently migrated from squid 3.1.19 to 3.3.5, and under 3.1.19 I was having
perfect TPROXY setup working, and now absolutely same config is failing in
3.3.5
The only change related to TPROXY between 3.1 and 3.3 is the addition of
HTTP Host: header security.
Squid 3.3 is not only spoofing the client IP on the outgoing traffic but
is also sending any traffic which fails the Host: validation direct to
the original server IP being used by the client.
This is the log I managed to get
91.239.13.61 is the web site i'm trying to open
and 192.168.1.106 is my test PC IP address
The browser shows error: "Error 324 (net::ERR_EMPTY_RESPONSE): The server
closed the connection without sending any data."
What can be the problem, and is it somehow related to this BUG #3329:
---
2013/07/09 19:39:04.523 kid1| Connection.cc(32) ~Connection: BUG #3329:
Orphan Comm::Connection: local=91.239.13.61:80 remote=192.168.1.106:59222 FD
12 flags=17
-----
2013/07/09 19:39:04.523 kid1| Intercept.cc(364) Lookup: address BEGIN:
me/client= 91.239.13.61:80, destination/me= 192.168.1.106:59222
2013/07/09 19:39:04.523 kid1| TcpAcceptor.cc(264) acceptOne: Listener:
local=[::]:8081 remote=[::] FD 15 flags=25 accepted new connection
local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17 handler
Subscription: 0x254b210*1
2013/07/09 19:39:04.523 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall
httpAccept constructed, this=0x25529e0 [call141]
2013/07/09 19:39:04.523 kid1| cbdata.cc(419) cbdataInternalLock: cbdataLock:
0x21920e8=3
2013/07/09 19:39:04.523 kid1| AsyncCall.cc(85) ScheduleCall:
TcpAcceptor.cc(292) will call httpAccept(local=91.239.13.61:80
remote=192.168.1.106:59222 FD 12 flags=17, flag=-1, data=0x21920e8)
[call141]
2013/07/09 19:39:04.523 kid1| ModEpoll.cc(139) SetSelect: FD 15, type=1,
handler=1, client_data=0x254cc58, timeout=0
2013/07/09 19:39:04.523 kid1| AsyncCallQueue.cc(51) fireNext: entering
httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17,
flag=-1, data=0x21920e8)
2013/07/09 19:39:04.523 kid1| AsyncCall.cc(30) make: make call httpAccept
[call141]
2013/07/09 19:39:04.523 kid1| cbdata.cc(510) cbdataReferenceValid:
cbdataReferenceValid: 0x21920e8
2013/07/09 19:39:04.523 kid1| client_side.cc(3335) httpAccept: httpAccept:
local=[::]:8081 remote=[::] FD 15 flags=25: accept failure: (0) No error.
Here is the problem. For some reason Squid is encountering an error
accept()'ing the new connection, but there is no system code or message
available about it.
Can you try with the latest 3.3 release please? any fix which you get
will be for the latest code.
2013/07/09 19:39:04.523 kid1| AsyncCallQueue.cc(53) fireNext: leaving
httpAccept(local=91.239.13.61:80 remote=192.168.1.106:59222 FD 12 flags=17,
flag=-1, data=0x21920e8)
2013/07/09 19:39:04.523 kid1| cbdata.cc(456) cbdataInternalUnlock:
cbdataUnlock: 0x21920e8=2
2013/07/09 19:39:04.523 kid1| Connection.cc(32) ~Connection: BUG #3329:
Orphan Comm::Connection: local=91.239.13.61:80 remote=192.168.1.106:59222 FD
12 flags=17
Please share your thoughts....
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-3-3-5-problems-with-Tproxy-tp4660968.html
Sent from the Squid - Users mailing list archive at Nabble.com.
