Joachim Schipper <[EMAIL PROTECTED]> writes:
> Well, I am not sure exactly what you are trying to do, but getting 1.1
> to talk to 1.2 might be somewhat interesting. Nothing too bad, but not
> exactly simple either.
I've gone clear around the bend ... over complicating.
So backing off to the recommended setup. 192,.168.0/24 255.255.255.0
for anything wired to the NETGEAR and 192.168.1/24 255.255.255.0
for the two nics that connect obsd 2nd nic to gentoo 2nd nic.
And no change at NETGEAR. whos address is 192.168.0.20 255.255.255.0
I hope thats what you were saying.
It doesn't really change the diagram,
> It's usually better to divide into subnets. /24 is the standard, and
> plenty big enough for any home LAN. This makes routing tables less
> complicated
God yes.... I was getting way over my head there.
> . . . . (for instance, the NetGear would need a /32 route entry for
> both 1.1 and 1.2, as would 0.4 and 0.19; this would be more elegantly
> solved by reserving 192.168.1.0/24 for the whole net behind 0.4 and
> 192.168.2.0/24 for the whole net behind 0.19; 192.168.0.0/24 is then the
> network that is directly attached to the NetGear).
Ok, I see where thats going ... I think. Let me just make sure I
understand that but in this case we're not going there.
By /32 I guess you mean a netmask of 255.255.255.255?
> Of course, all this presumes that the NetGear allows proper manipulation
> of routing tables, which should be the case but may not be.
It appears to.
But now backed off to the more simplified setup.
Same diagram and even same addresses but different mask. Everybody
has 255.255.255.0 including the (NETGEAR) router right?
(All have prefix 192.168)
INTERNET
| (Dynamic IP)
|
NETGEAR (consumer grade router FVS-318)
reader | 0.20 fwobsd
--------------------------------------------------
| 0.4 | 0.3 | 0.5 | 0.19
| | | |
[ m1 ] [ m2 ] [ m3 ] [ m4 ]
| 1.2 | 1.1
|________________________________________________|
rdmz fwdmz
Things just fall into place with this setup. Just one little glitch
and this is what caused me to go on the earlier binge and that was the
setup of bind.
But before getting to that, what happens in this scheme with the
domain name `local.lan' the numeric domain is now 2 domains right?
192.168.0 and 192.168.1. So can `local.lan' still cover both?
That point has confused me for a while...
Now about setup of bind (not on the obsd) ... I had no examples in DNS
and Bind (4th ed) except like what I posted earlier with 192.168/16
addressing
So I get confused on the zone files with the above (simpler)
addressing scheme in place. I've added a few more names to the
diagram to ease conversation and just them alone below.
| (to netgear) | (to netgear)
reader 0.4 (runs named) fwobsd 0.19 (runs PF but isn't a router)
| |
rdmz 1.2 fwdmz 1.1
|_____ chintzy hub ___________|
The reverse pointer zone file for 192.168.0 seems ok
But not 192.168.1. I'll post them at the end.
nslookup turns up any alpha name correctly but fails on the
two 1.0 subnet IP numbers.
nslookup rdmz
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: rdmz.local.lan
Address: 192.168.1.2
=========================
nslookup 192.168.1.2
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find 2.1.168.192.in-addr.arpa: NXDOMAIN
The reverse zone file for 192.168.1
db.192.168.1
$TTL 1D
@ IN SOA reader.local.lan. reader.reader.local.lan. (
200405190 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
;
; Name servers (The name '@' is implied)
;
IN NS reader
;
; Addresses point to canonical names
;
2 IN PTR rdmz.local.lan.
1 IN PTR fwdmz.local.lan.
Is it appropriate to use `@' at the top? Is origin still local.lan?
Then at the bottom do I need to put canonical IP instead of
1 and 2?
192.168.1.2. IN PTR rdmz.local.lan.
192.168.1.1. IN PTR fwdmz.local.lan.
Doing that doesn't cure the nslookup problem. It causes named to
output logs lines posted a little further on that indicate the info
is being ignored.
Putting `local.lan' where `@' also causes named to log info
indicating the zone file is not loading.
I haven't been able to get db.192.168.1 to load like it should.
That is also what lead me to trying to use 192.168/16 addressing.
Named output:
Mar 4 07:25:45 reader named[11515]: pri/db.192.168.1:18: ignoring
out-of-zone data (192.168.1.2)
Mar 4 07:25:45 reader named[11515]: pri/db.192.168.1:19: ignoring
out-of-zone data (192.168.1.1)
Mar 4 07:25:45 reader named[11515]: zone 1.168.192.in-addr.arpa/IN:
loaded serial 200405190
Its ignoring the 192.168.1/24 entries so I'm not sure what it needs.
