On 21:39, Wed 17 Sep 08, Reyk Floeter wrote:
> Hi!
>
> On Wed, Sep 17, 2008 at 05:45:23PM +0200, Mikael Jansson wrote:
> > I use relayd with redirects to loadbalance between two webservers
> > one redirect is used for http requests and the other for https.
> > the redirects looks like the following:
> >
> > redirect web_http {
> > listen on $ext_ip1 port http
> > sticky-address
> > forward to <webservers> port http check script "/usr/local/sbin/chksrvs"
> > }
> >
> > redirect web_https {
> > listen on $ext_ip1 port https
> > sticky-address
> > forward to <webservers> port https check script "/usr/local/sbin/chksrvs"
> > }
> >
> > The redirects works fine separately and sticks to the same machine,
> > but when the user navigates from http to https the requests sometimes
> > move over to the other machine. I need the same source-ip to always
> > stay on the same server regardless of which destination port (http or https)
> > is being used. Any suggestions on how to achive this would be greatly
> > appreciated.
> >
>
> it does not work without a patch. the problem is that the pf Source
> Tracking table includes a reference to the rule but your example above
> will load two different rules into pf - one matching http and another
> one matching https.
>
> the trick is to combine both statements into one rule. we don't
> support "port tables" in pf yet (which whould be very helpful in many
> cases) but there is support for a port range. so the "hack" is to
> allow port ranges in the relayd redirection block
>
> redirect web {
> listen on $ext_ip1 port 80:443
> sticky-address
> forward to <webservers> port http check script "/usr/local/sbin/chksrvs"
> }
>
> note that this will match any traffic in the 80 - 443 port range, make
> sure that you add additional pf rules to filter any other ports except
> 80 and 443. but it works with Source Tracking and should allow your
> clients to move between http and https on the same server. another
> limitation is that it only runs checks on one of the ports.
ugh, this looks ugly ;)
Instead of going this route I would say: find the source of why the
visitor should access the same host, and solve that.
We use relayd in front of 6 servers, doing http and https.
It doesn't matter what backend box the user go. Hell, they can even go
to another box on a reload.
This of course means we are storing sessions etc on shared storage (NFS
in our case, and the new sharedance port looks like an alternative for
that)
--
Michiel van Baak
[EMAIL PROTECTED]
http://michiel.vanbaak.eu
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD
"Why is it drug addicts and computer aficionados are both called users?"
