Re: [squid-users] forwarding port changed based on url

On 09/09/10 21:39, foobar devnull wrote:
> squid-users_at_squid-cache.org, Amos Jeffries<squid3_at_treenet.co.nz>
>
> On Wed, Sep 8, 2010 at 3:50 PM, Amos Jeffries<squid3_at_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