On 22/01/20 7:39 am, aashutosh kalyankar wrote: > The problem I am seeing is the intercept port initiates HTTP connection > to self-IP instead of the web server IP it gets from the DNS request. Neither of those IPs should be used. Self-IP indicates that the traffic is being delivered to the proxy port as explicit proxy traffic. Or that the NAT system is broken. We usually get this complaint from people who are testing their proxy by sending traffic directly to the proxy port. DNS is only involved to validate the HTTP Host header against the IP address to forbid caching dangerous contents. > Filtered Tcpdump > screenshot @ https://drive.google.com/open?id=0ByReiwdSAAY_VXBPTjF1M3dYTnBTTnhFVnRocXFveUlNSlNj > Screenshots are rarely useful. You are logging level 11,3 to cache.log, so there should be full HTTP message traces with related connection details and flow direction (client vs server). That would be more useful. What I do see in the image is several "GET http://"; lines. That absolute-form URL syntax is for explicit proxy traffic. Traffic intercepted from port 80 or 443 would use origin-form URLs. - This reinforces the idea that you are probably testing the proxy wrong - eg direct curl requests to the proxy? > Server IP: Eth0: IP: 172.22.22.148/26 (Same > eth0 interface reaches the internet gateway). > Configurations for > 1) Nat table: > Chain PREROUTING(policy ACCEPT 23 packets, 1632 bytes) > num pkts bytes target prot opt in out source > destination > 1 66 3960 REDIRECT tcp -- eth0 * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:80 /* > Redirect http traffic eth0:80 to eth0:3128 */ redir ports 3128 > You are missing the PREROUTING rule which would ACCEPT traffic outbound from the proxy to port 80. This config page details what you need for REDIRECT interception on iptables: <https://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect> Note that it does not place the intercept flag on port 3128. That is because Squid will generate URLs with its hostname and that port for clients to use directly when needed (error page contents, manager reports, etc). > Please let me know if I am missing some conf or the next steps I should > try to get this running. > Firstly, add that missing NAT rule. Secondly, make sure that your tests are accurately emulating how clients would "use" the proxy. That means making connections from a test machine directly to the Internet and seeing if the routing and NAT delivers the traffic to Squid properly. - Use cache.log to view the traffic coming into the proxy. It will be request messages with a prefix line indicating "Client HTTP request". Make sure that prefix line says the remote Internet IP address and port 80/443 you were testing with. - If you want confirm that access.log has a transaction entry for the URL you tested with ORIGINAL_DST and the server IP. Thirdly, some squid.conf improvements for other problems you have either not noticed or not encountered yet: > 3) Squid.conf > ... > acl my_machine src 172.22.22.0/24 > http_access allow my_machine > acl ap_clients src 172.16.10.0/24 > acl local_clients src 172.18.10.0/24 > acl localnet src 10.0.0.0/8 ... > http_access allow localnet > http_access allow ap_clients > http_access allow local_clients It looks sub-optimal to have these as separate ACLs. May as well use config comments to document what ranges are which clients and put them all in localnet (that is what it is for). eg: # AP clients acl localnet src 172.16.10.0/24 # Local clients acl localnet src 172.18.10.0/24 # LAN acl localnet src 10.0.0.0/8 http_access allow localnet > acl purge method PURGE > http_access deny purge PURGE is largely obsoleted (by HTCP CLR feature) and requires Squid to perform a relatively large amount of processing per-request. Unless you have tools that use it specifically it is best to remove all mention of it from the config file to let Squid avoid all that work. If any mention remains Squid will auto-activate the cache indexing work. If you do have tools using it. Then it is past time to consider/plan moving those tools and Squid to using HTCP CLR instead. > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports ... this is where all your custom http_access rules are supposed to be. The Safe_ports and SSL_Ports lines above are DoS and hijack protections. * DoS protections need to be first to do their job of minimizing the CPU impact effectively. It is counter productive to have allow's earlier than here. * It is risky to let clients hijack the proxy and Squid cannot handle native traffic to or from those ports anyway. If you need a specific port available > http_reply_access allow all Above is the default reply handling. No need to specify. > http_access deny all > http_port 8080 > http_port 172.22.22.148:3128 intercept > https_port 172.22.22.148:3129 intercept ssl-bump cert=/etc/squid/ssl_certs/myCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB You do need at least one non-intercept port for the direct-to-proxy communications that are needed occasionally. Port 3128 is reserved for that. It is best to pick a random other port number for the intercepted traffic to arrive at and leave 3128 for the normal proxy traffic. > acl step1 at_step SslBump1 > ssl_bump peek step1 > ssl_bump bump all NP: while this "works" bumping without any details about the server (obtained at step2) can cause a lot of connection compatibility problems and undesirable security side effects. Prefer to stare at step2 and bump at step 3. Do this step2 bump only as a last-resort (ie restrict it to sites that are broken and cannot be worked around in other ways). > host_verify_strict off The above is the default, no need to specify. > acl oyster-vpn-test dstdomain .oyster-vpn-test.com > cache deny oyster-vpn-test > visible_hostname togo.mtv.corp.google.com Er ... AFAIK Google does not use that domain for their machine hostnames. You sure you want to advertise your network as *.google.com ? Also, you only need a visible_hostname line if Squid is unable to pull the machines hostname from the OS configuration. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
