As I mentioned in the last entry, we
have an internal subnet for laptops and other generic user machines.
For various reasons, we require machines on this subnet to be registered
so that we can identify who is (theoretically) responsible for them.
One of the ways that people can do this is with a 'plug in and go'
registration portal; you plug in, try to go somewhere, and you wind
up on a simple registration web page instead.
Behind the scenes, it works like this:
- our DHCP server gives unregistered machines IP addresses from a
special subnet. Our internal firewall doesn't allow these IP
addresses access to the outside world.
- as part of the DHCP information, the unregistered machines are
pointed at a special DNS server that is essentially a fake DNS
server. The DNS server simply has a zone file for
., the root
zone, with only two entries; one entry for our registration
portal's public name that points to one
internal IP, and a wildcard ('
*') A record that claims everything
else has another internal IP address.
(In the terms of the last entry, these IP addresses are
Inside-2 and Inside-1 respectively.)
- the two IP addresses that the DNS server tells people about
run some web servers,
including the registration CGI.
- the registration CGI gets and validates the user's credentials,
picks the Ethernet address of their machine out of the web server's
ARP cache, and pokes the DHCP server to get the new machine
registered (using a method beyond the scope of this entry).
(In practice, not having to ask users for their machine's
Ethernet address is a big win for all parties.)
- once registered, users have to renew their DHCP lease (which
will cause their machine to get an IP address that can talk to
the network, along with a gateway and our proper DNS servers)
and flush any cached DNS information they picked up from our
fake DNS server. We tell users that the easiest way to do
this is to reboot their machine.
In terms of servers, the special fake DNS server and all of the web
stuff run on one machine, while the DHCP stuff runs on another (and the
firewall is a third machine). This is mostly a historical accident, in
that we already had the DHCP server running in production before we
started building this registration portal system.
Redirecting people's connections with DNS instead of with firewall magic
is much simpler but has some side effects, especially since the machine
that responds to the wildcard A record's IP address does have an ssh
server. We should probably do some work to make the wildcard record's
IP address block access to at least the ssh server.