|
Hello,
On Sun, 12 Nov 2000, tc lewis wrote:
> bah. the ipchains redirect method won't work here as i can't get named to
> bind to an ip that's not physically there, so i'm trying hidden dummy
> interfaces now. it's doing all sorts of wack shit. this is so
> frustrating. i should get my queries working before trying this with lvs
> tho, so once again let's ignore all the above. and this part has little
> to do with lvs, but i have no clue where else to turn.
>
>
> masquerading machine:
>
> [root@lga /root]# /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
> 64.211.224.162 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
> 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
> 64.211.224.160 0.0.0.0 255.255.255.240 U 0 0 0 eth2
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 64.211.224.161 0.0.0.0 UG 0 0 0 eth2
> [root@lga /root]# /sbin/ipchains -L -n
> Chain input (policy ACCEPT):
> Chain forward (policy DENY):
> target prot opt source destination ports
> MASQ all ------ 192.168.1.0/24 0.0.0.0/0 n/a
> Chain output (policy ACCEPT):
> [root@lga /root]#
>
>
> normal router/gateway to the outside is 64.211.224.161
>
>
> "real server" / client machine / whatever.
>
> [root@phl /root]# /sbin/ipchains -L -n
> Chain input (policy ACCEPT):
> Chain forward (policy ACCEPT):
> Chain output (policy ACCEPT):
> [root@phl /root]# /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.1.21 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 192.168.3.21 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
> 192.168.1.11 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 192.168.2.21 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
> 192.168.1.12 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 64.211.224.160 0.0.0.0 255.255.255.240 U 0 0 0 eth0
> 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
> 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 64.211.224.161 0.0.0.0 UG 0 0 0 eth0
> [root@phl /root]# tail /etc/rc.d/rc.local
> cp -f /etc/issue /etc/issue.net
> echo >> /etc/issue
> fi
>
> # -tcl.
> /sbin/sysctl -p
> /sbin/arp -s 64.211.224.161 00:30:B6:67:00:40
> /sbin/ip rule add prio 100 from 192.168.1.0/24 table 100
> /sbin/ip route add table 100 0/0 via 192.168.1.1 dev eth0
> #
> [root@phl /root]# cat /etc/sysctl.conf
> # Disables packet forwarding
> net.ipv4.ip_forward = 1
> # Enables source route verification
> net.ipv4.conf.all.rp_filter = 1
> # Disables automatic defragmentation (needed for masquerading, LVS)
> net.ipv4.ip_always_defrag = 0
> # Disables the magic-sysrq key
> kernel.sysrq = 1
send_redirects? Or there are 2 eth cards?
> [root@phl /root]# /sbin/ip route show table 100
> default via 192.168.1.1 dev eth0
> [root@phl /root]# /sbin/ip rule show
> 0: from all lookup local
> 100: from 192.168.1.0/24 lookup 100
> 32766: from all lookup main
> 32767: from all lookup 253
> [root@phl /root]#
>
>
> is net.ipv4.ip_always_defrag supposed to be 0 or 1? which/where/huh? i'm
> assuming 0 is correct for basically everywhere in my network.
Any value. Don't touch it after the first masq/LVS entry is
created.
> feel free to ignore all those other devices on this client machine.
>
>
> the priority routing and masq works fine normally:
> [root@phl /root]# ping -n -c 5 206.245.168.220
> PING 206.245.168.220 (206.245.168.220) from 192.168.1.21 : 56(84) bytes of
> data.
> 64 bytes from 206.245.168.220: icmp_seq=0 ttl=244 time=80.577 msec
>
>
> but not for domain queries:
>
> [root@phl /root]# nslookup www.linuxvirtualserver.org
> Server: phl.usa.mybiz
> Address: 0.0.0.0
>
> *** phl.usa.mybiz can't find www.linuxvirtualserver.org: Non-existent
> host/domain
Yes, because the real server phl can't see the world.
> [root@phl /root]#
>
> tcpdump on phl / client / real server:
>
> 15:08:44.650610 lo > 127.0.0.1.1025 > 127.0.0.1.domain: 59219+ A?
> www.linuxvirtualserver.org. (44)
> 15:08:44.650610 lo < 127.0.0.1.1025 > 127.0.0.1.domain: 59219+ A?
> www.linuxvirtualserver.org. (44)
> 15:08:44.651059 eth0 > 192.168.1.21.1024 > 128.8.10.90.domain: 42360 A?
> www.linuxvirtualserver.org. (44)
> 15:08:45.005379 eth0 > 192.168.1.21.1024 > 198.41.0.4.domain: 4432 NS? .
> (17)
No reply, may be the packets are not masqueraded.
>
> tcpdump on the masq machine showed absolutely 0 traffic.
*/send_redirects=0 ?
> not even requesting from a remote nameserver:
>
> [root@phl /root]# nslookup www.linuxvirtualserver.org 206.245.168.220
> *** Can't find server name for address 206.245.168.220: No response from
> server
> *** Default servers are not available
> [root@phl /root]#
Yes, phl exits directly with saddr=192.168.1.21
> tcpdump on phl:
>
> 15:10:53.005436 eth0 > 192.168.1.21.1024 > 193.0.14.129.domain: 4432 NS? .
> (17)
> 15:10:57.824356 eth0 > 192.168.1.21.1025 > 206.245.168.220.domain: 45849+
> PTR? 220.168.245.206.in-addr.arpa. (46)
>
>
> again, no traffic on the masq machine (lga).
>
>
> what could i possibly be missing here? does the ip program not jive with
> udp? i can't see how it would make a difference, but...i'm at a total
> loss here.
Try first to alter send_redirects and then to use such commands
to test the advanced routing rules:
ip route get from SADDR to DADDR
> i offer my soul to whoever has the answer i need here. or maybe just a
> bag of chips or something.
>
> -tcl.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
