Networking on the cloud demonstrates some bipolar aspects — it is one of the fundamental enabling elements of cloud computing and also one of the hazards to users of cloud computing.

Network performance degradation and instability can greatly affect the consumption of cloud resources; therefore, applications that are relatively isolated or specially designed to deal with network disruptions have an advantage running in the cloud.

From a different perspective, network resources can be virtualized and used in cloud computing just as other resources are.

The different layers of the network system will be either the responsibility of the cloud provider or of the cloud consumer depending on the type of cloud. The table summarizes some typical scenarios:

The table is a simplification of the many models that exist in practice. However, it is obvious from the table that an IaaS gives cloud consumers considerably more flexibility in network topology and services than PaaS and SaaS clouds, possibly at the expense of managing the tools that provide the flexibility.

Let's examine the pros and cons of some network tools through the lens of different business scenarios with their different requirements.

Back to top

How network tools facilitate in various scenarios

Figure 1 depicts typical network topology for a composite web application. It contains firewall configurations, VLAN set up, public/private IP configuration for load balancing, and access to business partner's Intranet.

Let's look at how networking tools can be used in various business cloud organization scenarios.

In a production system (using firewalls):

• A proxy can also be used, but usually for load balancing, rather than for security purposes.
• An administrator can access back-end servers via SSH tunnel or a SOCKS proxy.
• Firewall rules are needed to allow servers inside the firewall to access the Internet for security updates, license activation, and other tasks without making the internals visible to the Internet.

For development scenarios (involving the use of VPNs):

• Reverse access into the enterprise may be needed.
• A lightweight setup is required because a network expert may not be available to help.
• A VPN server on a laptop with DHCP can be used to allow access from the cloud.

At the enterprise level:

• A site-to-site VPN may be necessary for general access to the enterprise.

Editor's note: The Resources section contains other resources that cover enterprise-level cloud networking and tools, including Deliver cloud network control to the user: See how using a virtual network can put the customer in control of cloud networking.

Back to top

Tools and the tasks they solve

Following are a list of tools helpful for managing the delivery of cloud services over a network.

• Connecting to the VM (IP addresses)
• Managing virtualized networks
• Managing multiple individual IP addresses
• Using a firewall to protect multiple virtual machines
• Authenticating users and servers via SSH or PuTTY
  • Port forwarding
  • Creating and using the SSH tunnel
  • Command-line tunneling with OpenSSH
  • Tunneling with PuTTY
• Using virtual private networks
• Setting up OpenVPN
• Setting up a proxy server

Back to top

Connecting to the VM via IP addresses

One of the first tasks you face in cloud computing is how to connect to your virtual machine. There are several options when creating a virtual machine: System generated, reserved, and virtual local area network (VLAN).

System generated is analogous to dynamic host control protocol (DHCP) assigned addresses. They are actually static IP addresses but assigned by the IaaS cloud. This is the easiest option if all you need is a virtual machine that you can log into and use.

Reserved IP addresses are addresses that can be provisioned and managed independently of a virtual machine. Reserved IP addresses are useful if you want to assign multiple IP addresses to a virtual machine.

We'll address VLANs later in the article.

Back to top

Managing virtualized networks

When dealing with systems of virtual machines and considering network security, you need to manage networks. Network resources can be virtualized just like other cloud resources. To do this a cloud uses virtual switches to separate a physical network into logical partitions. This concept is illustrated in Figure 2.

Virtual local area networks (VLANs) can be used as an extension of your enterprise's private network. VLANs in clouds use private IP addresses to restrict network visibility of the virtual machines connected to it. The Internet Assigned Numbers Authority (IANA) reserves the following three blocks of the IP address space for private networks:

• 10.0.0.0 - 10.255.255.255 (10/8 prefix)
• 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

You can connect to a VLAN through an encrypted virtual private network (VPN) connection or by routing over a dual-homed virtual machine connected to another network, including the Internet.

A hypervisor can share a single physical network interface with multiple virtual machines. Each virtual machine has one or more virtual network interfaces. There are three ways that the hypervisor can do this:

• Bridging
• Routing
• Network address translation (NAT)

Bridging is usually the default mode. In this mode the hypervisor works at the data link layer (OSI Layer 2; Table 1) and makes the virtual network interface externally visible at the Ethernet level.

In routing mode, the hypervisor works at the network layer (#3) and makes the virtual network interface externally visible at the IP level.

In network address translation, the virtual network interface is not visible externally. Rather, it enables the virtual machine to send network data out to the Internet but the virtual machine is not visible on the Internet.

Network address translation is typically used to hide virtualization network interfaces with private IP addresses behind a public IP address used by a host or router. The network address translation software changes the IP address information in the network packets based on information in a routing table. The checksum values in the packet must be changed as well.

Network address translation can be used to put more servers on the network than the number of virtual machines that you have. It can do that by port translation. This is one of the reasons that IPv6 is still not in wide use — even though the number of computers exceeds the number of IP addresses. There are some things you can do to share them.

For example, suppose that you have a router and three servers doing HTTP, FTP, and mail respectively. You can assign a public IP address to the router and private IP addresses to the HTTP, FTP, and mail servers and forward incoming traffic as shown in Table 2.

Back to top

Working with multiple IP addresses

IBM SmartCloud Enterprise allows you manage IP addresses independently and assign them to virtual machines, including possibly assigning multiple IP addresses to a single virtual machine.

Why would you want to do that? You might want higher availability or want to connect different network zones with a firewall or VPN. Those steps are described in the developerWorks tip Span virtual local area networks.

Back to top

Using a firewall to protect multiple virtual machines

An individual firewall is a firewall that is installed on the same server as the resource it is protecting. This is an essential tool in cloud computing. Most modern operating systems, including all the images on IBM SmartCloud Enterprise, are packaged with an individual firewall. On Linux® virtual machines this is iptables; on Windows® it is a Microsoft® solution.

On IBM SmartCloud Enterprise, there is also a firewall between the hypervisor and the virtual machines that it manages.

A firewall rule specifies a set of criteria for a network packet and a target. When a network packet arrives, each rule is checked. If the packet does not meet the criteria for the rule then the next rule is checked.

On SUSE machines, you can use the YAST administration utility to add firewall rules. For example, to allow access to port 50030 from any outside address:

1. Start YAST from the command line by typing yast as root and navigate to Security and Users > Firewall using the Tab key and press Enter. A screen similar to Figure 3 opens.
   
   Figure 3. YAST firewall management utility
   
   
   
2. Navigate to Custom Rules and click Enter.
3. Navigate to Add and click Enter.
4. Enter 0/0 for the Source Network, which indicates any source computer, and 50030 for the port, which is the port you are interested in. See Figure 4.
   
   Figure 4. Custom firewall rule in YAST
   
   
   
5. Click Add, Next, and Finish. There is no need to manually restart. YAST takes care of that.

On Red Hat images, you can use the iptables command to manage firewall rules. The basic form of an iptables command is:

# iptables [-t table] -[AD] chain rule-specification [options]

The actions associated with a firewall rule include ACCEPT, DROP, QUEUE, and RETURN. If you don't want to accept a network packet then you should specify a DROP action. In the iptables command, A appends a rule and D deletes one.

There are three firewall tables. The default table is named filter. This table contains three chains: input, forward, and output. The input chain is for packets coming in to the local sockets, the forward chain is for packets that are routed, and the output chain is for locally generated packets.

As an example, to allow network packets from any source on port 80, the default HTTP port, use the command # /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT.

This adds a rule to the input chain of the filter table for TCP packets on port 80 with an ACCEPT action. The -p parameter specifies the protocol, tcp in this case. The --dport 80 option is the destination port, 80 in this case. The -j (jump) option is the target, ACCEPT in this case.

It can be a good practice to only leave firewall rules in place for as long as you need them. The command-line form is ideal for doing this. However, often you will want to keep the rules permanently, including after the next time you restart the instance. To do that, edit the file /etc/sysconfig/iptables. A typical iptables file looks like this:

*filter
:INPUT DROP [67:14849]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [346:34696]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT

This specifies the rules for the filter table. All incoming packets from ports 67 to 14849 are dropped. No forwarding is allowed, all outgoing packets on ports 346 to 34696 are allowed, and incoming packets on port 22 (SSH) are allowed. After you have made the edits and saved the file, start or restart the iptables service with the command # /sbin/service iptables restart.

If you have made changes with the iptables command, save them with the command # /sbin/service iptables save.

Check the status of the firewall with the command:

# /sbin/service iptables status

There are some performance advantages to be gained from using the hypervisor firewall rules. However, you cannot manage them as dynamically as the rules for the local firewall and you can only do it for your personal or community level visibility images.

You can set the hypervisor firewall rules at instance creation time using the parameters.xml file on IBM SmartCloud Enterprise. Find this XML file in the asset catalog entry for your image.

Linux firewalls can also be used to protect servers other than the server that the firewall resides on. Actually, this is a preferred configuration because it provides an additional level of isolation.

To protect servers, you first need to isolate the servers that you are protecting from the Internet by placing them on a VLAN. Add two IP addresses on the firewall virtual machine. Finally, configure rules for forwarding between the Internet and the VLAN in iptables. See Figure 5.

In Figure 5, virtual machine VM1 is directly connected to the Internet. The firewall VM2 has two IP addresses:

• One is Internet accessible
• One is on the private VLAN

Virtual machine VM3 has a single IP address that is only accessible on the VLAN. A firewall rule allowing inbound access from the Internet and mapping the firewall's IP to VM3's IP for a certain port allows inbound access from the Internet on that port only.

For example, if this was a web server and a user attempted to access the firewall's IP address on port 80, then that request would be forwarded to a web server on VM3. No other ports on VM3 are open.

Another firewall rule allows outbound access for VM4. This can be done by using ports dynamically for an individual TCP connection. For example, if VM4 attempts to open a TCP connection to the Internet, then the firewall can find an available port and change the TCP packet to contain this port and the firewall's own IP address. When it receives a packet back from the Internet in response to the request from VM4, then it does reverse mapping. In this way, the virtual machine VM4 is able to open connections to the Internet without being visible on the Internet.

Back to top

Authenticating users and servers with SSH or PuTTY

As seen in the previous sections, SSH is a fundamental tool in cloud computing; it can be worth learning in order to solve numerous practical problems in cloud computing. SSH was designed as a secure replacement for telnet, but now is also commonly used programmatically for many applications.

The two main versions of SSH are SSH-1 and SSH-2. The original version, SSH-1, has been replaced by SSH-2. SSH-2 was developed as a standard by the Internet Engineering Task Force, being released in 2006. The most popular implementation of SSH is the OpenSSH open source project. On Windows, PuTTY is the most popular client. See the Resources section for information on the basic use of PuTTY.

SSH uses public key cryptography for authenticate the remote computer and the user, if necessary. Besides remote login, SSH can also be used for tunneling, forwarding, X11 connections, and transferring files. Files can be copied with the SCP (Secure Copy) protocol and SFTP, which both use SSH.

Consider this common scenario: You create two instances on the cloud, server1 and server2, and you want to open an SSH session from server1 to server2. You should already have your private key on your local PC, so you need to copy it to server1. You can do that with WinSCP. Server2 will already be configured to accept this key because it was created with the public key in the authorized key list. Use these commands:

> chmod 0700 mykey
> ssh -i mykey server2

Where mykey is the name of your private key. You should make your private key so that it is not visible to other users. The chmod command does this. If you do not, ssh will complain and may ignore the key. The -i option uses the key that you have just copied in the SSH session. The default is ~/.ssh/id_rsa. The server2 argument is the host name or IP address of server2. Make sure that you have the right permissions on the directory .ssh. If some of the files are owned by root, then change them to idcuser with the chown command.

To generate a new SSH key, use the ssh-keygen command. For example, > ssh-keygen -t rsa -P 'My Passphrase' -f ~/.ssh/mykey.

This generates an RSA type (-t flag) with the passphrase 'My Passphrase' (-P flag), place the private key in the file ~/.ssh/mykey (-f flag) and place the public key in the file ~/.ssh/mykey.pub. If you do not use a -f option then the private key is written to ~/.ssh/identity. Authorized keys are contained in the file ~/.ssh/authorized_keys. To add a new public key to the authorized keys file, append it with the command:

> cat mykey.pub >> ~/.ssh/authorized_keys

The SSH keys generated by IBM SmartCloud Enterprise are in a format compatible with OpenSSH. You can also convert these to PuTTY format using PuTTYgen. PuTTYgen can also convert back to OpenSSH format, in case you lose the original key. To do this go to the Conversions > Export OpenSSH Key menu and save the file.

PuTTYgen can also generate keys. Upload the generated public SSH key to SmartCloud Enterprise if you prefer not to use the keys generated by the cloud.

The configuration file for SSH on the Linux systems on IBM SmartCloud Enterprise is at /etc/ssh/ssh_config and /etc/ssh/sshd_config. The AllowedUsers setting is one setting that you might change. The value of this parameter is a space-separated list of user name patterns. For example, AllowUsers idcuser webadmin.

To start the SSH server (sshd), use the command # /etc/init.d/sshd start; to restart, use the command # /etc/init.d/sshd restart.

You may want to include the user name in the SSH command in some cases, especially from scripts. To do that, use the form $ ssh -i .ssh/key-file idcuser@host:

• The @ symbol delineates the user name from the host name or IP address.
• The -v option (verbose) prints out extra information and can be useful in debugging problems.

For most of the images in IBM SmartCloud Enterprise, by default the SSH server sends informational and error messages to the file /var/log/secure.

It is a good practice to add a passphrase to your SSH keys to protect them. The problem with that practice is that scripts and programs that need access to the keys do not have the passphrase. The ssh-agent tool, which is a part of the OpenSSH distribution, is designed to solve this problem. It can automate entry of the passphrase in a similar way that a stash file can allow the web server to open the X.509 certificate.

A number of tools tunnel over SSH. For example, NX remote desktop technology tunnels over SSH. Several file transfer tools also tunnel over SSH.

Secure Copy, also known as SCP, is a protocol and a program to transfer files securely. It is based on BSD remote copy (RCP) command tunneled through SSH. As with SSH, by default it runs on port 22. To use SCP on Linux, use this command:

# scp -i identity_file host:sourcefile destinationfile

That command uses the private key file identity_file to copy the file sourcefile from machine host to the file destinationfile on the local machine.

The Windows WinSCP program actually works on SFTP (secure FTP) by default but can also use SCP.

Port forwarding with SSH

Port forwarding with SSH is a process where:

1. The address and port of a packet is translated to a new destination.
2. The packet is carried over an SSH connection where the destination is accessed.

It allows a user to tunnel another protocol over an SSH connection. With OpenSSH this is done with sshd. This can be useful if the protocol being tunneled is not secure or the destination address and port combination is not visible from the origin.

The client that uses the tunneled protocol must be able to specify a non-standard port for this to work. The concept is that you establish a SSH session to your server and then specify which port on the client machine to forward connections from.

SSH can also forward to other servers. Port forwarding can be important for solving connectivity problems between the cloud, your workstation, and IT resources inside your company. This is especially important where you need flexible but secure access for low-volume administrative tasks such as moving files to secure locations.

Knowing the tools well can avoid you having to write and maintain custom code for these administrative tasks. An example with VNC is provided in this section.

Connecting to remote Linux desktops is frequently needed in cloud applications. Because the remote machines are on the Internet, you should avoid sending unsecured network traffic to them and also avoid opening insecure services, like VNC, on the Internet.

Figure 6 shows a schematic representation of the network connections involved.

A VNC server running on the virtual machine on port 5901 connects to an X11 display, which in turn supports a Linux desktop. The laptop or workstation uses an SSH client to create a connection with a tunnel to the SSH server running on the virtual machine. A firewall running on the virtual machine prevents any traffic other than SSH traffic running on port 22 from accessing the virtual machine. The tunnel allows a VNC client running on the laptop to connect to the VNC server travelling through the firewall on port 22.

Creating and using the SSH tunnel

1. Change to root and go to directory /etc/ssh and edit file sshd_config:

   AllowTcpForwarding yes

   
   
2. Restart the ssh server as root:

   # /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]

   
   
3. If it is not already running, start VNC as idcuser:

   $ /usr/bin/vncserver ... New 'vhost0270:1 (idcuser)' desktop is vhost0270:1 Creating default startup script /home/idcuser/.vnc/xstartup Starting applications specified in /home/idcuser/.vnc/xstartup Log file is /home/idcuser/.vnc/vhost0270:1.log

   
   
4. Enter the password when prompted and answer no for a view-only password. The command prints out the information shown, which includes the name of the log file.
5. The first time that you run vncserver, it creates the configuration file ~idcuser/.vnc/xstartup. You need to change two settings in that file to be able to login with a normal desktop. Uncomment these two lines in the file ~idcuser/.vnc/xstartup:

   unset SESSION_MANAGER exec /etc/X11/xinit/xinitrc

   
   
6. You may not find these two lines in xstartup if you use SUSE. Stop and start the VNC session:

   $ /usr/bin/vncserver -kill :1 $ /usr/bin/vncserver

   
   

   In this example, the display :1 in the first command must match the display created when you previously started vncserver.

7. Check the VNC log to find the port that it is running on. You should see something like this:

   tail -f /home/idcuser/.vnc/vhost0270:1.log Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Underlying X server release 70101000, The X.Org Foundation Sun Oct 16 03:54:31 2011 vncext: VNC extension running! vncext: Listening for VNC connections on port 5901 vncext: Listening for HTTP connections on port 5801 vncext: created VNC server for screen 0

   
   

   In this example you see that VNC is listening for connections on port 5901.

Use an SSH client to connect to the virtual machine. The next sections describe 2 clients: OpenSSH and PuTTY.

Tunneling with the OpenSSH command

You can use OpenSSH on Linux or Windows through a Cygwin command line. With Cygwin, install the cygwin openssh package first if your system does not already have it.

Start a tunnel from your SSH client to the virtual machine on port 5901:

$ ssh -i ~/.ssh/key_name -L 5901:localhost:5901 idcuser@${SCE_VM}

The -i option specifies the key to use and the -L option specifies the tunnel. The port used (5901) must match the port used by the VNC server running on the virtual machine.

Tunneling with PuTTY

To create an equivalent tunnel with PuTTY:

1. Click Connection > SSH > Tunnels to open the PuTTY Configuration window shown in Figure 7.
   
   Figure 7. Setting up a tunnel with PuTTY
   
   
   
2. Enter the destination port 5901 in the source port and destination port in the form ip:port in the Destination field.
3. Click Add.
4. Click Open.
5. Enter idcuser at the login prompt. The tunnel is created and logs you into an interactive shell.
6. Start the VNC client. Enter the address localhost:5901 as shown in Figure 8.
   
   Figure 8. VNC client
   
   
   
7. Click OK. You should see the Linux desktop.

Back to top

Using virtual private networks

Virtual Private Networks (VPNs) rely on encryption to create an extension of a private network over the Internet. VPNs enable several network scenarios that are valuable to enterprises.

A traditional use of VPNs is to connect the local area networks of different offices of an enterprise into a wide area network. These types of connections are site-to-site. When VPNs were introduced for this purpose, they replaced the use of leased lines, greatly reducing cost for the enterprises.

Another traditional use of a VPN is to allow employees to access an enterprise's private network remotely; for example, to work from home. In this scenario, the enterprise provides a VPN gateway that is accessible from the Internet and the employee installs a VPN client that he installs on his laptop to access applications, such as email. This is termed a mobile virtual private network because one of the end points (where the employee is located) does not have a fixed IP address.

When a client sends a packet through a VPN gateway, an authentication header is added, the data is encrypted, and the data is placed in an Encapsulating Security Payload. The receiving VPN server decrypts the data and routes the packet to the destination according to information in the header.

The encryption provided by VPNs is at a low level so that all communication to the enterprise is encrypted. This can be at either OSI Layer 2 (data link layer) or Layer 3 (network layer) and can include any of these methods:

• IPsec
• SSL /TLS
• Datagram Transport Layer Security (Cisco)
• Microsoft Point-to-Point encryption
• SSH tunneling

VPNs can use bridging to create a virtual wide area Ethernet LAN. This has some advantages over using routing because it can work with any protocol that can work over Ethernet. Bridging is needed if you are using non-IP protocols or Windows file sharing. However, setting up a VPN with routing can be easier and allow finer control over access to specific hosts and ports.

Many enterprises may want to use cloud computing to extend the capacity of their IT infrastructure. To support this scenario, the VPN is configured via a gateway in the enterprise network to a private VLAN in the cloud. This is termed a site-to-site connection. The virtual machines on the cloud private network are not visible from the Internet but can only be accessed either via the VPN or via another virtual machine on the VLAN. This is illustrated in Figure 9.

In this scenario the cloud acts as an extension of the enterprise network. The extension in the cloud is isolated from the Internet and from virtual machines in the cloud outside the VLAN. IBM SmartCloud Enterprise supports this scenario as a fundamental offering. Unlike the work from home scenario, the employee does not have to do any special installation of a VPN client.

You can also support a network scenario that uses the cloud to support a VPN without needing an enterprise to own an on-premise VPN gateway. For example, the CohesiveFT VPN-Cubed images in the IBM SmartCloud Enterprise catalog can provide a VPN gateway. This can support employees working from home with a VPN client, such as the OpenVPN client. See Figure 10.

OpenVPN is an open source VPN client and server solution that can manage point-to-point and site-to-site connections. It uses the OpenSSL encryption library. The OpenVPN install image can be downloaded from the OpenVPN website. It includes both client and server software and must be installed on both client and server machines. You can install using the RPM package on RHEL machines and using the apt-get command on SUSE or other Debian-based systems. It is possible to install on other Linux systems from the tarball using make. There is a self-extracting installer for Windows and also client-only install images that you can direct end-users to.

The VPN-Cubed solution is a commercial software package from Cohesive FT that is available on IBM SmartCloud Enterprise. It can support many network configurations that are useful to create more complex virtual network configurations within a cloud, and to connect computing resources over multiple clouds with a VPN. VPN-Cubed can act as a virtual router, virtual bridge, VPN concentrator, and firewall.

Back to top

Setting up OpenVPN

Setting up a VPN with OpenVPN involves setting up a public key infrastructure, including a certificate with a public key and a private key for each server and client and a certificate authority (CA) certificate to sign each of these certificates. By default VPN does mutual authentication of both server and client using these certificates. However, you can configure alternate authentication methods. It is also possible to set up an Open VPN server on a dynamic IP address.

Install and configure the OpenVPN server on RHEL5

1. Install OpenVPN server using yum:
   1. The OpenVPN package for RHEL5 is not in the standard repositories. As root, download the descriptions for the Fedora EPEL (Extra Packages for Enterprise Linux) repositories before you type yum install openvpn.

      # rpm -ivh http://download.fedora.redhat.com/pub/epel/5/x86_64/ epel-release-5-4.noarch.rpm

      
      

      Output:

      Retrieving http://download.fedora.redhat.com/pub/epel/5/x86_64/ epel-release-5-4.noarch.rpm warning: /var/tmp/rpm-xfer.wmJlYz: Header V3 DSA signature: NOKEY, key ID 217521 f6 Preparing... ########################################### [100%] 1:epel-release ########################################### [100%] [root@vhost0508 ~]#

      
      
   2. Install the OpenVPN package with the command # yum install openvpn.

      Output:

      Loaded plugins: security Repository rhel-server is listed more than once in the configuration Setting up Install Process Resolving Dependencies --> Running transaction check ...

      
      

   You should be able to see that the EPEL repositories provided the current (but officially still unstable) Release Candidate 9 of OpenVPN (Version 2.1) was successfully installed in the output. Yum also installs the dependent LZO libraries.

2. Configure the OpenVPN server. Execute the following commands as root.

   # mkdir -p /etc/openvpn # cp -R /usr/share/openvpn/easy-rsa/ /etc/openvpn/ # cd /etc/openvpn/easy-rsa/2.0/

   
   

   A list of scripts that help configure VPN is displayed. The key scripts are summarized as follows:

   • vars: Creates environment variables and sets the necessary script variables
   • build-ca: Creates CA certificate (interactive)
   • build-dh: Creates Diffie-Hellman files
   • build-key-server: Creates server private keys
   • build-key: Creates client private keys
3. Generate a master CA certificate/key, a server certificate/key, and certificates/keys for clients.
   1. Edit the vars script according to your environment. Here's an example:

      export KEY_COUNTRY="CN" export KEY_PROVINCE="Shanghai" export KEY_CITY="Shanghai" export KEY_ORG="IBM" export KEY_EMAIL="a.user@example.com"

      
      
   2. Generate CA certificate:

      # ./clean-all # source ./vars # ./build-ca

      
      

      Output:

      Generating a 1024 bit RSA private key .........................++++++ ...................++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [CN]: State or Province Name (full name) [Shanghai]: Locality Name (eg, city) [Shanghai]: Organization Name (eg, company) [IBM]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) [IBM CA]: Name []: Email Address [a.user@example.com]: #

      
      
   3. Generate the server private key:

      # ./build-key-server server

      
      

      Output:

      Generating a 1024 bit RSA private key .................................++++++ ....++++++ writing new private key to 'server.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. ... Certificate is to be certified until Sep 23 13:15:05 2021 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

      
      
   4. Generate the client private key:

      # ./build-key client1

      
      

      Output:

      Generating a 1024 bit RSA private key ....................++++++ .............++++++ writing new private key to 'client1.key' ----- ... Certificate is to be certified until Sep 23 13:16:57 2021 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

      
      
   5. Generate the Diffie-Hellman parameters:

      # ./build-dh

      
      

      Output:

      Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time .........+........................................................+.........

      
      
   6. Copy the server certificate to /etc/openvpn:

      # cd keys # cp server.crt server.csr server.key ca.crt ca.key dh1024.pem /etc/openvpn/

      
      
   7. Zip the client certificate:

      tar zcvf client1.vpn.key.tar ca.crt ca.key client1.crt client1.csr client1.key

      
      
   8. Configure the server. It is preferable to refer openvpn sample-config files to create openvpn config files. An example is shown here:

      # cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf /etc/openvpn/ # cd /etc/openvpn/ # vi server.conf

      
      

      Output:

      local 129.35.209.162 # Which local IP address should OpenVPN listen on port 1194 # proto udp dev tun ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem server 10.8.0.0 255.255.255.0 client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log log openvpn.log log-append openvpn.log verb 3 push "dhcp-option DNS 10.8.0.1" push "dhcp-option DNS 170.225.111.10" # see h) to get name server, push "dhcp-option DNS 170.225.111.10" # see h) to get name server push "dhcp-option DNS 170.224.55.203" # see h) to get name server

      
      
   9. Check that the DNS name resolution is configured properly:

      # vi /etc/resolv.conf

      
      

      Output:

      domain site2.compute.ihost.com nameserver 170.225.111.10 nameserver 170.225.111.11 nameserver 170.224.55.203

      
      
   10. Make sure port 1194 is open. Check that the firewall allows traffic on port 1194 or use these commands to open it:

       /sbin/iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT /sbin/iptables -A OUTPUT -o eth0 -p udp --dport 1194 -j ACCEPT /sbin/service iptables save /sbin/service iptables restart

       
       
   11. Start/stop/restart the openvpn service.

       Start the openvpn service:

       # service openvpn start

       
       

       Output:

       Starting openvpn: [ OK ]

       
       

       Stop the openvpn service:

       # service openvpn stop

       
       

       Output:

       Shutting down openvpn: [ OK ]

       
       

       Restart the openvpn service:

       # service openvpn restart

       
       

       Output:

       Shutting down openvpn: [ OK ] Starting openvpn: [ OK ]

       
       

At this point the OpenVPN server is installed, configured, and running. Now you need to configure a client to communicate with it.

Install and configure the OpenVPN client on RHEL5

1. Install the openvpn package. Repeat steps 1 and 2 of the previous instructions.
2. Copy over client1.key, client1.crt, and ca.crt from server to client1 machine:

   #cp /usr/share/doc/openvpn-2.1.4/sample-config-files/client.conf /etc/openvpn

   
   
3. Find sample-config-files/client.conf and edit it. Edit the "remote" directive to point to the hostname/IP address and port number of the OpenVPN server.

   Output:

   remote 129.35.209.162 1194 ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt cert /etc/openvpn/easy-rsa/2.0/keys/client1.crt key /etc/openvpn/easy-rsa/2.0/keys/client1.key

   
   
4. Start openvpn from source dir:

   ./openvpn sample-config-files/client.conf

   
   

Towards the end of startup, it should read "Initialization Sequence Completed."

Install and configure the OpenVPN client GUI on Windows

1. Download OpenVPN GUI from the OpenVPN website. Note: The versions of OpenVPN GUI and OpenVPN server should be the same.
2. Install OpenVPN GUI. Follow the instructions when you download the file.
3. Config OpenVPN:
   1. Copy the client certificates from the server:

      ca.crt ca.key client1.crt client1.csr client1.key

      
      
   2. Copy sample-config-files/client.conf to the directory of config under installation directory, edit it and rename it to client.ovpn (C:\Program Files\OpenVPN\config):

      129.35.209.162 1194 ca ca.crt cert client1.crt key client1.key

      
      
4. Restart OpenVPN through the GUI

Back to top

Setting up a proxy server

To set up a proxy server on Red Hat:

1. Provision a Red Hat 5.6 instance on RTP Data Center. The instance has both a public and private IP; by default, the private IP is inactive after provisioning.
   
   Figure 11. Setting up a proxy server
   
   
   
2. Run the following command to check current gateway information; the current gateway is 170.224.160.1.

   # /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 170.224.160.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 170.224.160.1 0.0.0.0 UG 0 0 0 eth0

   
   
3. To active the private IP address:

   # /sbin/ifup eth1

   
   
4. Run the following command again to check current gateway information. The current gateway is now 10.216.1.1.

   # /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.216.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 170.224.160.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 10.216.1.1 0.0.0.0 UG 0 0 0 eth1

   
   
5. Check again to see that the private IP is "Active" now.
   
   Figure 12. Private IP is now active
   
   
   
6. If you enable the private IP, the default gateway is changed and you cannot access the Internet any longer. To fix this issue, set public IP gateway as the first priority to be reachable from the Internet:

   [root@vhost0513 ~]# /sbin/route del default [root@vhost0513 ~]# /sbin/route add default gw 170.224.160.1 [root@vhost0513 ~]# /sbin/route add default gw 10.216.1.1 metric 1

   
   

Now, you can ping the Internet IP successfully.

The following steps should help you to set private IP as proxy server to access instances with private IP within the same subnet.

1. Run yum to install the proxy server squid. For SUSE, run zypper install squid.

   [root@vhost0513 ~]# yum install squid Loaded plugins: security Setting up Install Process Resolving Dependencies ... Complete!

   
   
2. Configure squid on /etc/squid/squid.conf to add the lines in bold:

   http_access allow localhost acl lan_users src 10.216.1.0/24 http_access allow lan_users http_access deny all

   
   
3. Start squid as shown:

   # /sbin/service squid start

   
   

   Now you can use openssh to access another instance with a private IP from the previous instance.

4. The last step is to export the proxy as shown:

   # export http_proxy=http://10.216.1.144:3128

   
   

You have completed configuration of the proxy.

Back to top

In conclusion

In this article, we've summarized the management of network layers in different cloud scenarios and shown you how network management tools in the cloud can benefit different business scenarios. We've also detailed the following tools which will be helpful to you to manage the delivery of cloud services over a network:

• Connecting to the VM (IP addresses)
• Managing virtualized networks
• Managing multiple individual IP addresses
• Using a firewall to protect multiple virtual machines
• Authenticating users and servers via SSH or PuTTY
  • Port forwarding
  • Creating and using the SSH tunnel
  • Command-line tunneling with OpenSSH
  • Tunneling with PuTTY
• Using virtual private networks
• Setting up OpenVPN
• Setting up a proxy server

Resources

Learn

• More resources from the topics mentioned in this article:
  • Deliver cloud network control to the user
  • Extend your corporate network with the IBM Cloud
  • OpenSSH documentation
  • Tunneling with SSH
  • SSH Port Forwarding
  • OpenVPN documentation
  • IBM SmartCloud Enterprise tip: Span virtual local area networks
  • Developing and Hosting Applications on the Cloud by Alex Amies, Harm Sluiman, Qiang Guo Tong, and Guo Ning Liu. Published by IBM Press.
  
  
• For more on how to perform tasks in the IBM Cloud, visit these resources:
  • Up and download files from a Windows instance.
  • Install IIS web server on Windows 2008 R2.
  • Create an IBM Cloud instance with the Linux command line.
  • Create an IBM Cloud instance with the Windows command line.
  • Extend your corporate network with the IBM Cloud.
  • High availability apps in the IBM Cloud.
  • Parameterize cloud images for custom instances on the fly.
  • Windows-targeted approaches to IBM Cloud provisioning.
  • Deploy products using rapid deployment service.
  • Integrate your authentication policy using a proxy.
  • Configure the Linux Logical Volume Manager.
  • Deploy a complex topology using a deployment utility tool.
  • Provision and configure an instance that spans a public and private VLAN.
  • Secure IBM Cloud access for Android devices.
  • Recover data in IBM SmartCloud Enterprise.
  • Secure virtual machine instances in the cloud.
  
  
• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• Find out how to access IBM SmartCloud Enterprise.
  
  

Get products and technologies

• See the product images available for IBM SmartCloud Enterprise.
  
  

Discuss

• Join a cloud computing group on developerWorks.
  
  
• Read all the great cloud blogs on developerWorks.
  
  
• Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
  
  

About the authors

Alex Amies is a senior software engineer in the IBM GTS Development Lab in the China development lab. He is currently an architect working on the design of the IBM SmartCloud Enterprise. Previously, he acted as an architect and a developer on cloud and security products in other groups within IBM.

Chun Feng Wu is an IBM Certified Solution Advisor and an IBM Certified Solution Architect for cloud computing. He worked on the IBM public cloud, SmartCloud Enterprise and now works on IBM managed cloud, SmartCloud Enterprise Plus.

Guang Cai Wang is an Advisory Software Engineer at IBM and works as one of the lead developers on the IBM SmartCloud Enterprise team.

Mihai Criveti is an IT Architect mainly focused on cloud computing and virtualization. His interests are cloud computing, virtualization, enterprise architecture, SOA, middleware, digital forensics, and UNIX systems.

Rate this article

Comments

Back to top

Table of contents

• How network tools facilitate in various scenarios
• Tools and the tasks they solve
• Connecting to the VM via IP addresses
• Managing virtualized networks
• Working with multiple IP addresses
• Using a firewall to protect multiple virtual machines
• Authenticating users and servers with SSH or PuTTY
• Using virtual private networks
• Setting up OpenVPN
• Setting up a proxy server
• In conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Buy: Rational Application Developer for WebSphere Software

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers