|
howdy again.
On Mon, 13 Nov 2000, Julian Anastasov wrote:
>
> 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?
i need that on the client machine too? i just added those in there just
in case. can't hurt.
> > [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.
interesting. ok.
> > 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.
but pings and what not work fine. everything seems to work fine, except
the nameservice stuff.
> > [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 am in awe of your advanced routing utility prowess. =)
[root@phl /root]# /sbin/ip route get from 192.168.1.21 to 206.245.168.220
206.245.168.220 from 192.168.1.21 via 192.168.1.1 dev eth0
cache mtu 1500 rtt 375ms
looks good.
i've just made an interesting discovery. the discovery is that bind's
nslookup sucks, much like djb (qmail) claims.
[root@phl /root]# nslookup magician.bunzy.net 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]# dnsq a magician.bunzy.net 206.245.168.220
1 magician.bunzy.net:
136 bytes, 1+1+2+2 records, response, authoritative, weird ra, noerror
query: 1 magician.bunzy.net
answer: magician.bunzy.net 300 A 206.245.168.220
authority: bunzy.net 300 NS magician.bunzy.net
authority: bunzy.net 300 NS dns1.hostme.com
additional: magician.bunzy.net 300 A 206.245.168.220
additional: dns1.hostme.com 153536 A 206.245.167.2
[root@phl /root]#
dnsq is a lookup utility from djbdns.
so turns out all that stuff is fine. i'm not quite sure why nslookup
won't work, but i'll continue on from here with the mindset that bind is
garbage. i was actually in the midst of trying out tinydns (also from
djbdns) when i noticed this.
so i'll see where this takes me. many thanks once again, Julian.
-tcl.
|
