[TriLUG] newbie needs help with IP setup, part 2: static IP?

[Magnus]

Tom Roche wrote:

(are you the same Tom Roche from IBM, btw?)

> i.e. in whose rather cold basement the hardware is currently gathered
> together, and via whose TWC Surfboard the hardware is currently
> connected (via my ancient, dumb minihub) to the internet

As mentioned before, the very first thing you should be doing at this
point is installing a router between the TWC Surfboard and the minihub.
 Not only is this a huge security issue, but from a network architecture
standpoint you need to establish a private network that can access the
Internet (but not the other way around).

> * The POS requires static addresses (unless someone's willing to
>    diddle the config files everytime a DHCP lease changes). I suspect
>    we could enhance the code to communicate by name, but that is not
>    supported by the current release (and would introduce a DNS
>    dependency, no?).

There is a happy medium, which takes slightly more work, but has a nice
payoff in terms of long-term management.

Configure your POS terminals as DHCP clients.

Establish a dhcpd daemon on your server node.  This will require
*disabling* dhcp on the router that you still need to install. :)  You
can set up dhcp lease reservations in your /etc/dhcp/dhcpd.conf file.

Example, from an old Sun workstation that is no longer on my network
(sanitized a wee bit):

#begin example
host bluegill {
        hardware ethernet 08:00:20:12:34:56;
        ddns-hostname bluegill;
        fixed-address 192.168.1.2;
}
#end example

So if host "bluegill" asks the dhcp server for a lease, it will *always*
get 192.168.1.2.

The payoff of this is that if you need to change your network
infrastructure around, you don't need to change anything on the POS
terminals.  Just change it on the dhcp server and the next time the dhcp
client tries to renew its lease, it will pick up the changes.  Great way
to add new nameservers or what have you.

Going this route you also would need to set up dynamic dns on your
server (also not too hard).

Relevant lines from dhcpd.conf:

#begin
ddns-update-style interim;
key DHCP_UPDATER_KEY {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret [sanitized];
};

zone EXAMPLE.COM. {
  primary 127.0.0.1;
  key DHCP_UPDATER_KEY;
}

zone 1.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key DHCP_UPDATER_KEY;
}

option domain-name "example.com";
option domain-name-servers 192.168.1.1;
#end

This will update a DNS server running on the same host as dhcpd when new
leases are added. It will tell all dhcp clients that the domain name is
"example.com" and use the name server "192.168.1.1".

You'll also want to define a subnet and a pool:
#begin
subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers 192.168.1.254;
        option subnet-mask 255.255.255.0;
        pool {

                max-lease-time 28800;
                range dynamic-bootp 192.168.1.100 192.168.1.199;
                deny unknown-clients;
        }
}
#end

Note that the "deny unknown-clients;" line will prevent a machine from
getting a lease if it is not pre-registered in dhcpd.conf.  It's optional.

A registration can be something simple like this, without a reserved IP
address or anything:

#begin
host xbox {
        hardware ethernet 00:0d:3a:3d:76:b7;
        ddns-hostname xbox;
}
#end

You also need to edit your BIND configuration file to include stuff like
this:

#begin
key DHCP_UPDATER_KEY {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret [sanitized];
};

zone "example.com" IN {
        type master;
        file "/etc/bind/example.com.zone";
        allow-update { key DHCP_UPDATER_KEY; };
};

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "/etc/bind/1.168.192.rev";
        allow-update { key DHCP_UPDATER_KEY; };
};
#end

That will tell BIND to allow dhcpd to send it dynamic updates as new
leases are handed out.

> * It would be very convenient to be able to access each box remotely
>    while we're getting this setup. The POS' lead developers are in
>    Minneapolis and Portland, and a fair amount of customization is
>    usually required--co-ops have different membership structures/
>    policies, states have different tax codes (there are no NC users
>    currently), etc.

When you get your router configured, pass port 22/tcp traffic to your
server (ssh).  Once someone ssh's into that, they are effectively on
your network and can ssh from there to other hosts.

Other protocols can be tunneled over ssh, such as vnc, to effectively
permit a full GUI experience if necessary.

> * Security is definitely more important once deployed. I believe a
>    private intranet (on a cabled LAN) like you describe would be more
>    secure (no?), so I'd like to learn how to set one up. (Feel free to
>    recommend some doc, and I'll RTFM.)

For now, and I can't say this enough, get a router in there.  Hopefully
some of the config samples I provided above will help get your private
network up to speed quickly.

> 2 Enable toggling between private and public networking on demand.
>    Normal mode will be for the co-op to run the POS privately/securely
>    (no external access). But for development, or if we need the remote
>    folks to get hands-on, we could enable external access (by changing
>    POS config files, router config, etc).

No toggling should be needed.  Start private, then open a hole in the
firewall to permit ssh and nothing more.  VPN is another option but
takes a bit more work to get set up & troubleshoot.