Under unusual circumstances there may be a need to bypass the proxy server.
A streaming device did not work properly when Squid Transparent mode was enabled. There were no errors in the messages log. These messages appear in the squid access log at /var/log/squid/access.log:
1647144914.348 683 192.168.60.218 TCP_MISS_ABORTED/100 0
PUT http://name-changed.s3.amazonaws.com/SID_1234567890/123456/data.ts -
ORIGINAL_DST/52.217.123.123 -
The TCP_MISS_ABORTED/nnn errors normally appear just once in a while (i.e., two or three every month). But now the access.log was lousy with errors. Every streaming event resulted in the above error.
I came across this Transparent Proxy Selective Bypass article on the Squid wiki.
Once Squid gets engaged to serve a request, it can't declare itself out of the game, but has to either service it or fail it.
So Squid ACLs will not solve the issue. The Wiki above suggested iptables.
PREROUTING to CUSTOMPREROUTING.192.168.60.218/32.s3.amazonaws.com.Source 192.168.60.218/32 to two Destinations with multiple IPs - 52.216.0.0/15 and 54.231.0.0/16
iptables -t nat -N BYPASS
iptables -t nat -A CUSTOMPREROUTING -s 192.168.60.218/32 -p tcp -m tcp --dport 80 -j BYPASS
iptables -t nat -A BYPASS -d 52.216.0.0/15 -j ACCEPT
iptables -t nat -A BYPASS -d 54.231.0.0/16 -j ACCEPT
The s3.amazonaws.com domain covers many IP addresses. And Example #2 changes the Destination from two IP ranges to an ASN (Autonomous System Number).
location -> ipset file -> IPset restore -> iptables -> firewall.local
ASN=16509
location list-networks-by-as --format=ipset --family=ipv4 ${ASN} > "/etc/ipset/AS${ASN}.ipset"
ipset restore < "/etc/ipset/AS${ASN}.ipset"
iptables -t nat -N BYPASS
iptables -t nat -A CUSTOMPREROUTING -s 192.168.60.218/32 -p tcp -m tcp --dport 80 -j BYPASS
iptables -t nat -A BYPASS -m set --match-set ${ASN}v? dst -j ACCEPT
Older Revisions • July 9 at 4:16 pm • cfusco