|
I think this give some places to start. Thank You very much.
The whole reason for having to do this is because some of the developers
needs to be able to use cvs via ssh FROM the real servers. The reasons
for needing to go out from the real servers reall has nothing to do with
the services they're providing. It's just that peoepl need to be able to
hit the internet from these machines for work.
So, I could easily solves this by either putting real ip's on all the
machines, which is a waste of ip and a bit more insecure or I could just
settle for using NAT, which I guess wouldn't be all that bad, but I hoping
to show off the cool DR in a production environment.
Thanks
-jeremy
On Fri, 22 Sep 2000, Joseph Mack wrote:
> On Fri, 22 Sep 2000, Jeremy Hansen wrote:
>
> >
> > Yes, I am using LVS-DR and actually that part of it is working fine. DR
> > is working, but the problem is that I cannot initiate outgoing connections
> > from my real servers.
>
> sorry about this. I didn't understand the problem (I couldn't understand
> why you were having the problem I thought you were having, I was sure you
> understood all of that stuff).
>
> * You want to INITIATE outgoing connections *
>
> never mind (groan).
>
> Specifically in your example below you want to initiate connections for
> https from a real-server on a LVS which is forwarding all services on the
> VIP (if that's what your fwmark is doing). I presume these connections
> from the real-servers have nothing to do with the LVS, you just want the
> real-servers to do double duty?
>
> Well that's a new one. Just for my interest why do you want to do this?
>
> I'm going to have to think about this. In the mean time my half baked
> idea..
>
> ipvs uses ipchains/masq behind the scenes to do its work. Thus any
> packets travelling on the 10.x.x.x network with ports under the control
> of LVS will not obey standard tcpip rules. You should avoid messing with
> these packets.
>
> If you set up a VS-DR LVS to forward only http with (simple service to
> check from the client), then the only packets under the control of the LVS
> have dest_port=http. The default gw for the real-server is the router.
>
> Now you can NAT telnet from the real-server by running on the director
> something like
>
> $ echo "masquerading tcp real-server:telnet:tcp to outside world"
> $ ipchains -A forward -p tcp -j MASQ -s real-server telnet -d 0.0.0.0/0
>
> where real-server resolves to a RIP.
>
> for this to work you have to make the director the default gw, which
> will kill VS-DR. To restore functioning of the VS-DR, you have
> to make the VS-DR LVS work with the director as default gw. To do this
> you can use one of Julian's 2 martian modifications. The simplest of which
> is to get the director to accept packets on the VIP by transparent proxy
> (I also haven't tried this method, I tried Julian's 2nd method which
> involves patching the kernel, I know that works).
>
> So: set up a VS-DR LVS accepting packets on the VIP by transparent proxy
> and forward only http. When that works, then try NAT'ing telnet from the
> real-server.
>
> Am we talking about the ssame thing yet?
>
> Joe
>
> --
> Joseph Mack mack@xxxxxxxxxxx
>
>
eholes.org * jeremy@xxxxxxxxxx
-----------------------------------------
eholes have feelings too...
|
