Fast and Slow ACLs

Some ACL types require information which may not be already available to Squid. Checking them requires suspending work on the current request, querying some external source, and resuming work when the needed information becomes available. This is for example the case for DNS, authenticators or external authorization scripts. ACLs can thus be divided in FAST ACLs, which do not require going to external sources to be fulfilled, and SLOW ACLs, which do.

Fast ACLs include (as of squid 3.1.0.7):

• all (built-in)
• src
• dstdomain
• dstdom_regex
• myip
• arp
• src_as
• peername
• time
• url_regex
• urlpath_regex
• port
• myport
• myportname
• proto
• method
• http_status {R}
• browser
• referer_regex
• snmp_community
• maxconn
• max_user_ip
• req_mime_type
• req_header
• rep_mime_type {R}
• user_cert
• ca_cert

Slow ACLs include:

• dst
• dst_as
• srcdomain
• srcdom_regex
• ident
• ident_regex
• proxy_auth
• proxy_auth_regex
• external
• ext_user
• ext_user_regex

This list may be incomplete or out-of-date. See your squid.conf.documented file for details. ACL types marked with {R} are reply ACLs, see the dedicated FAQ chapter.

Squid caches the results of ACL lookups whenever possible, thus slow ACLs will not always need to go to the external data-source.

Knowing the behaviour of an ACL type is relevant because not all ACL matching directives support all kinds of ACLs. Some check-points will not suspend the request: they allow (or deny) immediately. If a SLOW acl has to be checked, and the results of the check are not cached, the corresponding ACL result will be as if it didn't match. In other words, such ACL types are in general not reliable in all access check clauses.

The following are SLOW access clauses:

• http_access
• adapted_http_access (2.x call this http_access2)
• http_reply_access
• url_rewrite_access
• storeurl_access
• location_rewrite_access
• always_direct
• never_direct
• cache

These are instead FAST access clauses:

• icp_access
• htcp_access
• htcp_clr_access
• miss_access
• ident_lookup_access
• reply_body_max_size {R}
• authenticate_ip_shortcircuit_access
• log_access
• header_access
• delay_access
• snmp_access
• cache_peer_access
• ssl_bump
• sslproxy_cert_error
• follow_x_forwarded_for

Thus the safest course of action is to only use fast ACLs in fast access clauses, and any kind of ACL in slow access clauses.

Удалить много conntrack соединений оптом

First, use conntrack to correctly identify your entries:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123

This should display any connections that came from the internal IP of 172.16.1.45 destined to 123.123.123.123

Once you have confirmed the connections shown are the ones you with to delete/reset, paste the following after the command from above:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123 | sed 's/=/ /g' | awk '{print("conntrack -D -s "$6" -d "$8" -p "$1" --sport="$10" --dport="$12)}'

This will print a list of the commands that would run to delete the connections. Replace "print" with "system" to execute the deletions:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123 | sed 's/=/ /g' | awk '{system("conntrack -D -s "$6" -d "$8" -p "$1" --sport="$10" --dport="$12)}'

Finally, re-run the list command to see that all the entries have been removed:

    conntrack -L -s 172.16.1.45 -d 123.123.123.123

And you're done!

http://www.muchtall.com/2008/11/12/5/