[Tfug] Fw: Re: Topology questions je9eqyma

Bexley Hall bexley401 at yahoo.com
Mon Oct 8 03:43:20 MST 2012


Hi Bender,

[sorry, I won't clean up the quoting -- listserver forced a
resend so I'm simply FORWARDing it!  :>

--- On Sun, 10/7/12, Bender <bender at bendertherobot.com> wrote:
> 
> > why don't you draw a picture?
> 
> I assumed the descriptions (included below) were sufficient
> to make clear what was going on.  But, if you insist on a
> drawing, pick up a pencil...
> 
>          
>                                              |-------- WiFi1
>                        exposed               |-------- Routed
> WLAN ---- Firewall ------------------ Router |-------- Private
>                                              |-------- WiFi2/Test
> 
> 
> (Here's where your pencil comes into play!  :> )
> 
> Each of the WiFi internets are essentially just 2 device
> internets:
> an access point and a spare RJ45.  Via these 2 devices
> (in two
> *places*!), "foreign" devices can connect to the network in
> much
> the same way things can try to get through the Firewall
> from
> The Outside World.  Having the router in place ensures
> I can
> watch that traffic -- and shut it down, if need be (the AP's
> are
> PoE so if someone starts abusing one, I just pull its plug)
> 
> The Routed internet is for the typical devices *you* would
> connect
> together -- and to the outside world.  Workstations,
> printers,
> FAX, etc.
> 
> The Private internet is for (atypical!) devices that you
> wouldn't
> want accessible from the outside world.  Network
> speakers, network
> displays, HVAC controller, irrigation controller, hot water
> heater,
> water softener/main, user interface/control panels,
> surveillance
> cameras, beacons, etc.  It would be a royal pain if
> someone was
> able to adjust the heat inside the house from a car parked
> down the
> road -- or, a deliberate and prolonged attack over the
> WLAN!
> 
> Onto this fabric, I have to add heavyweight services (FTP,
> HTTP,
> RDBMS, etc.), lightweight services (DNS, TFTP, NTP, etc.)
> and
> my "custom" services (music server, video server, etc.).
> 
> The router provides all the lightweight services to *all* of
> the
> internets (logical since they are inexpensive and it has
> free
> access to each of them -- including "exposed"!).
> 
> On first blush, the heavyweight services belong on the
> routed
> network as they are most commonly accessed from
> workstations.
> E.g., I keep the datasheets for the various electronic
> components
> that I use stored on the web server so I can call them up
> without
> having to thumb through dead trees.  Similarly, man
> pages for the
> various OS's that I use (so I don't have to have a machine
> of that
> particular flavor online just to consult it!)
> 
> Likewise, ISO's for various "Live CD's" or even purchased
> software
> get archived on the FTP server (easier to thumb through FTP
> listings
> than it is to dig through boxes of CD's!)  Imagine
> pulling 600MB
> *through* a router deliberately sized for low usage?? 
> (so running
> it 24/7/365 doesn't "cost an arm and a leg")
> 
> However, the "Private" internet also needs access to much of
> this
> same information.  No, not datasheets but, perhaps, the
> song list
> for a particular CD.  Or, to browse highlights from a
> movie (to
> decide if it is worth watching).  Or, to view the
> current 
> configuration of the irrigation system, etc.
> 
> [I.e., a "display" cares not what is presented on it --
> it's
> "just video".  You can view the TV program listing on
> your
> TV.  Why not the list of tracks on a CD?]
> 
> Given that many of the devices on the Private internet are
> designed
> to be "of limited capability" (user interfaces represent a
> good 
> portion of an embedded products complexity), this suggests
> biasing
> the availability of those services to the Private internet
> directly
> to give them a "leg up" on performance (afterall, the
> workstations
> on the Routed internet tend to be multigigahertz
> machines!).
> 
> How long would you want to wait for the program listing for
> the TV 
> to appear on the screen?
> 
> If, instead, you give each internet direct access to the
> services
> you aim for the best of both worlds.  And, you lock
> that traffic
> on that internet -- none of the other internets should
> expect to 
> see it (or figure out how to handle it!)
> 
> Repeat the exercise with the "exposed" internet.  I
> might want
> to serve up some of my personal publications to the outside
> world.  But, I surely don't want folks downloading
> items that
> I *don't* plan for public consumption:  "2011 Taxes,
> federal.pdf"...
> 
> Hopefully, gives you a better feel for what sorts of traffic
> have to
> be accommodated.
> 
> [Also, keep in mind, this is a *home* not a business! 
> We don't want
> big pieces of equipment, lots of noisey fans, high(er)
> electric
> bills, etc.]
> 
> --don
> 
>  
> > > I've got a multihomed device that serves up
> lightweight
> > > services (NTP, DNS, DHCP, etc.) and acts as a
> router
> > > between the "exposed" internet (the interface that
> talks
> > > to the firewall) and the "internal" internets.
> > > 
> > > E.g., there is a "routed" internet, a "private"
> internet
> > > and dedicated connections to wireless access
> points
> > > (so traffic from the AP's can't "get anywhere"
> without
> > > the router explicitly handling it).
> > > 
> > > For the most part, there is little traffic
> *between*
> > > the internets.  The router moves data between
> the
> > > "exposed" interface and the "routed" one; *some*
> > > (usually a single wireless client) traffic between
> AP's
> > > and exposed/routed/etc.; and mainly "control"
> information
> > > between the "routed" and "private" networks.
> > > 
> > > [Keep in mind, it is also providing those
> lightweight
> > > services]
> > > 
> > > The router has to be on 24/7 so I've tried to keep
> it
> > > as lean as possible.  I.e., the firewall can be
> powered down
> > > (assuming nothing needs to "get outside") as well
> as other
> > > internal hosts -- but the router has to provide
> its services
> > > 24/7/365 (i.e., if something wants to talk to the
> outside,
> > > *it* has to ensure the firewall is powered up!)
> > > 
> > > I've moved heavier-weight (HTTPd, FTPd, etc.)
> services
> > > to a different host that can handle the heavier
> load -- and,
> > > that can afford to be powered down when those
> services
> > > are not required.
> > > 
> > > I have an obvious choice as to how to connect this
> host to
> > > the network:
> > > - I can *pick* one of the internets and just stick
> it there
> > >  and add rules to the router to ensure
> <whatever> *should*
> > >  be able to access it, can.  This forces any
> traffic from/to
> > >  any of the "other" internets to pass through the
> router.
> > > - I can add additional interfaces to this
> "heavyweight" host
> > >  and let it have a real presence on the internets
> that need
> > >  to access its services.  This takes the router
> out of the
> > >  picture for all of that traffic.  (remember,
> router can be
> > >  regarded as a thin pipe that potentially reduces
> bandwidth)
> > > 
> > > Expounding on the second of these options, there
> is a question
> > > as to how I make those services available to the
> "outside world":
> > > - Have the router filter traffic from the outside
> world to decide
> > >  what gets through to the server (in addition to
> actually having
> > >  to forward those packets).  This allows the
> server to sit on
> > >  any/multiple internets and lets the router's
> configuration
> > >  determine how packets get to/from it.
> > > - Have the server *also* sit on the "exposed"
> internet and service
> > >  requests GATED BY THE FIREWALL without the
> router's involvement.
> > > 
> > > This last option also could be used for a "single
> interface"
> > > server -- put that interface on the exposed
> internet and have
> > > the router pass all internal traffic destined for
> one of those
> > > services *onto* that internet (i.e., the router is
> involved in
> > > *all* internal accesses regardless of the internet
> from which
> > > they arose).
> 
>



More information about the tfug mailing list