Every few years the technology punditry anoints a new buzzword to rule them all. In the last ten years we’ve seen mobile, social, Web 2.0, location-based services, and others lay claim to the mantle. Some have stood the test of time. Most haven’t. One idea, however, has managed to weather the vicissitudes of the buzzword sea—cloud computing.
At its core, cloud computing simply means running one’s computing processes in someone else’s physical infrastructure. Over the last decade this concept has seen many incarnations. In the early 2000s Larry Ellison (the CEO of Oracle) proclaimed that all user data would live in the cloud and that our computers would be little more than dumb terminals to get to the Web. He called this network computing. Of course, Larry’s vision never completely materialized, but aspects of it are very much present in our lives today.
Take email, for example. A growing number of users are getting email from virtual providers like Gmail and Hotmail. These are cloud services (sometimes referred to as Application Service Providers, or ASPs). Another great example of the migration to the cloud is Google Calendar and Google Docs. Both services store our data in the cloud for consumption from whatever PC we happen to be in front of.
Services like DropBox let us store and share files in the cloud, while Microsoft’s Office for the Web lets us move our entire Word, Excel, PowerPoint, and Outlook experience to the cloud.
YouTube, Vimeo, Hulu, and Netflix allow us to get our video entertainment from the cloud, while Pandora, Zune, Rhapsody, Spotify, and others do the same for music. Apple’s iCloud, Google’s Play, and Amazon Music even let us store our personal music libraries in the cloud for streaming anywhere and anytime.
These are all wonderful services that make life a lot easier for millions of people—your author included.
There are also services wherein a company’s entire IT infrastructure is configured and run in the cloud. These are great options for new companies that don’t want to spend a lot of money on new hardware or a dedicated IT staff. Not surprisingly, however, these services tend to force organizations to select from a fairly rigid menu of options—rather than letting the organization tailor services specifically to their needs. This creates an unfortunate trade-off between ease of use and administration on the one hand and breadth of reconfigurability on the other.
In a perfect world, however, there would be a place in the cloud where someone like you (and me, for that matter) could go to install and completely configure your own IT setup and run it for a few hundred dollars a month.
There is, and I’m going to show you exactly how to do it!
This book is for you do-it-yourself types who think standing up your own IT infrastructure in the cloud would be cool and don’t want to be artificially limited by the constraints of an all-in-one provider.
Installing software doesn’t scare you.
Editing the Windows registry doesn’t make you break out in hives.
You don’t need to be an IT expert by any stretch to get the most from this book, but before we go any further I should call out some of the things I expect you’ll at least have heard of before reading on.
It’s the thing that assigns network settings to your computer so you don’t have to do it by hand.
It’s how a human-friendly name like www.amazon.com is translated into a machine-friendly IP address.
A group of related computing resources on your network.
Keeps tracks of all your users and computing assets in a Windows domain.
If this is the first time you’ve ever heard of one or more of these terms, then this book may be a smidgen advanced for you. If, on the other hand, each of these terms at least rings a bell, then you’re good to go.
So limber up those typing and clicking fingers because we’re about to build us a gen-u-ine corporate IT infrastructure in the cloud. We’re going to do it right, and best of all, we’re going to do it inexpensively.
Before we jump in, though, I’d like to take a moment to introduce you to the most powerful set of cloud services on the Net today: Amazon Web Services.
I don’t think it will come as any surprise to you that Amazon runs some of the largest and most sophisticated data centers and data clouds ever constructed. You may even know that Amazon provides scalable development infrastructures for people wanting to write high-transaction and highly fault-tolerant software systems. What you may not know is that Amazon also provides a complete set of IT tools for organizations that want to create dedicated virtual clouds while retaining complete configuration control over their environments. These services—both developer and IT—are collectively known as Amazon Web Services.
As of the time of this writing (Amazon is adding new services all the time) the following is a list of the services Amazon offers to people.
Allows a user to define a template of machine and service configurations that can then be instantiated with a single click. This template can include other Amazon services like EC2, VPC, Elastic Beanstalk, and others. Think of this service as a means of replicating a complicated IT and application infrastructure in just a few clicks.
A content delivery platform that scales to meet large simultaneous demands—great for distributing widely consumed digital goods like music and video.
Enables you to collect, view, and analyze metrics related to your cloud resources. It’s very helpful as your virtual infrastructure grows more complicated.
If you are at all familiar with databases, you have probably been using relational database systems like Oracle or SQL Server. Over the last several years a new class of database system has emerged, generally referred to as NoSQL systems owing to the fact that they do not use SQL as their principal query language. These systems are popular for very large data sets that have to scale horizontally automatically. The downside is that they are often limited in the kinds of queries that can be performed against the data they hold. The Amazon DynamoDB service provides an infinitely scalable NoSQL system to programmers.
Amazon EC2 is a service you’ll be making heavy use of in this book. It’s the service that lets you stand up and manage multiple virtual servers and will form the backbone of the virtual network we will build.
Sometimes a developer needs to store a large amount of data in memory but does not need to commit it permanently to a database system. This typically happens in high-transaction-volume applications. For this use there is Amazon’s ElastiCache service, which provides highly scalable in-memory storage for large but transient data sets.
For developers who don’t want to worry about standing up the various Amazon service components they might need for their application, there is Elastic Beanstalk. Basically, Elastic Beanstalk is a programming framework that handles all the administration of your various needed services for you. You just write your application using the Beanstalk components, and it will worry about which services to provision on your behalf and how to scale them.
Storing large data sets in the cloud is one thing. Analyzing them for hidden meaning is something else entirely. This is where Amazon Elastic MapReduce (EMR) comes in. It is a service that helps you slice and dice the various data sets you have stored in any of the Amazon data storage services. If you’re going to need to do serious analysis on data that you will be continuously collecting, then this is the service for you!
Amazon IAM is the framework under which you manage users who will have access to components of your Amazon services. For example, suppose you want to give one user access to a server instance you have set up using EC2 and another user administrative access to some data you have stored in DynamoDB. This is the service with which you would define those permissions. This book won’t make use of this service, as you’ll handle access control via the normal domain-credentialing system of Windows Server.
If you’re not quite ready to jump on board the NoSQL bandwagon, then the Amazon RDS should make you feel right at home. It’s a scalable managed database system using the SQL query language and tools with which any experienced database administrator should be familiar.
This is Amazon’s scalable DNS system. Rather than setting up DNS names for machines using the tools of your domain provider (the people with whom you registered your domain name), you’ll maintain your DNS zones and subzones using Route 53.
If you think you will need to send bulk email messages, then this is the service for you. Rather than setting up your own outbound email servers, you can use this service to do all the heavy lifting.
SNS allows developers and administrators to send out email and SMS alerts. Since you’re going to configure your own email gateway, you’re not going to make much use of this. But if you’re a developer considering using the Amazon cloud for your application, this is a great way to integrate notifications without having to worry about the particulars of various SMS and email platforms and gateways.
Sometime developers will want different applications (or application components) to pass information among themselves. One of the best ways to do this is with a message queuing system. This service isn’t covered in this book, but if you are planning on writing a distributed application, then you will definitely want to check this out.
Think of this as your very own DropBox or other Internet file storage system. This is a great way to securely store vital information in a way that conforms to your enterprise security policies. It’s also a really handy place to keep periodic backups of your production systems. You’ll be making heavy use of this service later in the book, for backup and restore scenarios in the cloud.
Highly distributed systems (like SETI) divide large problems into smaller work units called tasks. SWF is a service that lets application components set up, schedule, and manage the tasks specific to your large distributed process.
The Amazon Storage Gateway service is a really handy tool that lets you set up storage managed by Amazon that connects via the Internet to an appliance or PC sitting in your physical infrastructure. It’s a fabulous way to do backups, disaster recovery, and archiving.
This service will be the backbone of this book and of your virtual IT infrastructure. In a nutshell, it allows you to collect server instances running on the Amazon EC2 service into a single (or segmented) virtual network. This means you can have your virtual domain controller talking to your virtual email server as if they were attached to the same bit of Ethernet—even though they may be across town from one another. I’ll be spending a lot of time on this topic as we move along.
Now that the introductions are out of the way, let’s talk about how you’re going to use these services to build your new IT infrastructure.
For the purposes of this book, I am going to walk you through installing the following list of IT services in your own network. There are countless others you can add, of course, but these are the ones I think are key to any true enterprise infrastructure.
A Primary Domain Controller (PDC)
An email server
A chat server
A voice over IP (VoIP) PBX
A secure VPN infrastructure
An automatic backup and restore process
In short, you want a completely functional IT system for immediate use.
To achieve this you will use the following five Amazon services:
By the time you are done with this book you will have a fully functioning IT infrastructure that you can run for less than $300 per month.
The 13 or so other services described earlier are really for any software developers you might have in your organization. There are some really great O’Reilly books that cater to people wanting to write scalable custom applications. This book, however, is not that. This is about the nuts and bolts of configuring an IT system that you can begin using immediately.
Before we go any further I’m going to assume that you have already signed up for a free Amazon Web Services account. If you haven’t, please visit http://console.aws.amazon.com and create yourself a new account. If you already have a regular Amazon consumer account, this process will take no more than 30 seconds.
For the sake of this book I’m going to assume that you want to have
a public-facing domain name (à la
MyCompany.com). The first
step in getting this is to pick a name not already in use and register it
with a domain registrar.
A domain registrar is a company authorized by ICANN (Internet Corporation for Assigned Names and Numbers—the body that governs domain names for the Internet) to register and reserve domain names. Usually, each registrar is limited to specific top-level domains (TLDs) that are often restricted by country. For example, US-based registrars are usually limited to .com, .edu, .org, .gov, .us, .info, .co, and .me domains. A registrar in the UK might be limited to .co.uk or other UK-specific domains.
For the sake of our work here, I’m going to register the domain DKRDomain.com. Since DKR are my initials (David K. Rensin) I’m not likely to forget it!
You can use any registrar you want to reserve your domain. In my case, I used the cheapest one I could find—godaddy.com. It was a 2-minute process and cost me $10 for the year.
The next thing I want to do is to have an AWS service named Amazon Route 53 manage the DNS for my new domain. Route 53 is a complete DNS solution provided by Amazon that lets you control every aspect of the name resolution process for your domain.
By default, your registrar will want to manage all the DNSs for your domain.
That’s no good.
Legitimate control freaks like me want to do it themselves. I need to tell the people I used to register my new domain to take a hike and let Route 53 do it for me. This way I have complete control over things.
To do likewise, first you need to go to the Route 53 page in the AWS online console. The URL for that is https://console.aws.amazon.com/route53/home. Since you already have a domain, you want to click the “Migrate an existing domain to Amazon Route 53” link. The steps to perform the migration are pretty straightforward.
Create a new hosted zone.
Go to the record sets.
Write down the values for the NS (name server) record set.
Go to the provider where you registered your domain and edit the zone file (or DNS server information) to match the values you just wrote down.
In my particular case, the correct screen on the http://www.godaddy.com site looks like this:
You can confirm that your new DNS zone info is correct via a number of websites. Please keep in mind that it can take as long as 24 hours for the new information to make its way around the Internet, but in practice it usually takes only 5 to 10 minutes.
A simple and free site for DNS checking is http://network-tools.com/nslook/. All you have to do is fill in your new domain name and set the record type to NS (Name Server).
Now, whenever you want to add a new host to your domain (for example www.dkrdomain.com) all you have to do is go to the Route 53 page and add an A Record to your domain that maps your hostname (www.dkrdomain.com) to a specific IP address (18.104.22.168).
Before you can do anything interesting with either VPCs or EC2 instances, you must first set up at least one set of security credentials—known as a key pair. From the main Amazon management console, select the EC2 tab at the top. On the left-hand side of the screen, click the Key Pairs link near the bottom. Since there will almost certainly not be any key pairs already generated for you, select the button from the top of the screen. Give your new key pair a name (I used DKR-EC2 since it was the key pair for my EC2 work—I strongly suggest that you follow a similarly consistent convention for yourself). When you click the Create button, the key pair file (it will end in the extension .pem) will automatically be downloaded to your computer.
Save this key pair file someplace safe, where you know you can find it again. It will be absolutely vital to just about everything you do in the rest of this book!
As I mentioned before, the virtual IT infrastructure we’re going to set up will exist in its own private virtual network, or VPC. It follows, thusly, that the first thing you want to do is to create your new VPC. To do this, log in to the Amazon AWS Management Console (https://console.aws.amazon.com) and select the VPC tab. You will be greeted with a screen that looks like this:
Click the “Get started creating a VPC” button.
AWS allows you to create some very complicated virtual infrastructures that include support for multiple subnets, hardware VPN connections to a data center, and mixed public/private subnets. For now, select the first option: VPC with a Single Public Subnet Only. This topology will do fine as long as you’re appropriately security conscious.
On the next screen leave the defaults as they are, and click Create VPC. Once Amazon is done creating your new VPC, click the Close button. You VPC console page should now look like this:
Now that you have a new virtual network, take a look at just what Amazon has created for you.
There is, of course, one instance of a basic VPC shell.
Amazon created a default network access control list (ACL) for you. This is where you can modify firewall rules for specific virtual network interfaces. In truth, you will almost never touch these rules and should therefore leave them as is.
Since you want your new network to connect to the Internet, AWS has helpfully created a default Internet gateway.
You have two routing tables: one for traffic to and from the Internet and another for routing packets among machines in the network.
Finally, AWS created a default security group. Security groups are a great way to partition machines from one another and limit the sort of intermachine traffic you allow. The default group that has been set up says it will allow any traffic among machines in that group but deny any traffic for anyone else. This is a good first rule to have, so you should leave it be.
The last thing you want to do is to set up a single, public-facing IP address for your new VPC. While still in the VPC tab, select the Elastic IPs link on the left-hand side of the page. On the top of the page, click the button. The following screen should appear:
Please note that this new public-facing IP address is not yet attached to any specific machine in your virtual infrastructure. You’ll get to that a little further along.
So now that you have your virtual environment configured, it’s time to set up your first server. You might think that—as is common in a Windows-based network—the domain controller would be the first machine you would want to configure, but that turns out to be not so. The first server you want to get running is actually the VPN server.
Why, you ask?
The answer is actually pretty simple. If you design security into your new infrastructure right from the beginning, you will be a lot less likely to be plugging holes later on. In this case, you want to limit all communications with the new environment and the outside world to a single secure channel. Eventually you’ll open other services like Web and email, but while you’re busy configuring things, the safest path to follow is one where everything is done via a VPN.
There are basically two types of VPN solutions in the world—IPsec and Secure Sockets Layer (SSL). As you might imagine, each solution has its pros and cons.
Most popular VPN solutions, like those from Cisco, are based on IPsec and are in very broad use. IT managers have a lot of experience with these kinds of VPNs, and most firewalls and routers support them. They do, however, have a couple of important downsides. First, they are almost always based on the User Datagram Protocol (UDP), versus TCP, and can have real problems getting through firewalls that use Network Address Translation (NAT). NATed infrastructures are extremely common in hotel WiFi configurations and can cause serious headaches when you’re trying to dial back to your office.
The other serious drawback to IPsec VPNs is that there isn’t any good free or open source server software for them. There are plenty of free clients, but if you want to set up a server in your infrastructure to actually enable the VPN connection, then you can expect to pay anywhere from a few hundred dollars to several thousand dollars for the privilege.
Before you fire up your email to send me a nastygram about how Windows Server 2008 can, in fact, be configured as an IPsec VPN server, I would like to point out the following facts:
Both the Layer 2 Tunneling Protocol (L2TP) and Point-to-Point Tunneling Protocol (PPTP) network types that you could configure are generally regarded as being not safe.
The other option—Secure Socket Tunneling Protocol (SSTP)—is certainly safe enough, but almost no clients support it on a non-Windows platform. That means no Mac, Android, or iOS.
SSL VPNs are newer to the security market than their IPsec brethren. Almost no operating systems natively support them, which means you will always need to install a client on the device you want to use to make the connection. On the other hand, there are some really great free implementations you can use in your infrastructure. In addition, SSL VPNs can be configured to run via TCP (instead of UDP) and will always work in NATed network environments. This is precisely how you’re going to set up your VPN.
All things being equal, I’m going to use an SSL VPN named OpenVPN to set up a secure channel in the example network. You can read more about OpenVPN at the OpenVPN main site.
One fantastic aspect of the Amazon Web Services is that many people have already done really interesting and difficult things using them. If, for example, we were going to set up a VPN server in our physically local space we would have to
Buy a PC.
Install an operating system.
Install and configure the VPN server software.
In the Amazon cloud, however, you can really shorten this process. For most common tasks—including setting up a VPN server—it is highly likely that someone has already done it and saved a snapshot of their running instance as an Amazon Machine Instance (AMI). That means if someone has already saved an OpenVPN AMI, for example, then you don’t have to do anything more than create a new server instance in the cloud based on that AMI and tailor its configuration to your liking. That reduces a multihour process to less than 30 minutes.
Step 1 in the process is to find an appropriate AMI and launch it into your VPC. From the EC2 part of your management console, select Launch Instance.
In the window that pops up, select Quick Launch Wizard → More Amazon Machine Images, and name the new instance something useful like Gateway. Then select Continue.
On the next screen, type
DKR in the search
window, pick the DKR OpenVPN Server instance type, and click Continue.
As you might have guessed from the AMI name, I’ve already built you a
stock VPN server and made it available publicly.
The summary screen that appears shows the basic details of the instance you’re about to launch. Notice that the item labeled Launch into a VPC is set to No. You want to change that.
Click the “Edit details” button and check the box on the next screen marked Launch into a VPC.
If you had more than one VPC to choose from, you could select it from the Subnet drop-down.
The type of instance currently configured for this AMI is a t1.micro. This is the smallest computing instance available in AWS. Unfortunately, you cannot launch a t1.micro instance into a VPC, so you need to select the next smallest unit—m1.small—from the Type drop-down list.
Select the Security Settings section and make sure that only the default security group is selected.
Click “Save details.”
Now you can launch the new instance by clicking the Launch button.
If all goes well, you should be greeted with a success message like the following:
New Windows instances can take upwards of 15 minutes to boot and be ready to use. Please wait until you see in the Instances section of the EC2 tab that your new instance is ready to go and that both of the status checks are green.
Before we can connect to your new server for the first time, you have to do two things:
Attach your external IP address to the server.
Enable use of the Remote Desktop Protocol (RDP).
First, establish a route from the Internet to your newly minted VPN server. In the AWS Management Console, select the VPC tab. On the left-hand side, click the Elastic IPs link. Now right-click the Elastic IP (EIP) you set up earlier and choose Associate. You should see the following:
Now select the instance you just created from the drop-down and click Yes, Associate.
The next thing you have to do is modify your default security rules to allow traffic on the standard RDP port: 3389.
Still on the VPC tab, click the link on the left-hand side labeled Security Groups. Now select the default group. Your browser should look like this:
Click the Inbound tab at the bottom of the screen and then click the drop-down. Next, scroll to the bottom and select RDP. Now click the Add Rule button and the Apply Rule Changes button. Your screen should look similar to this:
What you’ve done is to allow RDP packets to flow into your newly created server.
To access the new VPN server for the first time you will need an RDP client for your computer. If you’re on a Windows machine, then you already have one built in (mstsc.exe). On the Mac I recommend downloading the Remote Desktop Connection client for Mac OS X from the Microsoft web page.
Next, you need to open a remote desktop to the new machine and
perform some configuration. First, open your RDP client and enter in the
server field the public IP address that you were given when you created
your elastic IP for the VPC. Next, click the Connect button. You will be
prompted for a username and password. Use the username
Administrator and the password
passw0rd!. Click the Connect button, and in a few
moments you should have a remote desktop on the VPN instance.
The very first thing you must do is change the password for the Administrator account. You can do this from the Control Panel applet as you would normally do on a Windows machine. I cannot stress this enough. Every person reading this book and using that AMI will have the same initial password, so be sure to change it straight away.
Now, let’s chat for a few paragraphs about how the VPN server works.
If you’ve ever used a VPN before, you’re probably used to having to remember a username and password combination to authenticate. That’s one way to set up a VPN. The other way to do it is to issue certificates for each user who will need to connect. The certificate acts as your password and keeps you from having to remember any extra information. The downside, of course, is that you must have your certificate on whichever machine you want to connect from.
Although the OpenVPN software can be configured to operate in either mode, I’ve configured the example’s instance to use certificates instead of passwords.
To use this VPN you’ll need to create your own client certificates for every user you want to allow to connect.
In any system that uses certificates, those certificates are stored in a place known as the keystore. OpenVPN is no different. Here are the steps to create your own client certificate so you can start using the VPN.
Still on the remote instance machine, open a Windows command
prompt and type
cd "\Program Files
build-key.bat client. This
starts a process that builds a client certificate. You don’t have
to use the name client. You can use
build-key.bat myCert or some other name. Just
make sure to remember what you used!
Answer the questions that are put to you.
How you answer the questions is pretty much irrelevant except for when you get asked for the common name. That value must be unique among your certificates, or you won’t be able to successfully store your certificate in the keystore.
Answer any yes or no questions
Congratulations! You now have a brand-spanking-new
certificate named client.crt. This file is located
keys subdirectory. In that directory, the three
files you will need to make your client connection work are
ca.crt, client.crt, and
client.key. Keep in mind that you want the
.crt and .key files that match
the name you used when you ran
You already know that you will need copies of the three certificate files from above on your local computer. How you get them there is really a matter of personal preference.
The easiest way is to go into the preferences section of your RDP client and tell it that you want to share drives. When you do this, the drives from your local machine will show up under My Computer on the VPN server. You can just copy the files directly.
You can also use a file-sharing service like DropBox to transfer the files.
If you have a Web email account like Gmail, then you can just email the files to yourself from the VPN box.
Once you have the certificate files on your local machine, you will need to install an OpenVPN client application on your computer. If you’re on a Windows machine, you can download the installer from the OpenVPN site directly. If you’re using a Mac, then I would recommend using a program called Tunnelblick. In either case, be sure to have the manual handy for this next step.
The last step in getting set up is to put the certificate files in the place specified in the client docs and to create a connection configuration file. In the directory specified by the client software user manual, create a file named MyConnection.ovpn. There are tons of options for OpenVPN, but in this case you will need to paste only the following into the file.
# This is a client profile. client # We want to tunnel packets (rather than Ethernet bridging). dev tun # Use TCP instead of UDP. proto tcp # This is the VPN server we're connecting to. # Be sure to change this value to YOUR Elastic IP address. remote vpn.dkrdomain.com 443 # These are the crypto certificates we'll be using. ca ca.crt cert client.crt key client.key # Use LZO compression on the channel. comp-lzo
The only thing you need to change from this listing is the
hostname that is italicized; that needs to be the IP address of your
Elastic IP. You might potentially need to change the name of the
.key and .crt files, too, if
you used a name other than client when you ran
build-key.bat. Other than that you’re ready to go!
Make sure that the .ovpn configuration file you just created is in the same place as the three certificate files you got earlier. Consult the help for your particular client to find out where that should be. As long as they are all colocated, everything should work on the first go.
Before we can connect for the first time we have a little more housekeeping to take care of.
The VPN is set up to communicate over the standard SSL port (443),
so we need to make sure that our default security rule allows incoming
traffic on that port. As before, click the Security Groups link on the
left side of the VPC tab. Highlight the default rule, click the Inbound
tab at the bottom of the screen, enter the value
443 for the port, click Add Rule, and then Apply
You should now see that a new rule allowing incoming traffic on port 443 (HTTPS) is part of the default security group.
While you’re there, you should delete the rule allowing RDP traffic, since we want to allow any communication with the infrastructure to occur only through the VPN channel on port 443.
Now it’s time to test our VPN connection!
2012-04-07 11:51:12 Attempting to establish TCP connection with [AF_INET]22.214.171.124:443 [nonblock] 2012-04-07 11:51:12 MANAGEMENT: >STATE:1333813872,TCP_CONNECT,,, 2012-04-07 11:51:13 TCP connection established with [AF_INET]126.96.36.199:443 2012-04-07 11:51:13 TCPv4_CLIENT link local: [undef] 2012-04-07 11:51:13 TCPv4_CLIENT link remote: [AF_INET]188.8.131.52:443 2012-04-07 11:51:13 MANAGEMENT: >STATE:1333813873,WAIT,,, 2012-04-07 11:51:13 MANAGEMENT: >STATE:1333813873,AUTH,,, 2012-04-07 11:51:13 TLS: Initial packet from [AF_INET]184.108.40.206:443, sid=ab1e047f de8e819b 2012-04-07 11:51:14 VERIFY OK: depth=1, C=US, ST=VA, L=Haymarket, O=DKRDomain, OU=IT, CN=DKRDomain, name=Dave Rensin, emailAddressfirstname.lastname@example.org 2012-04-07 11:51:14 VERIFY OK: depth=0, C=US, ST=VA, L=Haymarket, O=DKRDomain, OU=IT, CN=DKRDomain, name=Dave Rensin, emailAddressemail@example.com 2012-04-07 11:51:15 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 2012-04-07 11:51:15 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 2012-04-07 11:51:15 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key 2012-04-07 11:51:15 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 2012-04-07 11:51:15 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA 2012-04-07 11:51:15 [DKRDomain] Peer Connection Initiated with [AF_INET]220.127.116.11:443 2012-04-07 11:51:16 MANAGEMENT: >STATE:1333813876,GET_CONFIG,,, 2012-04-07 11:51:17 SENT CONTROL [DKRDomain]: 'PUSH_REQUEST' (status=1) 2012-04-07 11:51:17 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' 2012-04-07 11:51:17 OPTIONS IMPORT: timers and/or timeouts modified 2012-04-07 11:51:17 OPTIONS IMPORT: --ifconfig/up options modified 2012-04-07 11:51:17 OPTIONS IMPORT: route options modified 2012-04-07 11:51:17 ROUTE_GATEWAY 192.168.50.1/255.255.255.0 IFACE=en0 HWADDR=58:55:ca:f2:f4:df 2012-04-07 11:51:17 TUN/TAP device /dev/tun0 opened 2012-04-07 11:51:17 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 2012-04-07 11:51:17 MANAGEMENT: >STATE:1333813877,ASSIGN_IP,,10.8.0.6, 2012-04-07 11:51:17 /sbin/ifconfig tun0 delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address 2012-04-07 11:51:17 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure 2012-04-07 11:51:17 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up 2012-04-07 11:51:17 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw tun0 1500 1544 10.8.0.6 10.8.0.5 init 2012-04-07 11:51:19 *Tunnelblick client.up.tunnelblick.sh: No network configuration changes need to be made. 2012-04-07 11:51:19 *Tunnelblick client.up.tunnelblick.sh: Will NOT monitor for other network configuration changes. 2012-04-07 11:51:19 *Tunnelblick: Flushed the DNS cache 2012-04-07 11:51:19 MANAGEMENT: >STATE:1333813879,ADD_ROUTES,,, 2012-04-07 11:51:19 /sbin/route add -net 10.8.0.1 10.8.0.5 255.255.255.255 add net 10.8.0.1: gateway 10.8.0.5 2012-04-07 11:51:19 Initialization Sequence Completed 2012-04-07 11:51:19 MANAGEMENT: >STATE:1333813879,CONNECTED,SUCCESS,10.8.0.6,18.104.22.168
In this listing there are four important lines to look for. I’ve highlighted them to make it easier to spot them.
The first boldface line shows that there was a successful TCP connection between the VPN client software and the server you’ve just finished setting up. This tells you that the work you did assigning the Elastic IP is working correctly.
The next two boldface lines show that there was a successful exchange of cryptographic keys (the certificates) between the server and the client.
The final boldface line shows that the tunnel was successfully set up and that the client machine now has the IP address of 10.8.0.6.
To test that everything is working well, open up your RDP client and use the IP address of 10.8.0.1 for the server address and try to get a remote desktop connection to the VPN server.
If that works you’re all set!
The server is preconfigured to give your computer an IP address in the 10.8.0.x range. The server will always be reachable at the address 10.8.0.1 as long as the VPN connection is active.
From this point forward, whenever you want to do maintenance on any of the machines in your new VPC you will have to:
Establish a VPN connection.
RDP to 10.8.0.1.
Connect to the other instances in your VPC from there.
You’ll get the hang of this quickly enough in the next chapter.
You’ve just done some of the hardest stuff in the whole book. Your virtual private cloud is set up and you now have a rock-solid secure VPN connection with which to reach it. In the following chapters you’ll explore the details of setting up various IT services you’ll need (such as email, chat, and voice). For now, though, you should be content in the knowledge that you have accomplished in probably less than an hour what would normally have taken the better part of two days.
Next stop, Active Directory and the Primary Domain Controller!