Re: [squid-users] Bypassing Squid completely for specific domains/IPs

On Wed, Sep 10, 2008 at 02:21:34PM +0200, Mike Raath wrote:
> There's an old discussion in these archives about how squid does a
> DNS lookup on the requested hostname and directs the request to
> the IP returned from DNS, effectively bypassing the destination IP
> supplied by the squid client, and I fully understand and take on
> board the reasons given for this, viz to prevent cache poisioning
> by spoofing domains.
>
> However, there is a very valid reason for not wanting this
> behaviour in some instances, and that's to test releases of web
> applications in a development environment by spoofing the
> production environment with hosts file entries, and in this case
> you wouldn't want to be viewing cached content anyway, so my
> question is this - is there a way of telling squid to just pass
> the request on wholesale to the requested IP without doing any
> DNS, and without caching?
>
> I don't think that always_direct does what I want, as squid still
> does the DNS lookup here. I can't believe that I'm the only one
> with this requirement, so how have others solved it?

Well the best way to not have squid interfere with your requests is
to not send them to squid in the first place. Since you're talking
about trying to use the original IP address looked up by the client,
you must be using squid in a transparent interception configuration.
Is it possible for you to simply not redirect requests to squid if
they're destined for particular IP addresses, i.e. your development
environment?

If you can't bypass squid entirely, then try Amos' suggestion. It
sounds like you want to allow people to test different servers just
by changing their hosts file though, so unless your testing is
structured enough that you can manage which server is being accessed
at a central location, that probably won't work as is.

An extension of the idea would be to configure a few "reverse proxy"
or "accelerator" listening IPs on your proxy, which are mapped to
particular cache_peers using the "myip" ACL type. Then users set
their hosts file to point to the IP address on the proxy which
corresponds to the dev server they want to test.

You could of course just use a dumb TCP relay to achieve the same
thing (e.g. iprelay), rather than using an actual proxy server and
trying to get it to behave like a dumb relay. But this is a squid
mailing list, so that's the hammer we'll use!

Since examples speak louder than words, here's a configuration
which would have the proxy listen on 10.20.10.10, and forward
anything it received there to the web server 10.20.20.10 using the
host header that the client sent.

# Set up an accelerator listening on 10.20.10.10:80, which will
# be used for testing on the server devweb1.
http_port 10.20.10.10:80 vhost

# Create an ACL that matches the IP we just started listening on.
acl test_devweb1 myip 10.20.10.10

# Configure devweb1 peer entry; assign it a name so it's easy to
# reference in cache_peer_access lines.
cache_peer 10.20.20.10 parent 80 0 name=devweb1 no-query no-digest originserver

# Allow access to devweb1, using the ACL we created earlier
# (i.e. if the client connected to 10.20.10.10, then allow)
http_access allow test_devweb1

# Send any requests we received on 10.20.10.10 to devweb1.
cache_peer_access devweb1 allow test_devweb1
# But don't send any other requests to devweb1.
cache_peer_access devweb1 deny all
# Don't cache anything, either.
cache_deny test_devweb1

# I needed this or else squid would try to fetch things from the
# internet rather than going via the cache_peer.
never_direct allow test_devweb1

# You would also want to deny access to any other cache_peers you
# have defined when the request was sent to your magic IP alias;
# otherwise people may be able to bypass other access restrictions
# you may have in place, due to the permissive "accept any request
# aimed at 10.20.10.10" above.
## cache_peer_access upstreamproxy deny test_devweb1
# If you add another web server as above, then make sure to prevent
# them from receiving each other's requests
## cache_peer_access devweb1 deny test_devweb2
## cache_peer_access devweb2 deny test_devweb1

All this is assuming that your clients can access 10.20.20.10
without having those requests intercepted and sent to the proxy.
And of course you'll already have access controls configured so
you'd need to make sure they were applied in the correct order. But
hopefully you get the idea.
Received on Wed Sep 10 2008 - 15:06:16 MDT