|
Hi,
our mail server here went down last week, but it's all fine and working
now. I trust ya'll had a nice thanksgiving break (for those that had
one).
I had the chance to continue trying to test out the DR method, and I
think I'm beginning to understand it a bit more.
As it's been more than a week since I've dealt with this, here's the
uber long refresher. I setup a DR method using ipchains redirect like
this:
some client
|
router/gw 209.144.204.129
|
director 209.144.204.132 on eth0 (the VIP)
netmask 255.255.255.248
10.23.2.2 on eth1
netmask 255.255.255.0
|
real server 10.23.2.101 on eth1
more real servers in 10.23.2.0/24 (e.g. 10.23.2.102)
the default gw goes to 209.144.204.129
All cables connect to the same vlan on the switch (not segmented).
director commands:
ifconfig eth0 209.144.204.132 netmask 255.255.255.248 up
route add -host 209.144.204.132 dev eth0
route add -net 209.144.204.128 netmask 255.255.255.248 dev eth0
route add default gw 209.144.204.129
--similar steps for the device on eth1 to 10.23.2.2
echo 1 > /proc/sys/net/ipv4/ip_forward
ipchains -A input -j ACCEPT -p tcp -m 1 -s 0.0.0.0/0 -d 209.144.204.132
http
ldirectord.conf set to forward fwmark 1 to the internal web servers on
80.
real server commands:
add the 10.23.2.101 ip and routes.
route add -net 209.144.204.128 netmask 255.255.255.248
route add default gw 209.144.204.129
echo 1 > /proc/sys/net/ip_forward
ipchains -A input -j REDIRECT 80 -p tcp -d 209.144.204.132 80
arp -s 209.144.204.129 MAC-address
The setup looks good. When my client is anyone in that 255.255.255.248
netmask (e.g. 209.144.204.130 or .133), I get through to the website NO
problem! However, soon as I step outside the network with the client
(e.g. some ip accross the nation out there), the web client sits there
and doesn't do anything.
The tcpdumps when I connect from outside the netmasked network:
director ("more stuff" is what looked unimportant):
tcpdump -len tcp port 80:
16:35:26.548133 eth0 < 0:2:4b:8f:c3:20 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:26.548196 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:29.540579 eth0 < 0:2:4b:8f:c3:20 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:29.540600 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:35.549625 eth0 < 0:2:4b:8f:c3:20 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:35.549647 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
tcpdump -len arp:
16:34:53.458539 eth0 < 0:d0:b7:65:cf:7c 0:0:0:0:0:1 arp 60: arp who-has
209.144.204.132 tell 209.144.204.130
16:34:53.458560 eth0 > 0:0:0:0:0:0 0:d0:b7:bd:5c:5f arp 42: arp reply
209.144.204.132 (0:d0:b7:bd:5c:5f) is-at 0:d0:b7:bd:5c:5f
(0:d0:b7:65:cf:7c)
16:35:31.543165 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 arp 42: arp who-has
10.23.2.102 tell 10.23.2.2 (0:d0:b7:c7:1d:32)
16:35:31.543300 eth1 < 0:d0:b7:c7:19:26 0:0:0:0:0:1 arp 60: arp reply
10.23.2.102 is-at 0:d0:b7:c7:19:26 (0:d0:b7:c7:1d:32)
on REALSERVER web2 (10.23.2.102 (setup exact same as web1, 10.23.2.101):
tcpdump -len tcp port 80:
16:35:28.783468 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:31.775804 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:37.784717 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
tcpdump -len arp:
16:35:33.778323 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 arp 60: arp who-has
10.23.2.102 tell 10.23.2.2
16:35:33.778350 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:19:26 arp 42: arp reply
10.23.2.102 (0:d0:b7:c7:19:26) is-at 0:d0:b7:c7:19:26 (0:d0:b7:c7:1d:32)
And that's all I'm getting. Anything make any sense? Do I need to
supply more information? I tried the other method for hiding arps (echo
1 into the proc/hidden), but it didn't work at all (this ipchains
redirect works to some extent, hehehe).
Phew. Sorry it's so boring :(
Thank you for any insight you can provide into this, and thanks for the
help last week.
Jano
|
