|
|
| (3 intermediate revisions by the same user not shown) |
| Line 2: |
Line 2: |
|
| |
|
| This page will cover a couple of key aspects of networking services on Linux: | | This page will cover a couple of key aspects of networking services on Linux: |
| * ip address schema | | * ip address schema - [[Linux/IP Schema]] |
| * dhcp server
| | * dhcp server - [[Linux/DHCP]] |
| * dns server
| | * dns server - [[Linux/DNS]] |
| * ntp server
| | * ntp server - [[Linux/NTP]] |
| | |
| | |
| ==IP Schema==
| |
| | |
| First principle: keep schema easy to change
| |
| | |
| What types of machines are you providing addresses to? Servers/workstations/printers, but now also phones, conference systems, tablets. many devices also have multiple network interfaces. a default network of 24 bits, 254 usable ip addresses, is not large enough for many situations.
| |
| | |
| multiple subnets would help to create individual networks for groups of devices (types of services). example: have servers on one subnet, printers on antoher, workstations on yet another.
| |
| | |
| the broadcast domain should also be limited. With a one-size-fits-all 24 bit network, you have a single subnet, and a single broadcast domain. Every device can communicate with every other device, with no need for routing. However, on large networks, breaking down the broadcast domain can help ensure performance. Organizing sub domains for different services keep those services from being overwhelmed.
| |
| | |
| To plan IP schema, use the <code>ipcalc</code> utility. This can help you understand the number of IP addresses that will be available for a given schema.
| |
| | |
| <pre>
| |
| $ apt-get install ipcalc
| |
| </pre>
| |
| | |
| You give it arguments of the network you are thinking about using:
| |
| | |
| <pre>
| |
| $ ipcalc 10.10.96.0/22
| |
| </pre>
| |
| | |
| ipcalc shows Hosts/Net, which is the number of allowable IP addresses that this network would give us.
| |
| | |
| The utility also shows the subnet mask that would be required, which is <code>255.255.252.0</code>.
| |
| | |
| ===ipv4 vs ipv6===
| |
| | |
| insert obligatory reference to number of IP addresses running out...
| |
| | |
| ipv6 needs to be ushered in.
| |
| | |
| HOWEVER, for small, internal networks, there is absolutely no need to complicate your life with ipv6. The namespace for ipv4 running out will only affect the wider internet, and not local nor private network IP spaces.
| |
| | |
| Unless you are a networking company. Or studying for a certification.
| |
| | |
| | |
| ==dhcp server==
| |
| | |
| now that we have used ipcalc to decide on a network layout (ip schema, number of addresses, number of bits, subnet mask, etc.), put it into action.
| |
| | |
| set up dhcp server to configure and serve up IPv4 addresses to machines that want one.
| |
| | |
| Use the <code>isc-dhcp-server</code>:
| |
| | |
| <pre>
| |
| $ apt-get install isc-dhcp-server
| |
| </pre>
| |
|
| |
| Now configure the dhcp server by editing its configuration file, located at <code>/etc/dhcp/dhcp.conf</code>
| |
| | |
| If you have a sample dhcp.conf file present, it will be pretty extensive. Or, it might be totally empty. Here is a sample:
| |
| | |
| <pre>
| |
| default-lease-time 86400;
| |
| max-lease-time 86400;
| |
| option subnet-mask 255.255.252.0;
| |
| option broadcast-address 10.10.99.255;
| |
| option domain-name "local.lan";
| |
| authoritative;
| |
| subnet 10.10.96.0 netmask 255.255.252.0 {
| |
| range 10.10.99.100 10.10.99.254;
| |
| option routers 10.10.96.1;
| |
| option domain-name-servers 10.10.96.1;
| |
| }
| |
| | |
| </pre>
| |
| | |
| To go through that a bit slower:
| |
| | |
| the default lease time and max lease time set the lease times of ip addresses.
| |
| | |
| The subnet mask and broadcast address options specify what subnet mask the clients will be given, and what broadcast address they'll use.
| |
| | |
| The subnet mask identifies the network that each connecting node will be a part of. The clients check their IP information after being provided an address. The subnet mask identified here should be shown.
| |
| | |
| The broadcast address is the address on which all nodes within this subnet are able to receive packets.
| |
| | |
| The domain-name option applies the domain name to the hostnames of each node that connects to the DHCP server. The authoritative option specifies that this DHCP server should be the primary DHCP server for this subnet.
| |
| | |
| The following lines about the subnet range, routers, and domain name servers:
| |
| | |
| <pre>
| |
| subnet 10.10.96.0 netmask 255.255.252.0 {
| |
| range 10.10.99.1 10.10.99.254;
| |
| option routers 10.10.96.1;
| |
| option domain-name-servers 10.10.96.1;
| |
| }
| |
| </pre>
| |
| | |
| these identify network address for the subnet, the subnet mask, the range of IP addresses that will be issued, the default gateway, and the DNS server.
| |
| | |
| This example shows that the first DHCP-issued address will be at 10.10.99.100 and it will end at 10.10.99.254.
| |
| | |
| This cuts out a really large number of possible IP addresses. The range we have specified, <code>10.10.96.0/22</code>, covers the following subnets:
| |
| | |
| <pre>
| |
| 10.10.96.0
| |
| 10.10.97.0
| |
| 10.10.98.0
| |
| 10.10.99.0
| |
| </pre>
| |
| | |
| so in fact we could hand out IP addresses starting at <code>10.10.96.1</code>, rather than <code>10.10.99.100</code>.
| |
| | |
| Once you have edited this file, you will restart the daemon.
| |
| | |
| <pre>
| |
| $ systemctl restart isc-dhcp-server
| |
| </pre>
| |
| | |
| ===an easier example===
| |
| | |
| This example is easier, as it only configures a network like <code>10.10.10.0/24</code> - a 24 bit network:
| |
| | |
| <pre>
| |
| default-lease-time 86400;
| |
| max-lease-time 86400;
| |
| option subnet-mask 255.255.255.0;
| |
| option broadcast-address 10.10.10.255;
| |
| option domain-name "local.lan";
| |
| authoritative;
| |
| subnet 10.10.10.0 netmask 255.255.255.0 {
| |
| range 10.10.10.10 10.10.10.254;
| |
| option routers 10.10.96.1;
| |
| option domain-name-servers 10.10.96.1;
| |
| }
| |
| </pre>
| |
| | |
| This sets the dhcp range to start at <code>10.10.10.10</code> and end at <code>10.10.10.254</code>. This gives 9 IP addresses that will never be assigned - which is useful if you need to assign static IP addresses to any machines.
| |
| | |
| ===Static IP Addresses===
| |
| | |
| To configure the DHCP server to hand out a static IP address lease, place a reservation at the end of <code>/etc/dhcp/dhcpd.conf</code>:
| |
| | |
| <pre>
| |
| host miami {
| |
| hardware ethernet AA:BB:AB:BA:DE:AD:BE:EF
| |
| fixed-address 10.10.97.4
| |
| }
| |
| </pre>
| |
| | |
| This will give the host miami with the mac address specified the fixed IP address of 10.10.97.4.
| |
| | |
| ===Restarting DHCP Server===
| |
| | |
| To restart the DHCP server once you have made changes:
| |
| | |
| <pre>
| |
| $ systemctl restart isc-dhcp-server
| |
| </pre>
| |
| | |
| | |
| ==DNS Server==
| |
| | |
| DNS stands for domain name system - it turns IP addresses into human-readable host names.
| |
| | |
| DNS is useful for the wider internet, obviously, but is also useful on a small network. DNS is useful for more than a handful of networked computers.
| |
| | |
| ===Installing/Starting===
| |
| | |
| On Debian, use <code>bind9</code> (BIND = Berkeley Internet Name Domain). This is the most popular name server around. Once you install it, Debian should boot it up for you and configure the daemon.
| |
| | |
| First, install it:
| |
| | |
| <pre>
| |
| $ apt-get install bind9
| |
| </pre>
| |
| | |
| Check that it is running:
| |
| | |
| <pre>
| |
| $ systemctl status bind9
| |
| ● bind9.service - BIND Domain Name Server
| |
| Loaded: loaded (/lib/systemd/system/bind9.service; disabled)
| |
| Drop-In: /run/systemd/generator/bind9.service.d
| |
| └─50-insserv.conf-$named.conf
| |
| Active: active (running) since Mon 2016-03-14 15:00:06 PDT; 18s ago
| |
| Docs: man:named(8)
| |
| Main PID: 16356 (named)
| |
| CGroup: /system.slice/bind9.service
| |
| └─16356 /usr/sbin/named -f -u bind
| |
| | |
| Mar 14 15:00:06 basilisk named[16356]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
| |
| Mar 14 15:00:06 basilisk named[16356]: command channel listening on 127.0.0.1#953
| |
| Mar 14 15:00:06 basilisk named[16356]: couldn't add command channel ::1#953: address not available
| |
| Mar 14 15:00:06 basilisk named[16356]: managed-keys-zone: loaded serial 0
| |
| Mar 14 15:00:06 basilisk named[16356]: zone 0.in-addr.arpa/IN: loaded serial 1
| |
| Mar 14 15:00:06 basilisk named[16356]: zone 127.in-addr.arpa/IN: loaded serial 1
| |
| Mar 14 15:00:06 basilisk named[16356]: zone 255.in-addr.arpa/IN: loaded serial 1
| |
| Mar 14 15:00:06 basilisk named[16356]: zone localhost/IN: loaded serial 2
| |
| Mar 14 15:00:06 basilisk named[16356]: all zones loaded
| |
| Mar 14 15:00:06 basilisk named[16356]: running
| |
| </pre>
| |
| | |
| Until the DNS server is configured, it won't be doing anything for us.
| |
| | |
| ===Configuring DNS===
| |
| | |
| The configuration file for BIND is located in <code>/etc/bind/named.conf</code>.
| |
| | |
| If the file has text in it already, back it up and clear it out. Now what we'll do is include two additional configuration files, to make our lives easier:
| |
| | |
| <pre>
| |
| include "/etc/bind/named.conf.options"
| |
| include "/etc/bind/named.conf.local"
| |
| </pre>
| |
| | |
| Note that we can put those files wherever we want, and create our own layout of configuration files.
| |
| | |
| ===Configure DNS Forwarding===
| |
| | |
| Start by setting up your DNS server to forward DNS requests that it can't handle to another (public) DNS server. Start by editing the BIND configuration options:
| |
| | |
| <pre>
| |
| $ vim /etc/bind/named.conf.options
| |
| </pre>
| |
| | |
| Edit this file and add the following contents:
| |
| | |
| <pre>
| |
| options {
| |
| forwarders {
| |
| 8.8.8.8; 8.8.4.4;
| |
| };
| |
| };
| |
| </pre>
| |
| | |
| What we are doing here is to create instructions for where to forward DNS requests, if it cannot find what it is looking for. (Note that this is usually done by default, but doing it this way allows us to specify which DNS servers to use.) These two (8.8.8.8 or 8.8.4.4) are both name servers from Google.
| |
| | |
| ===Local DNS Configuration===
| |
| | |
| Now we can set up the DNS configuration for the local network and its subnets. Start by editing the file:
| |
| | |
| <pre>
| |
| $ vim /etc/bind/named.conf.local
| |
| </pre>
| |
| | |
| Add the following contents to that file:
| |
| | |
| <pre>
| |
| zone "local.lan" IN {
| |
| type master; file "/etc/bind/net.local.lan";
| |
| };
| |
| | |
| zone "96.10.10.in-appr.arpa" {
| |
| type master; notify no; file "etc/bind/revp.10.10.96";
| |
| };
| |
| | |
| zone "97.10.10.in-appr.arpa" {
| |
| type master; notify no; file "etc/bind/revp.10.10.97";
| |
| };
| |
| | |
| zone "98.10.10.in-appr.arpa" {
| |
| type master; notify no; file "etc/bind/revp.10.10.98";
| |
| };
| |
| | |
| zone "99.10.10.in-appr.arpa" {
| |
| type master; notify no; file "etc/bind/revp.10.10.99";
| |
| };
| |
| </pre>
| |
| | |
| Here is an explanation of the pieces:
| |
| * The first line defines our local domain name. We picked the very boring name of "local.lan"
| |
| * This block calls out another file, "/etc/bind/net.local.lan"
| |
| * The remaining four blocks create configurations for reverse lookups on the four subnets we are creating. If you only have one subnet on your network, you will only include one block for the one subnet.
| |
| * Each subnet has its own reverse-lookup file where we can configure things. Each file is stored in <code>/etc/bind</code>.
| |
| | |
| ===DNS Records===
| |
| | |
| Now let's look at the actual DNS records (in the reverse-lookup files listed in the code above).
| |
| | |
| Starting with <code>/etc/bind/net.local.lan</code>:
| |
| | |
| <pre>
| |
| ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
| |
| ; dns zone for for local.lan network
| |
| ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
| |
| | |
| $TTL 1D
| |
| | |
| @ IN SOA local.lan. administrator.local.lan. (
| |
| | |
| 201507261 ; serial
| |
| | |
| 8H ; refresh
| |
| 4H ; retry
| |
| 4W ; expire
| |
| 1D ) ; minimum
| |
| IN A 10.10.96.1
| |
| ;
| |
| @ IN NS hermes.local.lan.
| |
| ceres IN A 10.10.98.1
| |
| euphoria IN A 10.10.97.4
| |
| galaxy IN A 10.10.96.4
| |
| hermes IN A 10.10.96.1
| |
| puppet CNAME galaxy
| |
| ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
| |
| ; end dns zone for for local.lan network
| |
| ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
| |
| </pre>
| |
| | |
| Going through this line by line:
| |
| * TTL is time to live, set to 1 day - this is how long DNS records are cached (important with multiple DNS servers or dynamic IP addresses)
| |
| * SOA is start of authority, which defines which comptuer has DNS authority on this local network. The <code>administrator.local.lan</code> is an email address.
| |
| * 201507261 is the serial number. if you change a zone file in bind, you should change this serial number. It is the first thing the daemon reads and it is how the daemon knows if the DNS records have been changed.
| |
| | |
| | |
| <!--
| |
| Each time our bind daemon is restarted, it will reload this file. But when it does, the serial number is the first thing it will look at. If it is the same, it will likely not load in any changes. Thus, every time you change a zone file in bind, you must change this serial number as well. In this example, the current date is being used without hyphens or spaces. The last digit is just a revision number for that day, if the file is changed multiple times in one day. You can use whatever scheme you'd like. But using the date is a very popular approach. Regardless of the format you use, always ensure you increment the serial by 1 with every change you make. You'll save yourself frustration wondering why newly created records aren't taking affect.
| |
| | |
| 8H ; refresh
| |
| 4H ; retry
| |
| 4W ; expire
| |
| 1D ) ; minimum
| |
| These values dictate how often slave DNS servers will be told to check for updates. The first value will configure slaves to refresh zone records from the master (this server) every eight hours. In regards to retry, we're letting slaves know that should there be a problem connecting, check back in this amount of time. Finally, we're setting our minimum age of zone records to one day, and the maximum to four weeks. Configuring slave DNS servers is beyond the scope of this book, but having this configuration in place doesn't hurt anything in case you do decide to configure slave DNS servers later on.
| |
| | |
| @ IN NS hermes.local.lan.
| |
| Here, we're identifying this name server. In my case, I'm calling it hermes and its full domain name is hermes.local.lan.
| |
| | |
| galaxy IN A 10.10.96.4
| |
| hermes IN A 10.10.96.1
| |
| Finally, in this sample configuration, four address records are called out. This basically means that any time someone is looking for one of these hosts, the request is mapped to the listed domain name. These can be among multiple subnets or a single subnet. In my case, these hosts are on different subnets:
| |
| | |
| puppet CNAME galaxy
| |
| The final line of this configuration contains a Canonical Name (CNAME) record. Basically, this allows us to refer to a server by another name. In this example, galaxy is also used for software known as puppet, so a CNAME record has been set up for it. This way, if someone were to try to access galaxy.local.lan or puppet.local.lan, their request would resolve to the same IP address (10.10.96.4). A CNAME records can be very useful if a single server provides more than one service to the network.
| |
| | |
| Earlier, I called out four reverse lookup records, /etc/bind/revp.10.10.96, /etc/bind/revp.10.10.97, /etc/bind/revp.10.10.98, and revp.10.10.99. Next, I'm going to demonstrate one of these files (in this case, for the 10.10.96.0 network):
| |
| | |
| $TTL 1D
| |
| @ IN SOA hermes.local.lan. hostmaster.local.lan. (
| |
| 201507261 ; serial
| |
| 28800 ; refresh (8 hours)
| |
| 14400 ; retry (4 hours)
| |
| 2419200 ; expire (4 weeks)
| |
| 86400 ; minimum (1 day)
| |
| )
| |
| ;
| |
| @ NS hermes.local.lan.
| |
| 1 PTR hermes.local.lan.
| |
| 3 PTR nagios.local.lan.
| |
| 4 PTR galaxy.local.lan.
| |
| With this configuration, you'll notice we have a start of authority record as with our master zone, and we also have a serial number. The same idea applies here. Whenever you update any record (including reverse lookup records), you should update the serial number of the file. The start of authority entry works the same as earlier, no surprises here. Where the file differs is how the hosts are called out. Rather than calling out an entire IP address, we only need to identify the last octet since the entire file is dedicated to reverse IP address lookups from the 10.10.96.0 network. For each of your subnets, you'll need to create a similar file. Again, in our sample configuration there are four subnets, but you don't need that many. It was only provided in this way in order to provide an example of how to handle separate subnets, should you need to do so.
| |
| | |
| With our configuration in place, feel free to restart the bind service on your DNS server and test it out. We can restart bind with the systemctl command, as before.
| |
| | |
| For Debian, use the following command:
| |
| | |
| # systemctl restart bind9
| |
| For CentOS, use the following command:
| |
| | |
| # systemctl restart named
| |
| One way we can test our DNS server is via the dig command. With Debian, you should already have this package installed. CentOS requires the installation of the bind-utils package. dig (domain information groper) is a utility that allows us to request information from a DNS server. To give it a shot, try it out with an internal hostname:
| |
| | |
| dig myhostname.local.lan
| |
| If your DNS server comes up under SERVER in the output, then your DNS server is functioning properly. If for some reason it doesn't, verify what you've typed, your serial number, and whether or not you have restarted bind since your last configuration change.
| |
| | |
| Feel free to practice setting up additional nodes and records within your DNS server. Setting up bind can be frustrating at first, but stick with it and you'll be a pro in no time. Using examples from this section, you should have a working skeleton you can use to set up a DNS server within your environment. Make sure that you change the hostnames and IP addresses contained within the configuration files to those that match your network. In addition, make sure you set up bind to match your subnets, or remove mentions of other subnets if you don't have any. To be safe, instead of copying the configuration directly from this book, it's usually better to type everything manually just in case.
| |
| -->
| |
|
| |
|
| =Related= | | =Related= |
|
| |
|
| {{LinuxNetworkingFlag}} | | {{LinuxNetworkingFlag}} |
