25.01.2017 1:10, Alex Rousskov пишет: > On 01/24/2017 11:33 AM, Yuri Voinov wrote: > >>> 1485279884.648 0 - TCP_DENIED/403 3574 GET >>> http://repository.certum.pl/ca.cer - HIER_NONE/- text/html;charset=utf-8 > >> http_access deny !Safe_ports > Probably does not match -- 80 is a safe port. > > >> # Instant messengers include >> include "/usr/local/squid/etc/acl.im.include" > I am guessing these do not match or are irrelevant. Yes, irrelevant. > > >> # Deny CONNECT to other than SSL ports >> http_access deny CONNECT !SSL_ports > Does not match. This is a GET request. Exactly. > > >> # Only allow cachemgr access from localhost >> http_access allow localhost manager >> http_access deny manager > Probably do not match. This is not a cache manager request although I > have not checked how Squid identifies those exactly. > > >> http_access deny to_localhost > Does not match. The destination is not localhost. Yes, destination is squid itself. From squid to squid. > > >> # Allow purge from localhost >> http_access allow PURGE localhost >> http_access deny PURGE > Do not match. This is a GET request, not PURGE. > > >> # Block torrent files >> acl TorrentFiles rep_mime_type mime-type application/x-bittorrent >> http_reply_access deny TorrentFiles > Does not match. There was no response [with an application/x-bittorrent > MIME type]. > > >> # Windows updates rules >> http_access allow CONNECT wuCONNECT localnet >> http_access allow CONNECT wuCONNECT localhost > Do not match. This is a GET request, not CONNECT. > > >> http_access allow windowsupdate localnet >> http_access allow windowsupdate localhost > Probably do not match. The internal transaction is not associated with a > to-Squid connection coming from localnet or localhost. > > >> # Rule allowing access from local networks >> http_access allow localnet >> http_access allow localhost > Probably do not match. The internal transaction is not associated with a > to-Squid connection coming from localnet or localhost. Exactly. > > >> # And finally deny all other access to this proxy >> http_access deny all > Matches! But! This is recommended final deny rule, if I omit it - squid will adds it silently by default, like normal firewall! > > >> I have no idea, what can block access. > That much was clear from the time you asked the question. I bet your > last http_access rule that denies all other connection matches, but I > would still ask Squid. Squid knows why it blocks (or does not allow) > access. There are several ways to ask Squid, including increasing > debugging verbosity when reproducing the problem, adding the matching > ACL to the error message, using custom error messages for different > http_access deny lines, etc. Yes. I've tought about debugging. > > These methods are not easy, pleasant, quick, or human-friendly, > unfortunately, but you are a very capable sysadmin with more than enough > Squid knowledge to find the blocking directive/ACL, especially for a > problem that can be isolated to two HTTP transactions. > > Once we know what directive/ACL blocks, we may be able to figure out a > workaround, propose a bug fix, etc. For example, if my guess is correct > -- the "deny all" rule has matched -- then you would need to add a rule > to allow internal requests, including the ones that fetch those missing > certificates. Here is in doubt. I tought I've good knowlegde about squid's acl. But I don't know (on first look) special ACL rule to permit internal access from squid to squid. I'm reading documented config - there is no special ACL type to permit/deny internal access. Hmmmmmmmmmm. It looks squid blocks own internal access to itself, but permits the same request from outside. Can this be bug? Or I lost something? > > > HTH, > > Alex. > > >> 25.01.2017 0:27, Alex Rousskov пишет: >>> On 01/24/2017 11:19 AM, Yuri Voinov wrote: >>> >>>> It is downloads directly via proxy from localhost: >>>> As I understand, downloader also access via localhost, right? >>> This is incorrect. Downloader does not have a concept of an HTTP client >>> which sends the request to Squid so "via localhost" or "via any client >>> source address" does not apply to Downloader transactions. In other >>> words, there is no client [source address] for Downloader requests. >>> >>> Unfortunately, I do not know exactly what effect that lack of info has >>> on what ACLs (in part because there are too many of them and because >>> lack of info is often treated inconsistently by various ACLs). Thus, I >>> continue to recommend finding out which directive/ACL denied Downloader >>> access as the first step. >>> >>> Alex. >>> >>> >>>> 25.01.2017 0:16, Alex Rousskov пишет: >>>>> On 01/24/2017 10:48 AM, Yuri Voinov wrote: >>>>> >>>>>> It seems 4.0.17 tries to download certs but gives deny somewhere. >>>>>> However, same URL with wget via same proxy works >>>>>> Why? >>>>> Most likely, your http_access or similar rules deny internal download >>>>> transactions but allow external ones. This is possible, for example, if >>>>> your access rules use client information. Internal transactions (ESI, >>>>> missing certificate fetching, Cache Digests, etc.) do not have an >>>>> associated client. >>>>> >>>>> The standard denial troubleshooting procedure applies here: Start with >>>>> finding out which directive/ACL denies access. I am _not_ implying that >>>>> this is easy to do.
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
