Thanks for your replies! I agree that this should be solved in the web-app,
but in the meantime I'll try reyks workaround.
Regards, Mikael
2008/9/17 Michiel van Baak [EMAIL PROTECTED]:
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=getsearch=0x71C946BD
Why is it drug addicts and computer aficionados are both called users?
