On Tue, Dec 26, 2017 at 12:23:41AM +0900, Mark Fletcher wrote:
I run a home network with what might be slightly unusual topology. At
the centre of it is a Buffalo Airstation which services a bunch of
iDevices, a couple of Androids, a Windoze laptop,
It's bad enough having to read a really long post without having to also
see juvenile things like "windoze" scattered throughout...
and a mini ITX machine
running Stretch, and its wired ethernet ports also service a NAS and my
main Debian Stretch desktop. Until very recently I ran a cable from the
AirStation's WAN port to another mini ITX PC, this one running LFS,
which acts as my firewall (I don't trust the firewall in the
AirStation). The firewall runs a DHCP server to supply the AirStation
with an IP address. The AirStation runs its own DHCP server on its LAN
side, giving out IP addresses in the range 192.168.11.0/24, which is how
all my machines except the firewall get their IP addresses. The firewall
gets its external-facing interface IP via DHCP from my ISP and is static
IP on its internal-facing side.
This is unnecessarily complicated, and will make your life harder than
it needs to be. The best thing would be to not use the airstation as a
router at all, just use it as a switch + wireless access point in a flat
configuration, with the router plugged into the switch. Ignore the "wan"
port on the airstation and turn off any dhcp or other services that it
is providing.
Recently I threw together LFS on a Raspberry PI and decided to use it as
a caching DNS server. My plan is to run dnscache on it. The list may
remember a thread I started a few months ago about the best way to solve
DNS worries I had back then; I got some good advice at that time and
this is me implementing said advice -- at long last I have some time off
work and time to work on this.
Honestly, this will probably end up being slower overall than not having
a caching DNS server, because the PI is slow and you're adding latency
to all requests without significantly speeding up cached requests.
If the PI is going to be useful as a caching DNS server for my network, it
needs to not be in danger of having its IP address changed -- especially
since it is going to need to be sitting outside the AirStation's LAN
(since the AirStation insists it is the DNS server for its LAN, but
actually merely forwards on all DNS queries to whatever DNS server it
has been given in its WAN setup).
A DNS server will always have a range of IPs that it is configured to
use, if you assign an IP statically outside that range there is no
danger of "having its IP changed". You don't need to put a device on a
new subnet to achieve that goal.
So I bought myself an ethernet switch -- a Netgear ProSAFE Gigabit
Switch to be precise -- and have configured the PI to have a static IP
on the same subnet as the firewall and the IP address given to the
AirStation by the firewall. To be concrete, the internal-facing firewall
interface is 192.168.1.1 (static, works), the DHCP server I set up on
the firewall gives out 192.168.1.2 to the AirStation (works), and I have
configured the PI to use 192.168.1.3 (static, partly works). So inside
AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
192.168.1.1, .2 and .3 -- note the third octet difference for internal
and external. All 3 of AirStation WAN port, PI and firewall
internal-facing interface are plugged into the switch. I ran the switch
for a couple of days with just the firewall and the AirStation plugged
in (ie the switch was strictly unnecessary at that stage) and the
network suffered no apparent ill effects. So the switch appears to be in
good working order.
This will not work the way you think it will. Devices on the airstation
will have packets go directly to 192.168.1.3 (because the airstation
knows how to get to anything on 192.168.1.0/24) (you never actually
specified the netmask for 192.168.1., hopefully that's correct). The
packets returning from 192.168.1.3 will go to 192.168.1.1 because
192.168.1.3 does not know how to get to 192.168.11.0/24 and uses the
default route instead. The firewall at 192.168.1.1 will drop those
packets because they don't form a valid session. To make this work,
192.168.1.3 (and any other device on 192.168.1.0/24) would need a static
route to 192.168.11.0/24 via 192.168.1.2. This will be a pain to
maintain, and offers no advantage over simply having a flat network and
abandoning the routing functionality of the airstation.
Mike Stone
