|
Hello,
On Sun, 12 Nov 2000, tc lewis wrote:
> hi there. see below.
>
>
> > > what issues exist with doing dns through lvs? i'm pulling my hair out
> > > over this one.
I don't know for such "issues"
> > ICMP error => no listener?
> >
> > Before I fully understand your message (the ARP talks for
> > example) one question:
> >
> > Is the DNS server in the real server(s) started before the VIPs
> > are configured (in the real servers). Look at the logs (/var/log/messages?)
> > whether the DNS server is listening on VIP:53. There can be a problem if
> > you start your network scripts (VIPs, routes, etc) in rc.local while the
> > DNS server was started long before from the rc.d levels. If you
> > use "bind" I assume there is no listener(s) for the VIPs you add after
> > starting the server.
> >
> > For the telnet service there is no problem. It just listens for
> > 0.0.0.0 and when you add new VIP later it just works.
>
> yeah, that stuff is all ok (it actually might not have been on that
> tcpdump--not sure). so i think it all comes back to the priority
> routing thing. cause i can't nslookup from the real server (which is the
> name server) for outside domains. but even with priority routing off
> strange things happen. ok ignore that. check the following out. it
> looks like some odd udp problem, but tcp is ok.
You are not sure if the TCP is ok, yes there is traffic but
may be DNS errors are reported?
There are such messages in my home pc:
Nov 13 07:52:38 u named[180]: listening on [127.0.0.1].53 (lo)
Nov 13 07:52:38 u named[180]: Forwarding source address is [0.0.0.0].1024
Nov 13 07:52:38 u named[181]: Ready to answer queries.
So, my bind is listening only on 127.0.0.1, i.e. there is no
other IP, I'm starting the ppp link later, so there is no listener
for the external ppp IP until I don't restart bind.
I'm not sure you can use transparent proxy to accept traffic
in the real servers. This method works only when the real service is
listening on the VIP or 0.0.0.0. This is not the case with bind.
> director:
> UDP 64.211.224.164:53 lc
> -> 192.168.1.11:53 Route 1 0 2
> TCP 64.211.224.164:53 lc
> -> 192.168.1.11:53 Route 1 0 1
>
> real server:
> [root@phl /root]# /sbin/ipchains -L -n
> Chain input (policy ACCEPT):
> target prot opt source destination ports
> REDIRECT tcp ------ 0.0.0.0/0 64.211.224.164 * ->
> 53 => 53
> REDIRECT udp ------ 0.0.0.0/0 64.211.224.164 * ->
> 53 => 53
> Chain forward (policy ACCEPT):
> Chain output (policy ACCEPT):
>
> (i wasn't using the horms/ipchains method before, but i am now).
Switch back to the old method.
> udp to port 53 (nslookup):
> 12:19:06.223900 eth0 < 208.219.36.76.61214 > 64.211.224.164.domain: 50126+
> PTR? 164.224.211.64.in-addr.arpa. (45)
> 12:19:06.224186 eth0 > 192.168.1.21.domain > 208.219.36.76.61214: 50126
> NXDomain 0/1/0 (116)
> (unsuccessful)
Reply from 192.168.1.21? Don't use transparent proxy!
> -tcl.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
