On 09/09/10 21:39, foobar devnull wrote:
squid-users@squid-cache.org, Amos Jeffries<squ...@treenet.co.nz>
On Wed, Sep 8, 2010 at 3:50 PM, Amos Jeffries<squ...@treenet.co.nz> wrote:
On 09/09/10 01:22, foobar devnull wrote:
Hi all,
I tried to look for an answer to this probably simple question via the
"mailing list search" but it seems to be down and google was of little
help.
I have the following setup:
I have a squid server setup as a reverse proxy and serving a vm with
multiple domains/websites. One of these websites offers an ssl
connection on port 443 and a second ssl connection on port 6066 for
the admin interface. both ports point to www.foobar.com
I'd like to be able to do the following with squid
wwwadm.foobar.com:443 --> [squid] --> www.foobar.com:6066
www.foobar.com:443 --> [squid]--> www.foobar.com:443
Can this be done? If so, I'd be grateful if you could point me to the
appropriate documentation or give me a simple example to work from.
The answer is two questions:
can you make a wildcard cert for both those domains?
or,
can you assign each its own IP and certificate?
Squid can be configured as an HTTPS reverse proxy to do it either way. It's
a standard virtual-host setup with ssl added, differing only in the
receiving https_port settings.
http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting
http://wiki.squid-cache.org/ConfigExamples/Reverse/MultipleWebservers
Amos
Hi Amos,
I read the documentation you sent me and you had a very good point
regarding the need for a wildcard certificate but I am still looking
for a solution to my question which is basicaly...
can squid reformat the url and port to match the target vm?
That is a very different proposition to what you asked initially.
Doing URL re-writing in a reverse-proxy is almost completely pointless
and quite dangerous.
A reverse-proxy never sees the full URL, it has to lookup all sorts of
details and generate a fake one in order to re-write it, then it has to
erase the domain and port info from the new URL again before passing it
to the master server. In a properly configured reverse proxy the master
server is hard coded with a cache_peer entry regardless of what the URL
says about host/port.
Altering the URL in-transit merely fools the master server into
thinking it can advertise the "internal" host/port names to its public
clients via uncontrolled things like absolute links in the pages (or
worse; Refresh and Location HTTP headers on *real* 30x redirects).
If you don't have a cache_peer entry for the master server then you have
a badly configured interceptor proxy. Which is another nightmare altogether.
Yes it can be done. In three years I've seen exactly one network which
needed to, and I have yet to meet anyone who likes the experience.
The request is made to
wwwadm.foobar.com:443
and passed through the reverse proxy to the vm listening on
www.foobar.com:6066
both ports use ssl of course.
Any help is appreciated. I can't seem to find any information on the
forwarding (and changing) of ports.
Middleware like Squid is forbidden from doing so. Squid can, if you
absolutely must re-write the URL.
I pointed you at the accelerator stuff, because this line here:
cache_peer www.foobar.com.ip 6606 0 ssl
... passes traffic to its destination without altering the request
in-transit. The master server then knows how to generate the public URLs
like https://wwwadm.foobar.com/foo to be sent back to the public
clients. Instead of telling them to bypass the proxy for future requests
straight to https://www.fobar.com:6066/foo
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.8
Beta testers wanted for 3.2.0.2
