If I were to expand on this, can I just run this past you experts so that I am
going down the right road.
The end rule should be a round-robin style rule, which is populated by "l4ip"
process, and it would be nice if this rule could be left to be maintained by
l4ip, and not "written" by stunnel (sample/proxy.c) code. (Since I don't want to
have to deal with knowing what members are UP in stunnel patch)
To be compatible, it can't really use localhost, and in addition to this, to
function with IPFilter it has to pass from one interface to another. (Still the
case right?).
Ports here are just examples.. should be on for any TCP+SSL protocol.
So, perhaps something like:
1] ext0:80 RDR -> int0:80
2] stunnel listens on int0:80, with the extra patch to fudge src IP, connects to
3] ext0:81 RDR+rr -> int0 -> one-cluster-host:81
1] is static rule.
3] is populated by l4ip to add/remove members with RDR + round-robin.
External SSL connection comes in to port 80, is redirected to stunnel. stunnel
handles the SSL->plain conversion, and connects to ext:81 with the proxy source
patch added to ensure that the connection appears to come from external IP. It
connects to external interface so that the packet travels through to leave on
the internal interface, to one of the members listed in the RDR+rr rules.
Return packets are sent to external IP.. I assume here, that ipfilter picks up
on this, sends it to ext0 interface where stunnel is, and the rest is standard.
Would that work? It might be desirable to add ipf.conf rules to stop direct
connections to :81, or, alias on another non-routable IP to simulate localhost.
Lund
Carson Gaspar wrote:
--On Wednesday, May 17, 2006 11:44 AM +0900 Jorgen Lundman
<[EMAIL PROTECTED]> wrote:
But to me that still feels very hacky. It would be more desirable if you
could make a competing "black box" solution with IPFilter+SSL, and not
require the SSL overhead on the client servers at all (which is one of
the points of SSL accellerators).
You can. You just need to add support for IP filter to stunnel. See
samples/proxy.c in the source distribution for an example of the NAT API
used to accomplish this.
--
Jorgen Lundman | <[EMAIL PROTECTED]>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
