Re: relayd http-https-redirects with sticky-address
On Wed, Sep 17, 2008 at 10:19:11PM +0200, Michiel van Baak wrote:
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.
no, it is not ugly. it is a reasonable solution for a very common
case. you can easilly block other incoming connections with
restrictive pf rules. but please face reality - not everyone is in
control of their backend web servers since it is VERY common that the
loadbalancers (networking group) are handled by a different group than
the backend webservers (servers group). and it is also very common
that you run your fancy nice openbsd box in front of some other
stuff. indeed, it is very common for loadbalancers and firewalls to
fix arbitrary systems attached to the network.
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)
of course this is a better solution if you're in control of the
backend servers. some people also use solutions like a clustered
database backend (eg. mysql), proprietary solutions like zend cache,
...
reyk
--
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?
Re: relayd http-https-redirects with sticky-address
I can relate to that, having load balancers fixing backend services.
If you have the time, you will probably find pound reverse proxy
http://www.apsis.ch/pound/ to be a nice alternative to try out in your lab.
I have pound on openbsd for several years and can recommend it for http
- https redirects, SSL termination and back-end load balancing with
health checks (not to mention the dynamic scaling ) and and weighted
priority between backend nodes.
Check it out
Reyk Floeter wrote:
On Wed, Sep 17, 2008 at 10:19:11PM +0200, Michiel van Baak wrote:
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.
no, it is not ugly. it is a reasonable solution for a very common
case. you can easilly block other incoming connections with
restrictive pf rules. but please face reality - not everyone is in
control of their backend web servers since it is VERY common that the
loadbalancers (networking group) are handled by a different group than
the backend webservers (servers group). and it is also very common
that you run your fancy nice openbsd box in front of some other
stuff. indeed, it is very common for loadbalancers and firewalls to
fix arbitrary systems attached to the network.
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)
of course this is a better solution if you're in control of the
backend servers. some people also use solutions like a clustered
database backend (eg. mysql), proprietary solutions like zend cache,
...
reyk
--
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?
Re: relayd http-https-redirects with sticky-address
On 2008-09-29, Leon Dippenaar [EMAIL PROTECTED] wrote: I can relate to that, having load balancers fixing backend services. If you have the time, you will probably find pound reverse proxy http://www.apsis.ch/pound/ to be a nice alternative to try out in your lab. I have pound on openbsd for several years and can recommend it for http - https redirects, SSL termination and back-end load balancing with health checks (not to mention the dynamic scaling ) and and weighted priority between backend nodes. relayd with PF handling the redirection is lower overhead for simple load-balancing (no kernel/userland/kernel path for the packets), and the SSL termination can be a lot smarter (e.g. presenting the backend web server with the client's original IP address via transparent proxying) thanks to the integration with the rest of the OS..
Re: relayd http-https-redirects with sticky-address
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?
Re: relayd http-https-redirects with sticky-address
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.
reyk
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.122
diff -u -p -I$OpenBSD.*$ -r1.122 parse.y
--- parse.y 22 Jul 2008 23:17:37 - 1.122
+++ parse.y 17 Sep 2008 19:21:53 -
@@ -30,6 +30,7 @@
#include sys/queue.h
#include net/if.h
+#include net/pfvar.h
#include netinet/in.h
#include arpa/inet.h
#include arpa/nameser.h
@@ -100,11 +101,12 @@ static in_port_t tableport = 0;
struct address *host_v4(const char *);
struct address *host_v6(const char *);
int host_dns(const char *, struct addresslist *,
- int, in_port_t, const char *);
+ int, struct portrange *, const char *);
int host(const char *, struct addresslist *,
- int, in_port_t, const char *);
+ int, struct portrange *, const char *);
struct table *table_inherit(struct table *);
+int getservice(char *);
typedef struct {
union {
@@ -113,6 +115,7 @@ typedef struct {
struct host *host;
struct timeval tv;
struct table*table;
+ struct portrange port;
struct {
enum digest_type type;
char*digest;
@@ -134,8 +137,9 @@ typedef struct {
%token v.string STRING
%token v.number NUMBER
%type v.string interface hostname table
-%type v.number port http_type loglevel sslcache optssl mark parent
+%type v.number http_type loglevel sslcache optssl mark parent
%type v.number proto_type dstmode retry log flag direction forwardmode
+%type v.portport
%type v.hosthost
%type v.tv timeout
%type v.digest digest
@@ -231,15 +235,29 @@ eflags: STYLE STRING
;
port : PORT STRING {
- struct servent *servent;
+ char*a, *b;
+ int p[2];
- servent = getservbyname($2, tcp);
- if (servent == NULL) {
- yyerror(port %s is invalid, $2);
+ p[0] = p[1] = 0;
+
+ a = $2;
+ b = strchr($2, ':');
+ if (b == NULL)
+ $$.op = PF_OP_EQ;
+ else {
+ *b++ = '\0';
+ if ((p[1] = getservice(b)) == -1) {
+ free($2);
+ YYERROR;
+ }
+ $$.op = PF_OP_RRG;
+ }
+ if ((p[0] = getservice(a)) == -1) {
free($2);
YYERROR;
}
- $$ = servent-s_port;
+ $$.val[0] = p[0];
+
Re: relayd http-https-redirects with sticky-address
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?
