Thanks for your information.
The SSLProxy is a homemade stuff. My coworker wrote it. And I don't know how
he implements it. And I don't know the internals of the ldirector mechanisms
either. Hmm, big problem then.
Ideally, ldirector does not need to know SSLProxy.
The request goes like this
Client -> SSLProxy(443)->(80)->Load Balancer(80)->Real Servers (80)
After I run my SSLProxy, response always comes from the fall back server
instead of from any real servers. It looks like I have to look into the
source codes. Any suggestions!
Thanks again
Longhua
-----Original Message-----
From: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mark
Sent: Tuesday, October 11, 2005 11:50 AM
To: 'LinuxVirtualServer.org users mailing list.'
Subject: RE: LVS problem with SSLProxy
Hm...
I'm not sure about choosing option 2 over option 1. As far as I know, the
SSL stuff can be pretty processor heavy...
But anyway... I think what you want to do should be possible (ldirector and
SSLProxy on one machine) - although I haven't done it
myself...
The only problem I could think of is that the box figures out that both
pieces are its own Ips and then somehow uses the local
interface rather than the eth interfaces. If that happens, I am not sure
about whether the ldirector hooks are still able to pick up
and redirect the traffic, or if they rely on it coming in through a real eth
interface... I don't know enough about the internals of
the ldirector mechanisms...
If you really cant get that to work, try it with option 1, maybe that will
work.
The most important thing is to make sure that you have the input and output
ports of each chain element set up properly, I think.
Which SSLProxy are you using?
I use a load balancer to forward HTTPS to a bunch of apache servers, each of
them has their own HTTPS proxy. I just use mod_rewrite
for that. You could use mod_proxy as well, but mod_rewrite gives you better
mapping options with regex-based rules, etc...
MARK
|