> On 29/11/2014 2:40 a.m., Mark Riede wrote: > > Hello, > > > > I have a strange behavior with Squid 2.7.STABLE9 and local requests > > which should be intercept by the option deny_info. > > > 1) *Please* upgrade your Squid. 2.7 has been unsupported for more than 5 years now and is seriously out of date with modern web traffic needs. That is not an option. We are already migrating to an other software. > 2) "intercept" and how deny_info works are completely unrelated concepts. "intercept" was the wrong word. The word "match" ist more appropiate. > > I am using Squid as a reverse proxy. I have configured a list of > > subdomains (i.e. subdomain.domain.tld) in a file via the option > > dstdomain, which will be forwarded to the defined cache peer. > > There is an additional list of domains (i.e. *.domain.tld) which match > > via wildcard to all other domains, which are not absolutely defined > > yet and will be forwarded to a custom error page via the option > > deny_info. > > > > The problem is that requests forwarded to the ip of the server, i.e. > > 192.168.0.1, will be catched up by the option deny_info. But, when the > > request is forwarded to the ip of the localhost (127.0.0.1), the > > option deny_info will not match. > ?? *all* traffic to the cache_peer is "forwarded to the ip 127.0.0.1" > since that IP *is* the cache_peer's IP. Ok, I think it needs a little bit more explanation. External requests will be forwarded via nat to internal IP 192.168.0.1 and the option deny_info works well. But when the nginx sends a request to the squid with the destination IP 127.0.0.1 the option deny_info does not work. > 127.0.0.1 (and ::1) are special purpose IP addresses. Traffic is not permitted to go to/from it from a global-scope IP address. When you send to/from a localhost IP then it is mandatory for the TCP system to use the localhost IP as source. > > Now the strange behaviour is that requests to the ip of the localhost > > but with the destination domain subdomain.domain.tld will be answered > > successfully. I need a fix because clients get the custom error page > > for requests via http (NAT to 192.168.0.1) but not the same response > > via https (nginx to 127.0.0.1). I don´t know where or how I can fix > > this problem or do more debugging. > Why is nginx not forwarding proper HTTP messages with the relevant > Host: header contents to Squid? the HTTP message syntax is no different when sent over TLS port 443 as when sent over TCP port 80. Nginx is forwarding the request with a proper HTTP-Header because the option cache_peer is working well. We are able to cache HTTPS-Requests so far. It seems that the option deny_info does not work well. > - From your description it sounds like nginx is sending to Squid messages with URL https://127.0.0.1/* which cannot be expected to exist in your list of acceptible domains. > Also, why are you not using Squid to receive and direct both HTTP and HTTPS traffic to the relevant servers? > Squid accepts port 443 traffic with an https_port directive just fine. Because we are using the Squid for multiple clients and Squid in our version ist not able to handle multiple certificates. > > > > # Config http_access allow localhost > The above rule permits all traffic from 127.0.0.1 to go through this proxy *no matter what*. From your description that would be all traffic arriving from nginx **AND** any traffic you direct at > 127.0.0.1 IP from any other software. Thank you for your consideration. I will consider it. > It is a very bad thing to do, particularly for a reverse-proxy. Remove it and traffic from nginx (and yoru 127.0.0.1 tests) will start to obey the other rules. Not a complete fix, but required for Squid to work as you expect. > > acl foo dstdomain "/file" acl foo_deny dstdom_regex "/ file _deny" > > http_access allow foo > When testing this ACL with a raw-IP Squid will lookup reverse-DNS of the IPand compare the result with contents of /file. > Meaning 127.0.0.1 == "localhost" --> is "localhost" one of the peer hosted domain names? should not be. Which version was in use? Is it possible to override this behaviour? I don´t think it is the right location of the problem. Everything works well except the option deny_info. > > cache_peer 127.0.0.1 parent 8080 0 no-query originserver name=srv1 > login=PASS > > cache_peer_access srv1 allow foo cache_peer_access srv1 deny all > > deny_info ERR_FOO foo_deny http_access deny foo_deny http_access deny > > all > <snip> > The rest of these rules match your intended behaviour of Squid. > Amos > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > iQEcBAEBAgAGBQJUfDWaAAoJELJo5wb/XPRjfEYH/1KMTu400wRO0wmz6RURlUwB > 6jVEqWGc+rYV1hvtjZe5PtvJW8nMxF6idP0SU2aj/GWoGmcusrq413sAsoQhwEYT > lGAlDhU08c6aQ5r7ZyNY9TMNip8OJS6NPYEWV07Nw34QuJcQXbHUEC9VTAjboQqa > VYfnrBZIbMXFY3wkdhGkyNm4m/Uz5scOZ2lKAVabhZ4wHEu/NVMYISD3mEIHNiT7 > rLT9/dqZaj/KHn1Vb5Z31k3szija9ZMh2Gu6A5tg3TfpelBVrbCXFOzoHIJMN7es > eRScL64c2KZ1PMpTMrTUzq1ILcOIuXcVDSdcj610Tcp524u0ssQ1vteJqj8kFak= > =8Dhf > -----END PGP SIGNATURE----- > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
