Lab 2:
Networking in the cloud

Overview:

As with any virtual environment networking is one of the most important aspects that must be addressed. Amazon’s Web Services gives you enough networking options to meet almost any need that could be done in a physical environment.

In this lab you will learn about:

·  Public IP Addresses

·  Private IP Addresses

·  Elastic IP Addresses

·  Virtual Private Clouds

·  Internet gateways

·  Amazon DNS & DHCP

Public IP, Private IP and Elastic IP Addresses

Public IP addresses are addresses that can be reached from anywhere on the Internet. These workas regular IP address that routable on the internet. When you launch an instance into EC2 your instance is automatically given a Public IP and a Private IP address. The private IP address works for Amazon’s internal networks and allows you to send traffic between your instances without having to route it through the public internet. This is important from a cost perspective because all internal traffic is free of charge. During this class you will not find it terribly important to limit the amount of external traffic but in a real world scenario the charges can quickly add up.

Public and private IP addresses are only assigned through DHCP which means that the addresses are not static. Every time you stop and start the instance the address will change. Using these default settings gives you very limited functionality for your instances.

Elastic IP addresses work a lot like public static addresses in that they are addresses that are given to your account that can be attached to any instance and it won’t change unlike your other IP addresses. If you want to run a temporary web server this would be an important option. Because the server is always up and you need to access it with a consistent address, you would attach an elastic IP to reach the server. What’s best about elastic IP addresses is that they can be moved from one instance to another and the address stays the same.

There is no charge for elastic IP addresses unless you have some that are not assigned to an instance. In this case amazon will charge the account a small fee for every hour that the IP address is free. If you are no longer in need of an elastic IP address remove it.

Note: When you stop an instance that is associated with an elastic IP address, the address will disassociate itself upon shutdown

Pinging Externally and internally

  1. First launch two micro Linux instances like you did for Lab 1. Make sure they are both in the same security group.
  2. Name one MachineA and the other MachineB.
  3. Connect to MachineA via SSH
  4. Looking at your instances from the Instance Library, select Machine A and scroll down to the DNS information.
  5. Looking at the Public DNS you can see the public IP address for your instance. The address is the sequence of numbers between ec2 and .compute-X.amazonaws.com. In the screenshot above it is 50.16.55.68. This is the address that can be used to communicate with the machine from the public Internet. The Private IP address, 10.28.133.227, is the address that can only be reached by internal Amazon instances.
  6. Before we can actually issue a ping command we need to allow for that type of traffic. Remember in Lab 1 you set your security group (firewall) to only allow SSH traffic.
  7. Go to Security groups and select the security group you selected in Lab 1
  8. Add 2 new rules. Both are Custom ICMP rules: one for Echo Replies, and one for Echo Requests
    Make sure to apply the changes!
  9. Now that the rules have been implemented, you should be able to ping from MachineA to MachineB, from your personal computer to MachineA and MachineB, and you should still be able to ping from MachineA to any external address

Deliverables:

·  Screenshots of the three ping scenarios as described in Step 9

·  Implement your own Firewall Rule that will only allow for internal IP addresses to be able to ping machines

Implement An elastic IP address

  1. From the navigation menu on the left, go to Elastic IPs
    From this screen you’ll see a list of all Elastic IPs for the account. If the Address is associated with an instance, the Instance ID field will have a value. Use the Address that is assigned to you or your group.
  2. Select an address and go to Associate Address on the top menu bar
  3. A new pop up will appear and will ask you to select your instance. If your instance doesn’t have a name you will have to navigate back to get the instance ID.
  4. Once your address has been associated the fields will be populated

Deliverables:

·  Screenshot of your newly associated address

·  Screenshot of a ping sent from your local machine to the new Elastic IP

·  Screenshot of you logging in to the instance using the elastic IP

Virtual Private Clouds

While the IP addresses that we’ve talked about up to this point may work for some situations, they are not long term solutions for production environments. This is where Virtual Private Clouds come in. Virtual Private Clouds is a service that lets you set up a virtual network topology so that you can customize it with subnets and your own routing. This gives you more flexibility on which instances are publicly reachable - such as webserver - and which should only be accessed internally – like a database server.

There are a number of ways that a VPC can be setup

The first two options is what we’ll be concerned with in this class, more specifically the first for now. This option will allow us to create a network topology that will still be able to access the Internet and other Amazon services. For future projects you may want to practice and implement using a VPC with Public and Private Subnets.

The later two options are best used for corporations. VPN allows for more secure connection to the Amazon instances and is another layer of security that some organizations may be concerned with. For example if you are an organization that hosts proprietary information on Amazon and don’t want anyone capturing your data as it is transmitted, a VPN tunnel may be one of the technologies that you will leverage to provide added security. However, since we are not going to be using any VPN tools this is out of the scope of the class.

When creating a VPC using the VPC Wizard, the system will create all the necessary component to get the topology that you want. In reality it sets up several parts for you:

·  Virtual Private Cloud – This is the actual network setup that has the CIDR notation and determines how many hosts your VPC will be able to handle

·  Subnets – You can create more than one subnet for your VPC. This is how you would be able to create a private subnet that would not be immediately accessible from the outside

·  Internet Gateway – If the topology that you setup is supposed to be accessible through the public Internet then an Internet Gateway is what it will use to communicate with everything outside of the VPC

·  Route Tables – Think of these as the rules that you would apply in a router. This is what is going to be controlling the traffic that is generated from your topology. You can set certain kinds of requests to only go to a certain machine. For example any HTTP 80 requests should only be directed to your web server. When you first create a VPC, the system will create two route tables one will be marked as main and the other one will not. The main route table is what your VPC will first try to use when traffic is trying to find its way. This route table says that anything with a certain address range (what you identified as in your CIDR notation) should be handled as local traffic. So if one of your instances is trying to communicate with another instance within the VPC the main route table will identify that it is local communication and will route it to the proper place. However, if the traffic is determined not to be local then it will go to your second route table that says “redirect everything else that is not local traffic (0.0.0.0/0 - anything) to the Internet gateway”.

·  DHCP Option Sets – These let you identify the name of your domain, domain servers, ntp servers, netbios-name-servers, and netbios-node-type. When a computer is added to your VPC the first thing it will do is talk to the DHCP service to know what information it will get from what machine. DHCP is what automatically assigns IP addresses to machines when they first join the network.

Using a VPC

For the following part of the lab you are going to replicate the following setup:

You are going to launch 3 machines into a VPC. 2 will be Ubuntu machines and one will be a Windows 2008 Server. One of your Ubuntu machines will be running an NTP (Network Time Protocol) server, one will be a regular machine, and your Windows 2008 Server will have a service of your choice. The purpose of this Lab is to utilize a VPC to launch an internal network with modified DHCP options that point to your NTP server and provide the same time to your 2 other machines.

1.  Log on to the Amazon Web Services Console and Navigate to VPC from the top navigation bar.
The VPC Dashboard page gives you a summary of all the VPC services that you have deployed.

2.  Go to Your VPCs and select the VPC ID that was assigned to you. On a piece of paper write down your VPC ID, DHCP-option set, and main route table.

3.  On the left navigation bar, go to Subnets

4.  Find the subnet that is assigned to your VPC by matching up your VPC ID. Write down your subnet ID.
These are important for when you’re going to launch your instances. You need to know your subnet ID and your VPC ID. Later you’ll also use your DHCP ID to edit your DHCP options.

5.  Navigate back to EC2 (Top Navigation Bar > EC2) and Launch a new Instance.

6.  You’re going to launch 2 small Ubuntu 12.04 servers into the subnet that corresponds to your VPC (this is where writing down the number helps). Make sure the instances are small not micro. Micro instances cannot be launched inside of VPCs.

7.  When you get to the Firewall page you will have to create a new security group. Security Groups for VPCs are different than previous ones we’ve used and so a new group has to be created. Create the rules that we will need for this lab to work. We will definitely need RDP, SSH, and NTP (UDP port 123)

8.  Launch a Windows 2008 Server into the same VPC

9.  Because all of these instances are within a VPC you will not see a public DNS. You need to associate an Elastic IP address to the machines that you will be connecting to. You can use 2 or 3 elastic IPs. In reality you can also just use 1 and move it from instance to instance as you need to.

10.  Using the Elastic IP address, SSH into the machine that will be running your NTP server. Google search instructions on how to install and configure an NTP server. When modifying the configuration file add the following 3 servers

  1. nist1-ny.ustiming.org
  2. nist1-ny.ustiming.org
  3. nist1-pa.ustiming.org

Make sure you are installing ntpd NOT ntpdate

11.  Once you have installed and configured the NTP server correctly issue the following command: sudo ntpq –c lpeer
The command should give you something like this:

12.  Once the NTP server is setup, go back to VPC area and click on DHCP Option Sets in the left navigation bar.

13.  Create a new DHCP Option Set

14.  In the new pop up you are only going to fill out two fields:

  1. Domain Name server: AmazonProvidedDNS
  2. NTP Server: [IP address of your Ubuntu instance running NTP server]

15.  Now apply this to your VPC by going to Your VPCs on the left navigation, selecting your VPC and clicking Change Your DHCP Options Set and select the set you just created

16.  Now log in to your other Ubuntu Instance and point the ntpdate address to your NTP server. (you can Google search this)

17.  Logging into your Windows machine also point the time update to your NTP server

18.  Now add one more service to any of your machines and include a screenshot. This could be DNS, Active Directory, Webserver, etc..

Deliverables:

·  Include a screenshot for the following steps: 10, 11, 14, 16, 17, & 18