|
Roberto Nibali wrote:
>> Back to the matter at hand - assuming I need to work around the IP
>> spoofing prevention, do I not have another option besides LVS-NAT -
>> I'm thinking of a variation of LVS-DR, where the real servers do not
>> respond directly to the client, but route their answers through the
>> director (set up as the default gateway for the real servers) ?
>
> Yes, you could try the forward shared approach:
>
> http://www.ssi.bg/~ja/#lvsgw
OK, I'm trying that, but I'm seeing something odd - let me describe my
test-setup:
1+4 servers, all on the same physical network = n.n.n.72/73/74/75/76.
Server#1 is director, the others are real servers. My VIP is n.n.n.80.
I've got the forward_shared patch applied on the director:
# cat /proc/sys/net/ipv4/conf/all/forward_shared
1
# cat /proc/sys/net/ipv4/ip_forward
1
# ipvsadm -l -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 217.8.220.80:25 rr
-> 217.8.220.73:25 Route 1 0 0
The default route on the the real server (just server#2 for now) points
to the director at n.n.n.72.
I've got an external client on 88.198.n.n.
I was trying to see what path responses from server#2 would take to get
back to the client, so I did some tracerouting and pinging, and this is
where something odd happened (odd to me anyway).
On the first traceroute from server#2 to my client at 88.198.n.n., I see
the path going through my director, looks good. On a subsequent
traceroute, the director is skipped and instead the path goes straight
to my default gateway. When I tried pinging instead I saw this:
# ping 88.198.7.133
PING 88.198.7.133 (88.198.7.133) 56(84) bytes of data.
>From 217.8.220.72: icmp_seq=1 Redirect Host(New nexthop: 217.8.220.66)
I'll be doing some more googling, but I thought someone might recognise
this right away?
/Per Jessen, Zürich
|
