|
what issues exist with doing dns through lvs? i'm pulling my hair out
over this one.
here's a tcpdump on my real server:
08:37:41.004616 eth0 > 192.168.1.21.1024 > 192.203.230.10.domain: 9513 NS?
. (17)
08:37:42.503820 eth0 B arp who-has 192.168.1.12 tell 192.168.1.2
08:37:42.503842 eth0 > arp reply 192.168.1.12 (0:d0:b7:65:ec:48) is-at
0:d0:b7:65:ec:48 (0:c0:95:e2:a8:b1)
08:37:42.503943 eth0 < 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
PTR? 163.224.211.64.in-addr.arpa. (45)
08:37:42.504012 eth0 > 64.211.224.163 > 208.219.36.76: icmp:
64.211.224.163 udp port domain unreachable [tos 0xc0]
08:37:42.503996 eth1 B arp who-has 192.168.1.12 tell 192.168.1.2
08:37:42.504045 eth1 > arp reply 192.168.1.12 (0:c0:95:e2:85:40) is-at
0:c0:95:e2:85:40 (0:c0:95:e2:a8:b1)
08:37:42.504006 eth2 B arp who-has 192.168.1.12 tell 192.168.1.2
08:37:42.504073 eth2 > arp reply 192.168.1.12 (0:c0:95:e2:85:41) is-at
0:c0:95:e2:85:41 (0:c0:95:e2:a8:b1)
08:37:42.538686 eth0 < 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
PTR? 163.224.211.64.in-addr.arpa. (45)
08:37:42.538704 eth0 > 64.211.224.163 > 208.219.36.76: icmp:
64.211.224.163 udp port domain unreachable [tos 0xc0]
08:37:45.004615 eth0 > 192.168.1.21.1024 > 198.41.0.10.domain: 9513 NS? .
(17)
208.219.36.76 is my CIP, 64.211.224.163 is my VIP, and 192.168.1.21 is my
RIP. the real server sends back through a gateway of 64.211.224.161,
which is all dandy. the exact same config with port 23 (tcp) instead of
53 (tcp and udp) works, but for some reason dns flakes out. does dns do
other weird stuff that wouldn't be problems with services like telnet?
director:
UDP 64.211.224.163:53 wlc
-> 192.168.1.12:53 Route 1 0 0
TCP 64.211.224.163:53 wlc
-> 192.168.1.12:53 Route 1 0 0
08:37:01.359776 eth2 < 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
PTR? 163.224.211.64.in-addr.arpa. (45)
08:37:01.359852 eth1 > arp who-has 192.168.1.12 tell 192.168.1.2
(0:c0:95:e2:a8:b1)
08:37:01.359983 eth2 B arp who-has 192.168.1.12 tell 192.168.1.2
08:37:01.360045 eth1 < arp reply 192.168.1.12 is-at 0:d0:b7:65:ec:48
(0:c0:95:e2:a8:b1)
08:37:01.360060 eth1 > 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
PTR? 163.224.211.64.in-addr.arpa. (45)
08:37:01.360285 eth1 < arp reply 192.168.1.12 is-at 0:c0:95:e2:85:41
(0:c0:95:e2:a8:b1)
08:37:01.360289 eth1 < arp reply 192.168.1.12 is-at 0:c0:95:e2:85:40
(0:c0:95:e2:a8:b1)
08:37:01.394780 eth2 < 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
PTR? 163.224.211.64.in-addr.arpa. (45)
08:37:01.394802 eth1 > 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
PTR? 163.224.211.64.in-addr.arpa. (45)
i'm at a loss here. what am i missing?
also, i was trying to use that priority routing setup, where responses
from the real server go through the 64.211.224.161 gateway, but new
connections made from the real server go through a masq machine at
192.168.1.1, and i was having strange issues with dns there too -- i
couldn't even nslookup query an outside host with that. but if i ditched
the prio routing and just made my normal gateway the 192.168.1.1 masq
machine, the nslookup worked fine. other services seemed fine with
priority routing, like ping and telnet.
the rules i was using:
/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
the above problem was tried both with and without the priority routing
rules set. the above tcpdumps are from when the real server did _not_
have priority routing setup, only the 64.211.224.161 gateway, although it
didn't work with priority routing setup either.
any ideas on what i might be missing?
does this even make sense?
-tcl.
|
