|
Good morning, I hope you had a pleasant weekend.
I put ===== where I have my replies, to make it easier to find.
> > 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?
=====
https? What's that have to do with this? I was able to "fix" that
problem two weeks ago by using fwmark instead of directly forwarding
it. The emphasis and point of this mail was about a completely
different issue.
>
> > 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?
=====
I don't know, I don't have access to the router. I supplied you with
tcpdump output with arp, if you need for port 80 or 443, I can do that
as well.
>
> > 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?
=====
I have no idea, was hoping you could tell me that ;)
>
> > 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.
=====
Neither do I, that's why I mailed the list! I honestly think I'm
missing some mini, little, teeny, tiny step SOMEWHERE. For instance, if
I do the "arp" method where I "echo 1" into the proc files on the real
server and set lo there to be the vip with netmask of 255.255.255.255,
no matter what I do I cannot ping, lynx, curl, or get to that machine
from any other machine, except the real server itself -- obviously
something is wrong, and it's answering it's own arps. Hrrrm.
>
> > 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?
=====
Again, what does that have to with this? In a regular nat setup, it
works fine. With the DR method I used (steps are, again, above),
nothing worked outside the real-server's network, no ping, no http, no
https, etc etc. So NAT works nearly without flaw, but I don't want to
use it in production because of thousands of collisions I get on the
nics (viewed using ifconfig) when under high load.
>
> > 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.
=====
I've temporarily put work on this aside, but I still hope someone out
here will see what I'm doing wrong and steer me in the right direction!
Good day,
Jano
|
