|
Thanks Graeme,
I think you are right, I will try and go back to basics: so maybe I
can ask you this simple question then. What is the best way to go,
when I can't have the client finding out the real server IP.
If what everyone is saying, then if I have a network sniffer on my
machine as the client, and I point my browser to the VIP, which sends
my request off to the Real Server, that server sends everything
directly to me. Will the real server's IP show up on the sniffer?
I can't have the sniffer know where the real server is (geographically).
That's what I need to happen, and that's why i'm so confused, because
all of the howtos, tell you the real server sends everything right to
the client..
Thanks William
On Jan 6, 2008 4:01 PM, Graeme Fowler <graeme@xxxxxxxxxxx> wrote:
> On Sun, 2008-01-06 at 10:30 -0500, William Ottley wrote:
> > Thanks for your time Graeme,
>
> No problem.
>
> > if i'm correct, then what you're saying is IP spoofing?
>
> No, it isn't. But it could be seen that way in certain contexts. It's
> spoofing if and only if the source IP address has no right to be inbound
> on a router (or other device) interface. If you control the LAN, or you
> have an ISP which will agree to let these packets pass, it isn't
> spoofing.
> You may however have issues with URPF (unicast reverse path forwarding)
> verification on A Certain Vendor's kit; it's not too hard to turn off on
> a given LAN but has wider consequences that should be understood. It
> should always be applied with appropriate ACLs anyway, so turning it off
> with the right router ACL in place simply means more load on the ACL
> (URPF verification often runs in hardware).
>
> > I thought I read that since the real server is sending the VIP
> > address, this is considered IP spoofing, and some ISP's block that
> > traffic? or is it something completely different?
>
> If you're doing DR, then you probably have everything in the same (or
> adjacent) netblocks, or netblocks from the same provider, so it isn't
> such a problem. If you choose to use TUN, then you need to make sure
> that either you control all relevant client-facing networks which might
> egress the packets, or have a decent ISP who will allow you to do it.
> There are more complex issues at play here anyway, since TUN only works
> generally speaking if all the peers of the egress ISP will accept the
> VIP as a source - if it's from a different AS, you have problems before
> you start.
>
> Like I said - strip back to something simple. Once you know you can make
> that work, scale up and out.
>
>
> Graeme
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
--
---------------
Morpheus: After this, there is no turning back. You take the blue pill
- the story ends, you wake up in your bed and believe whatever you
want to believe. You take the red pill - you stay in Wonderland and I
show you how deep the rabbit-hole goes.
|
