[squid-users] Problems with Linux Worstations
Marcio Demetrio Bacci
marciobacci at gmail.com
Mon Sep 5 16:25:19 UTC 2016
Hi Amos
Now, my squid.conf is as follow (very simple):
############ START #################
http_port 3128
debug_options 11,2
cache_mem 512 MB
cache_swap_low 80
cache_swap_high 90
maximum_object_size 512 MB
minimum_object_size 0 KB
maximum_object_size_in_memory 4096 KB
cache_replacement_policy heap LFUDA
memory_replacement_policy heap LFUDA
fqdncache_size 1024
### Parametros de atualizacao da memoria cache
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
### Localizacao dos logs
access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_dir aufs /var/spool/squid3 600 16 256
visible_hostname proxy
### acls
acl localhost src 192.168.200.7/32
acl to_localhost dst 192.168.200.7/32
acl SSL_ports port 22 443 563 7071 10000
acl Safe_ports port 21 70 80 88 210 280 389 443 488 563 591 777
1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny purge
auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/passwd
auth_param basic children 5
auth_param basic realm CMS
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
### Exige autenticacao
acl autenticados proxy_auth REQUIRED
http_access deny !autenticados
### Rede do CMS #####
acl lannet src 192.168.200.0/22
### Nega acesso de quem nao esta na rede local do CMS
http_access allow lannet
http_access allow localhost
#negando o acesso para todos que nao estiverem nas regras anteriores
http_access deny all
### Erros em portugues
error_directory /usr/share/squid3/errors/pt-br
#cache_effective_user proxy
coredump_dir /var/spool/squid3
########## END ###########################
I have some doubts:
1) I open my browser to test the authentication. It seems OK, but when I
open new tab in browser the Squid3 ask the user and password again. Is this
normal behavior ?
2) Is necessary to declare LOCALHOST acl as "acl localhost src
192.168.200.7/32" ?
3) Isn't necessary MANAGER acl as "acl manager proto cache_object" ?
4) Is correct order of the ACL in my squid.conf ? How do I improve it?
5) In my access.log, I have saw many "TCP_MISS/200". Does mean only the
website is not in cache or is a strange behavior?
Sorry, but I'm still learning about Squid!
Regards,
Márcio
2016-09-05 1:17 GMT-03:00 Amos Jeffries <squid3 at treenet.co.nz>:
> On 5/09/2016 10:41 a.m., Marcio Demetrio Bacci wrote:
> > I have used debug_options 11,2 in squid.conf file. After I have following
> > results in logs files:
> >
> > /var/log/squid3/access.log
> > 1473026084.048 253 192.168.200.85 TCP_MISS_ABORTED/000 0 POST
> > http://m.addthis.com/live/red_lojson/100eng.json? marcio HIER_NONE/- -
> > 1473026086.275 0 192.168.200.85 TCP_DENIED/407 3792 CONNECT
> > tiles.services.mozilla.com:443 - HIER_NONE/- text/html
> > 1473026086.778 0 192.168.200.85 TCP_DENIED/407 3995 GET
> > http://start.ubuntu.com/14.04/Google/? - HIER_NONE/- text/html
> > 1473026088.908 0 192.168.200.85 TCP_DENIED/407 3796 CONNECT
> > shavar.services.mozilla.com:443 - HIER_NONE/- text/html
> > 1473026091.932 0 192.168.200.85 TCP_DENIED/407 3780 CONNECT
> > self-repair.mozilla.org:443 - HIER_NONE/- text/html
> > 1473026096.418 180 192.168.200.85 TCP_MISS/200 960 POST
> > http://ocsp.digicert.com/ marcio HIER_DIRECT/192.16.58.8
> > application/ocsp-response
> > 1473026096.467 85 192.168.200.85 TCP_MISS/200 960 POST
> > http://ocsp.digicert.com/ marcio HIER_DIRECT/192.16.58.8
> > application/ocsp-response
> > 1473026102.051 525 192.168.200.85 TCP_REFRESH_UNMODIFIED/200 2907 GET
> > http://start.ubuntu.com/14.04/Google/? marcio HIER_DIRECT/91.189.90.41
> > text/html
> > 1473026102.091 0 192.168.200.85 TCP_HIT/200 22099 GET
> > http://start.ubuntu.com/12.04/sprite.png marcio HIER_NONE/- image/png
> > 1473026104.855 0 10.133.85.3 TCP_DENIED/407 3929 GET
> > http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/
> authrootstl.cab?
> > - HIER_NONE/- text/html
> > 1473026146.453 83 192.168.200.85 TCP_MISS/200 960 POST
> > http://ocsp.digicert.com/ marcio HIER_DIRECT/192.16.58.8
> > application/ocsp-response
> > 1473026147.447 83 192.168.200.85 TCP_MISS/200 960 POST
> > http://ocsp.digicert.com/ marcio HIER_DIRECT/192.16.58.8
> > application/ocsp-response
> > 1473026148.923 0 192.168.200.85 TCP_DENIED/407 3796 CONNECT
> > shavar.services.mozilla.com:443 - HIER_NONE/- text/html
> > 1473026157.117 61506 192.168.200.85 TCP_MISS/200 3525 CONNECT
> > tiles.services.mozilla.com:443 marcio HIER_DIRECT/52.24.123.95 -
> > 1473026157.195 61584 192.168.200.85 TCP_MISS/200 4521 CONNECT
> > self-repair.mozilla.org:443 marcio HIER_DIRECT/54.69.9.44 -
> > 1473026160.190 63085 192.168.200.85 TCP_MISS/200 5449 CONNECT
> > self-repair.mozilla.org:443 marcio HIER_DIRECT/54.69.9.44 -
> > 1473026204.518 0 192.168.200.85 TCP_DENIED/407 3780 CONNECT
> > safebrowsing.google.com:443 - HIER_NONE/- text/html
> > 1473026207.807 62056 192.168.200.85 TCP_MISS/200 3686 CONNECT
> > incoming.telemetry.mozilla.org:443 marcio HIER_DIRECT/52.89.83.186 -
> > 1473026207.808 61159 192.168.200.85 TCP_MISS/200 390 CONNECT
> > incoming.telemetry.mozilla.org:443 marcio HIER_DIRECT/52.89.83.186 -
> > 1473026207.808 61159 192.168.200.85 TCP_MISS/200 390 CONNECT
> > incoming.telemetry.mozilla.org:443 marcio HIER_DIRECT/52.89.83.186 -
> > 1473026207.808 61160 192.168.200.85 TCP_MISS/200 390 CONNECT
> > incoming.telemetry.mozilla.org:443 marcio HIER_DIRECT/52.89.83.186 -
> > 1473026207.809 61160 192.168.200.85 TCP_MISS/200 390 CONNECT
> > incoming.telemetry.mozilla.org:443 marcio HIER_DIRECT/52.89.83.186 -
> > 1473026207.814 61165 192.168.200.85 TCP_MISS/200 390 CONNECT
> > incoming.telemetry.mozilla.org:443 marcio HIER_DIRECT/52.89.83.186 -
> > 1473026207.866 61052 192.168.200.85 TCP_MISS/200 3821 CONNECT
> > aus5.mozilla.org:443 marcio HIER_DIRECT/52.34.235.152 -
> > 1473026212.687 116018 192.168.200.85 TCP_MISS/200 61971 CONNECT
> > normandy.cdn.mozilla.net:443 marcio HIER_DIRECT/52.84.177.125 -
> > 1473026264.532 0 192.168.200.85 TCP_DENIED/407 3780 CONNECT
> > safebrowsing.google.com:443 - HIER_NONE/- text/html
> > 1473026299.647 0 10.133.85.3 TCP_DENIED/407 3813 CONNECT
> > iecvlist.microsoft.com:443 - HIER_NONE/- text/html
> > 1473026335.221 0 10.133.85.3 TCP_DENIED/407 3813 CONNECT
> > ieonline.microsoft.com:443 - HIER_NONE/- text/html
> > 1473026592.061 6624 10.133.85.3 TCP_MISS/200 3582 CONNECT
> > forum.zentyal.org:443 marcio HIER_DIRECT/162.13.13.134 -
>
> Notice how the 407 occur in bunches. 2-3 getting a 407 reject, then many
> requests going through with user credentials. Then again some without
> any getting a 407.
> Those bunches of 407 will be matching some type of credentials timeout
> in the browser, or opening of new tabs.
>
>
> This request below is the only one from 192.168.200.96 so appears to be
> the one you provide cache.log trace for...
>
>
> > 1473026793.073 0 192.168.200.96 TCP_DENIED/407 3780 CONNECT
> > safebrowsing.google.com:443 - HIER_NONE/- text/html
> >
> > /var/log/squid3/cache.log
> >
> > ----------
> > 2016/09/04 19:06:33.073 kid1| client_side.cc(2407) parseHttpRequest: HTTP
> > Client local=192.168.200.7:3128 remote=192.168.200.96:56302 FD 12
> flags=1
> > 2016/09/04 19:06:33.073 kid1| client_side.cc(2408) parseHttpRequest: HTTP
> > Client REQUEST:
> > ---------
> > CONNECT safebrowsing.google.com:443 HTTP/1.1
> > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0)
> Gecko/20100101
> > Firefox/35.0
> > Proxy-Connection: keep-alive
> > Connection: keep-alive
> > Host: safebrowsing.google.com:443
>
> Notice the abence of any Proxy-Authorization header containing credentials.
>
> >
> >
> > ----------
> > 2016/09/04 19:06:33.073 kid1| client_side.cc(1459) sendStartOfMessage:
> HTTP
> > Client local=192.168.200.7:3128 remote=192.168.200.96:56302 FD 12
> flags=1
> > 2016/09/04 19:06:33.073 kid1| client_side.cc(1460) sendStartOfMessage:
> HTTP
> > Client REPLY:
> > ---------
> > HTTP/1.1 407 Proxy Authentication Required
> > Server: squid/3.4.8
> > Mime-Version: 1.0
> > Date: Sun, 04 Sep 2016 22:06:33 GMT
> > Content-Type: text/html
> > Content-Length: 3357
> > X-Squid-Error: *ERR_CACHE_ACCESS_DENIED 0*
> > Proxy-Authenticate: Basic realm="CMS"
>
> That realm="CMS" does not match the realm value of "AUTENTICACAO" which
> your earlier config contained.
>
> Unless you changed your auth_param settings that is a sign that some
> other proxy is generating that response message. BUT, your access.log
> entry shows no server being contacted.
>
>
>
> > X-Cache: MISS from proxy.cms.ensino.br
> > X-Cache-Lookup: NONE from proxy.cms.ensino.br:3128
> > Via: 1.1 proxy.cms.ensino.br (squid/3.4.8)
> > Connection: keep-alive
> >
> > ----------
> >
> > Sorry, but I didn't discover the problem!
> >
> > Anybody have an idea?
>
> If you altered your squid.conf settings as above in the auth details,
> did you also remove 192.168.200.7 from the "localhost" ACL ?
>
> Your rule "http_access allow localhost" occurs before anything that
> requires authentication. That means these requests coming from
> 192.168.200.7 to your proxy would not use authentication for the above
> CONNECT request. So no reason for your proxy to generate any 407 response.
>
>
> Amos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160905/285d83ad/attachment-0001.html>
More information about the squid-users
mailing list