On 7/04/19 7:01 pm, jyliu wrote: > Thanks for replying so quickly! I really appreciate it! > > I am very new to Squid (start a week ago) so I probably will make dumb > mistakes. > > I just search this forum and find another post similar to my problem, and > your answer is: >> http_port xxx.xxx.xxx.14:3128 name=0 >> acl ip1 myportname 0 >> tcp_outgoing_address xxx.xxx.xxx.14 ip1 > > Is this the same as what I am previously doing? No. The myportname ACL tests the non-changing name= setting of whichever http_port the requests TCP connection was received on. "myip" checks against the dynamically changing TCP connection port number the client used to connect to Squid. This may have nothing to do with the http_port port number. It just happens that your current tests are using the port 3128 to connect directly to the proxy so they both reach the same outcome. Correct configuration is to either use mytportname to match the squid.conf setting if that is what you want. Or use localport ACL to match the client connection dst-port value if that is what you want. >> http_port 3128 >> acl ip1 myip xxx.xxx.xxx.14 >> tcp_outgoing_address xxx.xxx.xxx.14 ip1 > > > > I check access.log it returns 407: > TCP_DENIED/407 3710 GET http://www.google.com/ test HIER_NONE/- text/html > So that is HTTP status "407 Proxy Authentication Required". Either the request has no credentials. Or any credentials given are not sufficient to perform the action being asked of the proxy. Other credentials are being requested by the proxy. > I am not sure how to put -d in squid.conf helper...But I add those > debug_options. See those auth_param and external_acl_type lines where the helper program command-lines are configured. Add -d to the helepr parameter list on those lines. Like so: auth_param basic program /usr/lib64/squid/basic_ncsa_auth -d \ /etc/squid/passwords external_acl_type userIp %SRC %LOGIN \ /usr/lib64/squid/ext_file_userip_acl -d \ -f /etc/squid/userIp.conf > > And here is cache.log file: ... > 2019/04/07 02:54:03.586 kid1| client_side.cc(2408) parseHttpRequest: HTTP > Client local=204.188.217.14:3128 remote=209.166.109.90:55394 FD 9 flags=1 > 2019/04/07 02:54:03.586 kid1| client_side.cc(2409) parseHttpRequest: HTTP > Client REQUEST: > --------- > GET http://www.google.com/ HTTP/1.1 > Host: www.google.com > Proxy-Authorization: Basic dGVzdDp0ZXN0 > User-Agent: curl/7.58.0 > Accept: */* > Proxy-Connection: Keep-Alive > > > ---------- > 2019/04/07 02:54:03.587 kid1| Checklist.cc(62) preCheck: 0x1777988 checking > slow rules > 2019/04/07 02:54:03.587 kid1| Acl.cc(157) matches: checking http_access > 2019/04/07 02:54:03.587 kid1| Acl.cc(157) matches: checking http_access#1 > 2019/04/07 02:54:03.587 kid1| Acl.cc(157) matches: checking !ncsa_users > 2019/04/07 02:54:03.587 kid1| AclProxyAuth.cc(143) checkForAsync: checking > password via authenticator > 2019/04/07 02:54:03.587 kid1| Starting new basicauthenticator helpers... > 2019/04/07 02:54:03.588 kid1| Acl.cc(62) AuthenticateAcl: returning 2 > sending credentials to helper. ... > 2019/04/07 02:54:03.602 kid1| Acl.cc(177) matches: checked: ncsa_users = 1 Credentials existed in the request. Login happened successfully ... > 2019/04/07 02:54:03.602 kid1| InnerNode.cc(90) resumeMatchingAt: checked: > !ncsa_users = 0 ... so "http_access deny !ncsa_users" passed. Moving on. ... > 2019/04/07 02:54:03.602 kid1| Acl.cc(157) matches: checking userIp > 2019/04/07 02:54:03.602 kid1| Acl.cc(177) matches: checked: userIp = 0 The external_acl_type helper found that "204.188.217.14 test" was not in your userIp.conf file. > 2019/04/07 02:54:03.602 kid1| InnerNode.cc(90) resumeMatchingAt: checked: > http_access#2 = 0 > 2019/04/07 02:54:03.602 kid1| InnerNode.cc(90) resumeMatchingAt: checked: > http_access = 0 > 2019/04/07 02:54:03.602 kid1| Checklist.cc(378) calcImplicitAnswer: > 0x1777988 NO match found, last action ALLOWED so returning DENIED This states that the "http_access deny all" rule you showed being in your config earlier does not exist. Last ACL to be tested being userIp - which used authentication credentials. So a different outcome may have happened if some other login was supplied by the client. ==> the 407 challenge is produced to get _different_ credentials that may pass the userIp check. > Client local=204.188.217.14:3128 remote=209.166.109.90:55394 FD 9 flags=1 > 2019/04/07 02:54:03.603 kid1| client_side.cc(1461) sendStartOfMessage: HTTP > Client REPLY: > --------- > HTTP/1.1 407 Proxy Authentication Required > Server: squid/3.4.14 > Mime-Version: 1.0 > Date: Sun, 07 Apr 2019 06:54:03 GMT > Content-Type: text/html > Content-Length: 3234 > X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 > Vary: Accept-Language > Content-Language: en > Proxy-Authenticate: Basic realm="Squid proxy-caching web server" > X-Cache: MISS from mx3.dealsbay.org > X-Cache-Lookup: NONE from mx3.dealsbay.org:3128 > Via: 1.1 mx3.dealsbay.org (squid/3.4.14) > Connection: keep-alive > > ---------- PS. The most current Squid release is 4.6. Please upgrade. There are a very large number of bug fixes and more than a few major security vulnerabilities fixed since 3.4.14. Ideally no version older than Squid-3.5.28 should be in use anymore. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
