On 26/02/2014 8:06 p.m., Jerry OELoo wrote: > Hi Amos: > Thanks for your quick feedback. > 1) I do not much understand your said about connect to host > 10.64.12.100, I just find it in B (10.64.12.101) squid cache.log, > It is the reason your ssl-bump is not working. The SSL connection is not actually going to any relevant web server, but being connected back to the client IP. The ORIGINAL_DST indicates that it was the IP address details for server taken from the TCP packets on the client->server connection which was intercepted into Squid. These connections show up as client IP being server if you have one of these happening: * Linux TPROXY mechanism used to intercept, but "intercept" flag used on the port. * client making explicitly configured (PAC file, environment variable or browser config settings) connections directly to the proxy port. > 2) I do not add any other setting in squid.conf about interception. > I mean do you have iptables settings using DNAT, REDIRECT or TPROXY targets to point the port 443 traffic at the Squid https_port ? > 3) As you mentioned, https_port requires NAT interception, so in my > scenario, A, B are in the same LAN, and I want to A use B as HTTPS > proxy, and I want to use SSL bump to monitor A's HTTPS content. so is > there any way that can meet it? Yes. What you have shodul be enough for the Squid setup. However interceptio is done in teh networking layers... 1) you must first *route* the port 443 packets through the Squid box. 2) you must TPROXY/DNAT/REDIRECT *intercept* the packets into teh Squid listenign port. 3) catch the packets in Squid and ssl-bump. You have show that you are doing (3). The problem is happening somewhere at (1) or (2). Amos
