|
Hello,
On Mon, 27 Nov 2000, John Lukac wrote:
> 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:
This is a different setup, the https service is not tested?
> 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.
May be the problem is in 209.144.204.129? Are the outgoing
packets (to the client) dropped?
> 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)
What mean 0:0:0:0:0:0 and 0:0:0:0:0:1 in this output?
> 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)
Are the SYNs replied from the real server? Who is stopping
the packets? What do you think, where is the problem? I don't understand
from these outputs where is the problem.
> 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
What is the result from your tests with the SSL service?
> 1 into the proc/hidden), but it didn't work at all (this ipchains
> redirect works to some extent, hehehe).
I don't know for a case where the hidden flag does not work.
May be you have another problem.
> Phew. Sorry it's so boring :(
>
> Thank you for any insight you can provide into this, and thanks for the
> help last week.
> Jano
Regards
--
Julian Anastasov <ja@xxxxxx>
|
