Hi Amos,
Thank you for the walkthrough..
Instead of having to play with tproxy on haproxy currently, I figured
i'd try a simpler route..
The purpose of this setup, is to "jump around" a firewall issue with a
sh#! firewall, which in order to filter http and https traffic
appearently drops 5-15%.. and in 6 months noone has seem willing/able to
fix it :(
I've put squid directly on the 10.43.18.181 (previously haproxy) ip -
and changed to: http_port 80 intercept
I tried this on the client (being on other subnet):
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination
10.43.18.181:80
and the traffic looped in exactly the same way :(
Amos Jeffries wrote on 03/10/2015 05:45 PM:
On 11/03/2015 4:08 a.m., Klavs Klavsen wrote:
hmm..
I've read the config examples..
I would very much like to understand how/why it works, if I've setup a
client to route package to squid (instead of trying to send directly)..
I suggest diagramming your network traffic flow, writing down the TCP
packet src/dst IP:port values on each connection.
"Normal" interception operation showing your loop:
1) curl thinks its talking to Internet server
src ip-of-curl:*
dst ip-of-bt.dk:80
2) NAT diverts the packet to haproxy
src ip-of-curl:*
dst ip-of-haproxy-machine:*
3) haproxy knows its talking to Squid
src ip-of-haproxy-machine:*
dst 10.43.18.165:3129
4) Squid machine reports un-mangled NAT is ...
src ip-of-haproxy-machine:*
dst 10.43.18.165:3129
5) Squid contacts dst-IP to fetch the HTTP request
src 10.43.18.165:*
dst 10.43.18.165:3129
6) repeat from 4 (but with src now 10.43.18.165:*) until
a) machine runs out of memory,
b) machine runs out of TCP sockets,
c) machine runs out of disk space logging errors, or
d) Squid notices Via header loop and rejects request.
A "Normal" connection directly to squid port:
1) curl thinks its talking to Internet server on 10.43.18.165:3129
src ip-of-curl:*
dst 10.43.18.165:3129
2) Squid machine reports un-mangled NAT is ...
src ip-of-curl:*
dst 10.43.18.165:3129
3) Squid contacts dst-IP to fetch the HTTP request
src 10.43.18.165:*
dst 10.43.18.165:3129
4) repeat from 2 (but with src now 10.43.18.165:*) until
a) machine runs out of memory,
b) machine runs out of TCP sockets,
c) machine runs out of disk space logging errors, or
d) Squid notices Via header loop and rejects request.
Confirm it against wireshark packet traces of what is coming *in* to the
Squid machine.
Squid undoes the NAT mangling done on the machine its running. Any NAT
changes prior to that is unknowable. NAT un-mangling can sometimes
appear to work in Squid if haproxy runs on the same machine BUT, some
NAT lookup requires correct TCP socket and some require particular
IP:port ordering so its unrelible.
The Squid access.log lines with ORIGINAL_DST show what client src-IP and
dst-IP Squid received after NAT un-mangling. Though you have to take
care to subtract the duration value from the line timestamp to get the
order right for loops.
I'm trying to follow this on a test client (haven't gotten it working yet):
http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
(where squid is amongst the internal clients - actually on it's own vlan
- but it's not the default route)
If its on its own VLAN then its not "among the clients".
"among the clients" means a bunch of machines all on the same LAN
subnet, one of which is the Squid proxy. They can talk directly to each
other without involving the router so you can hit the triangular routing
problem and have to account for it in your forwarding and/or NAT rules.
If you have Squid on a separate subnet or VLAN with all packets going
via the router, that is a DMZ subnet. The router sees all packets and
can adjusts them right, so triangular routing problem is avoided.
meanwhile I tried pointing to the haproxy - which then forwards requests
in tcp mode, to squid server port 3129.
If I just send to haproxy directly, I get the loop and this in the
accesslog:
1425998994.271 0 10.43.18.165 TCP_MISS_ABORTED/000 0 GET
http://www.bt.dk/ - ORIGINAL_DST/10.43.18.165 -
when doing:
curl -H "Host: www.bt.dk" http://proxy-haproxy-ip/
10.43.18.165 is the ip of squid server behind haproxy.
Methinks that haproxy is still sending to the Squid port configured with
"intercept" option.
A connection between two proxies is explicitly configured. Thus a normal
forward-proxy connection, no special port flags required.
The log line is also showing haproxy to be vulnerable to CVE-2009-0801.
If your Squid and haproxy are recent enough they could use the PROXY
protocol to exchange the original client connections TCP/IP details.
I've not tested it for this myself but that may also allow Squid with an
intercept port to both handle the traffic okay (PROXY protocol override
the NAT lookups), and protect against the CVE-2009-0801 vulnerability in
haproxy ('intercept' flags existence makes Squid do the security checks).
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
--
Regards,
Klavs Klavsen, GSEC - kl@xxxxxxx - http://www.vsen.dk - Tlf. 61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
