Michael D. Schleif wrote:
How about you tell
me what ip tinydns-public is bound to?
==> cat /etc/tinydns-public/env/IP
How about what ip is dnscache bound to?
==> cat /etc/dnscache/env/IP
# cat /etc/tinydns-public/env/IP
64.4.197.65
# cat /etc/dnscache/env/IP
0.0.0.0
I've not seen 0.0.0.0 used w/dnscache, and I can't
find a reference to it in the djbdns docs. It looks
like you are asking two services to listen on
64.4.197.64.
what, pray tell, is wrong with the nestat proof, published twice (2x)
and ignored twice?
I saw it, but I couldn't make sense of how you got
there w/o seeing the contents of your IP files.
What you pasted doesn't make sense w/what your IP files
contain. There wouldn't be a tinydns on 127.0.0.1
according to your IP file. So something is missing
and I'm sorry if I didn't catch it from your earlier
posts.
root@bluetrout:/root
# netstat -anp | grep dns
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 28373/dnscache
udp 0 0 0.0.0.0:53 0.0.0.0:* 28373/dnscache
udp 0 0 64.4.197.65:53 0.0.0.0:* 28326/tinydns
udp 0 0 127.0.0.1:53 0.0.0.0:* 28324/tinydns
Or at least make up something interesting...
are you being cute? did i miss the joke?
No. Yes. I won't joke w/you again.
with some sleight-of-hand, adding the real external_ip (wan1, _not_
tinydns-public ip) and add an ipchains forward rule from dmz to masq'ed
internal dcd interface, then I see the request _get_to_ dnscache and I
see dnscache resolve the name and _send_the_answer_ -- however, nothing
makes it back to the dmz.
You're missing a route.
which one?
You haven't pasted in the entire trail of the dns request
packet as it moves along your network. So it's not likely
I can narrow down which part of your routing/forwarding
is incomplete.
root@czar:~
# ip route
64.4.197.64/26 dev eth0 proto kernel scope link src 64.4.197.69
default via 64.4.197.65 dev eth0
>
root@bluetrout:/var/log
# ip route
64.4.222.158 dev ipsec0 proto kernel scope link src 64.4.222.157
64.4.222.158 dev wan1 proto kernel scope link src 64.4.222.157
64.4.197.64/26 dev eth1 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
192.168.123.0/24 via 64.4.222.158 dev ipsec0
default via 64.4.222.158 dev wan1
Do you forward and masq from the dmz to internal or just forward?
Have you posted all the rules you're using for that?
this could be it:
<http://www.helices.org/tmP/ipchains.bluetrout.txt>
Ok, I'll have to digest that for a bit. I've never seen
so many forward rules in one place, and it's a lot.
imho, we are missing some crucial ipchains link from dcd out eth1 to the
dmz -- but, what can it be?
Please tell me you've added ipchains -l logging to every packet
1) inbound on dmz nic
2) outbound from dmz nic
3) inbound on internal nic
4) outbound on internal nic
5) forwarded by any forward rule
and repost the trail of a dns request from the dmz, judiciously snipping
and trimming if you please.
quite honestly, this is a very busy network and to log each and every
packet through this router is not a good idea ;<
Well, if you can't define the problem, you'll never
have a chance at solving it. Someone made the choice
not to have a test bench setup. That saved them very
little $$ but may cost them a lot of time.
i've avoided going there, unless there is no other way -- which is why i
hoped that somebody had already worked the magic.
If your forward rules were generated by CS's scripts, then
you may get your wish.
perhaps it is a missing masq chain?
until i publish more details, what do you think about what is already
published?
I think it's very easy to make a subtle error in routing,
which in this case arises in the forward/masq rules you
have installed, yes.
on to the other posts..
matt
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
