On 19/06/19 1:37 am, Ralf Hildebrandt wrote: > From my log: > ============ > > Mon Jun 17 07:28:47 2019 36 10.39.68.232 TCP_DENIED/302 390 CONNECT trx.adscale.de:443 - HIER_NONE/- text/html accessRule=ensiloip - > > Now I tried find out why trx.adscale.de is being denied. I'm using squid-5 with annotate_transaction: > > acl markensiloip annotate_transaction accessRule=ensiloip > acl ensiloip dst "/etc/squid5/manual-ensilo-ipblocklist.acl" > http_access deny ensiloip markensiloip > > > So I *DO* know that /etc/squid5/manual-ensilo-ipblocklist.acl must be > the reason for the refusal -- so I resolved trx.adscale.de and got: > > # host trx.adscale.de > trx.adscale.de is an alias for san.adscale.de.edgekey.net. > san.adscale.de.edgekey.net is an alias for e9040.g.akamaiedge.net. > e9040.g.akamaiedge.net has address 95.100.198.56 > > > So a CDN is being used. And alas: > > > # fgrep -c 95.100.198.56 /etc/squid5/manual-ensilo-ipblocklist.acl > 0 > # fgrep -c 95.100.198 /etc/squid5/manual-ensilo-ipblocklist.acl > 0 > # fgrep -c 95.100 /etc/squid5/manual-ensilo-ipblocklist.acl > 0 > > So, I guss the IP must have change between to time "trx.adscale.de" was > blocked and now. Or, its IPv6 is listed. Or, your test was done from a different machine than the one running Squid. Or, the DNS query packet arrived at Akamai via a different DNS recursive resolver this time. Or, the Internet route between your network and Akamai DNS changed slightly. (Don't we all love query-dependent DNS responses.) > > How can I log the IP "trx.adscale.de" resolved to when the rejection happened? > Your DNS resolver logs should contain that info. If the check is close to the transaction time, then your Squid ipcache manager report should list all the IPs that domain has. Other than that, your best bet would be the debug trace of what ACLs are matching. "debug_options 28,4" should do it. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
