Table of Contents
In the previous lab, we installed our server virtual machine, Server1, applied a bunch of updates, and moved it into our production environment. In this lab, we’re going to continue from there, and actually make it part of the same network as our client, set up some IPv4 and IPv6 addressing and run a few tests. We shall also spend some time looking at one way of creating network services, as well as one common way to restrict access to network services.
Except where explicitly noted (typically in command prompts, but also in the text), all work is to be performed on the server you installed previously. You will also need Client1, but nothing else.
Currently, Server1 has been moved from the nursery into the production, and its “outside” interface is configured to attach to VirtualBox’s “NAT”, allowing it to access the outer (campus) network without the server needing an address on the outer network. But with this attachment comes a restriction; we can’t talk to other virtual machines. We want our virtual machines to all be connected to each other in a dedicated LAN.
We could re-attach the “outside” interface of Server1 to the internal network, which would allow us to connect with Client1, but that means we wouldn’t be able to connect to the outer network if we needed packages. That’s really annoying.
To solve this problem, we shall add another apaptor to VirtualBox, and configure the new interface as the “inside” interface. This will allow us to create a “dual-homed” configuration whereby we can talk to both the outside world and the internal network.
Shutdown the server cleanly. It needs to show its status as “Powered off”. If it is showing as “Saved” you will need to start it, then shut it down cleanly using shutdown -h now.
In the VirtualBox network setting for the server, leave Adaptor 1 as it is (it should be attached to NAT), and go into Adaptor 2. Enable the interface and attach it to the Internal Network “TELE301 Internal Network 1”.
Start the server. To prevent confusion, use the same method
we used in an earlier lab to change the interface name from “eth1”
to “inside” (hint:
/etc/udev/rules.d/70-persistent-net.rules).
Change the network interface configuration inside the server
by editing the file
/etc/network/interfaces.
auto outside
iface outside inet dhcp
auto inside
iface inside inet static
address 192.168.1.1
netmask 255.255.255.0Affect the changes by rebooting.
#shutdown -r now
Check that everything is now as expected, taking a screenshot of each test. First, are the interfaces configured as we would expect?
$ifconfig inside…IP address should be 192.168.1.1$ifconfig outside…IP address should be 10.0.2.15
Okay, now check that the routing table is as we expect, with a default route going out the “outside” interface:
$routeDestination Gateway Genmask … Iface 10.0.2.0 * 255.255.255.0 … outside 102.168.1.0 * 255.255.255.0 … inside default 10.0.2.2 0.0.0.0 … outside
Finally, a “test by doing”: can we get to the package repository?
#apt-get update… Fetched 565kB in 6s (87.56kB/s) Success! Reading package lists... Done
How might you test if a web server is working? You could look to see if it running (pstree etc.), but that isn’t an exhaustive test. It is much better to simply retrieve a page (possibly multiple pages), which tests the entire “stack”. Testing by doing is a great way of testing for success conditions, but is not a good way of diagnosing faults.
Okay, so now we know that Server1 can talk to the world. Let’s re-introduce Client1 into the network so we can test that we can communicate with hosts in the internal network.
Before you start Client1, go into the settings for tele301-client1 and ensure that the network adaptor Adaptor 1 is connected to the Internal Network “TELE301 Internal Network 1”. Then start Client1.
If you recall, in the lab on basic interface management, we
only gave Client1 a temporary IP address, and did not make a
permanent configuration. Let’s create one now. On Client1, edit
/etc/network/interfaces and
replace the stanza for iface
eth0:
auto eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0Affect the change using ifup:
client1#ifup eth0ssh … we can ignore such linesclient1$ifconfig eth0eth0 Link encap:Ethernet HWaddr 08:00:27:99:c2:7d inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe99:c27d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:5000 (5.0 KB)
Ensure you get the IPv4 address specified. Take a screenshot to show that you have successfully given Client1 its address.
We added Client1 to the network to ensure that Server1 could talk to other internal hosts, so let’s test that now. Still on Client1, let’s check that we can ping Server1:
client1$ping -c2 192.168.1.1PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.39 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.358 ms --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.358/1.874/3.391/1.517 ms
That worked, which means traffic can flow in both directions. To be doubly sure[42], let’s try the same thing on Server1:
server1$ping -c2 192.168.1.11PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data. 64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=4.88 ms 64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.385 ms --- 192.168.1.11 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.385/2.636/4.887/2.251 ms
Hooray! So we know local deliveries are working on the internal network. Time to go onto the next section.
[42] At present, its not actually needed, but in general, because of devices such as firewalls and NAT, it pays to test both directions if needed.