This is working production server. I've checked configuration twice. See no problem. Here: # ------------------------------------- # Access parameters # ------------------------------------- # Deny requests to unsafe ports http_access deny !Safe_ports # Instant messengers include include "/usr/local/squid/etc/acl.im.include" # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager http_access deny to_localhost # Allow purge from localhost http_access allow PURGE localhost http_access deny PURGE # Block torrent files acl TorrentFiles rep_mime_type mime-type application/x-bittorrent http_reply_access deny TorrentFiles deny_info TCP_RESET TorrentFiles # No cache directives cache deny dont_cache_url cache allow all # 302 loop acl text_mime rep_mime_type text/html text/plain acl http302 http_status 302 store_miss deny text_mime http302 send_hit deny text_mime http302 # Windows updates rules http_access allow CONNECT wuCONNECT localnet http_access allow CONNECT wuCONNECT localhost http_access allow windowsupdate localnet http_access allow windowsupdate localhost # SSL bump rules acl DiscoverSNIHost at_step SslBump1 acl NoSSLIntercept ssl::server_name_regex "/usr/local/squid/etc/acl.url.nobump" ssl_bump peek DiscoverSNIHost ssl_bump splice DiscoverSNIHost icq ssl_bump splice DiscoverSNIHost icqip icqport ssl_bump splice NoSSLIntercept ssl_bump bump all # Rule allowing access from local networks http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all is ok. I'm only on doubt about this: http_access deny to_localhost but it is recommended to use long time, as documented: # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on "localhost" is a local user #http_access deny to_localhost and has no visible effect to comment out this line. I have no idea, what can block access. 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
