{"id":228,"date":"2014-01-09T16:56:19","date_gmt":"2014-01-09T16:56:19","guid":{"rendered":"http:\/\/blogs.nd.edu\/devops\/?p=228"},"modified":"2014-01-09T18:45:46","modified_gmt":"2014-01-09T18:45:46","slug":"tunneling-home","status":"publish","type":"post","link":"https:\/\/sites.nd.edu\/devops\/2014\/01\/09\/tunneling-home\/","title":{"rendered":"Tunneling Home"},"content":{"rendered":"

\"ShawshankRedempt_184Pyxurz\"<\/a><\/p>\n

So I have an EC2 instance sitting in a subnet in a VPC on Amazon. \u00a0Thanks to Puppet, It’s got a rails server, nginx, and an Oracle client. \u00a0But it’s got no one to talk to.<\/p>\n

It’s time to build a VPN tunnel to campus. \u00a0Many, many thanks go to Bob Richman, Bob Winding, Jaime Preciado-Beas, and Vincent Melody for banding together to work out what I’m about to describe.<\/p>\n

It turns out the AWS side of this configuration is not actually very difficult. Once traffic reaches us, there’s a lot more configuration to do! \u00a0Here’s a quick sketch:<\/p>\n

\n
<\/dt>\n
\"VPN-tunnel\"<\/a>IPs and subnets obscured<\/dd>\n<\/dl>\n

 <\/p>\n

You can see the VPC, subnet, and instance on the right. \u00a0The rectangle represents the routing table attached to my subnet. \u00a0Addresses in the same subnet as the instance get routed back inside the subnet. \u00a0Everything else (0.0.0.0\/0) goes to the internet gateway and out to the world.<\/p>\n

Configuring The Tunnel<\/h3>\n

To actually communicate with resources inside the Notre Dame firewall, such as our Banner databases, we need a few new resources. \u00a0These objects are pretty simple to create in software on AWS:<\/p>\n

    \n
  1. the virtual private gateway<\/strong>. This is basically a router that sits on the AWS side of the VPN tunnel we’ll create. \u00a0You attach it to the VPC, and then you’re done with that object.<\/li>\n
  2. the customer gateway<\/strong>. \u00a0When you create this object, you give it the public IP of a router on your network. \u00a0We’re using one that resides on the third floor of this building. \u00a0You need to configure this router to function as the VPN endpoint. \u00a0Fortunately, we have people like Bob Richman, who just know how to do that sort of thing. \u00a0If we didn’t, AWS provides a “download configuration” button that gives you a config file to apply to the router. \u00a0You can specify the manufacturer, type, and firmware level of the router so that it should be plug-and-play.<\/li>\n
  3. the VPN connection<\/strong>. This object bridges the two resources named above.<\/li>\n<\/ol>\n

    Setting up Routing<\/h3>\n

    Now we want certain traffic to flow over this connection to ND and back again. \u00a0Here’s where I start to pretend to know things about networking.<\/p>\n

      \n
    1. AWS routing table. \u00a0<\/strong>We need to set routes on the subnet to which our instance belongs, forwarding traffic intended for Notre Dame resources to the Virtual Private Gateway<\/strong> described above. \u00a0No problem. \u00a0We define the IP\/subnet ranges we want (example: the range for our Banner database service listeners), and route them to the VPG.<\/li>\n
    2. VPN Connection static routes.<\/strong>\u00a0 As I mentioned, this resource bridges the VPG and the Customer gateway on our side. \u00a0So it needs the same rules to be configured as static routes.<\/li>\n<\/ol>\n

      At this point, we are in business! \u00a0Kind of. \u00a0I can ping my EC2 instance from campus, but I can’t talk to Oracle from EC2.<\/p>\n

      Fun Times with DNS<\/h3>\n

      Getting to our development database from anywhere requires a bit of hoop-jumping. \u00a0For an end user like me, running a SQL client on my laptop, it typically goes like this:<\/p>\n

        \n
      1. I use LDAP to connect to an OID (Oracle Internet Directory) server, specifying the service name I want. \u00a0My ldap.ora file contains four different domain names: two in front of the firewall and two behind. \u00a0It fails over until it can reach one. \u00a0So it’s not super-intelligent, but no matter where I call from, one of them should work.<\/li>\n
      2. The OID server responds with the domain name of a RAC cluster machine that can respond to my request.<\/li>\n
      3. My request proceeds to the RAC cluster, which responds with the domain of a particular RAC node that can service the actual SQL query.<\/li>\n<\/ol>\n

        With a little help from Infosec, setting up ND firewall rules, we can connect to LDAP, we can connect to the RAC cluster, and we can even connect to the RAC node. \u00a0Via telnet, using IP addresses<\/strong>. Notice the reliance on DNS above? \u00a0This got us into a bit of a mess.<\/p>\n

        Essentially, it was necessary to set up special rules to allow my AWS VPN traffic to use the ND-side DNS servers. \u00a0I needed to edit my EC2 instance’s resolv.conf to use them. \u00a0We also ran into an issue where the RAC node resolved to a public IP instead of a private one. \u00a0This was apparently a bit of a hack during the original RAC setup, and firewall rules have been established to treat it like a private IP. \u00a0So again, special rules needed to be established to let me reach that IP over the VPN tunnel.<\/p>\n

        Success!<\/h3>\n

        After these rules were in place and routes added to the VPN to use them, viola! I am now able to make a Banner query from AWS. \u00a0This is a fantastic step forward for app development in the cloud. \u00a0It’s only one piece of the puzzle, but an important one, as it is inevitable that we will want to deploy services to AWS that talk to ND resources of one kind or another.<\/p>\n

        Our networking, infosec, and database guys will probably tell you that some cleanup ought to be done on our side re: network architecture. \u00a0There are some “interesting” exceptions in the way we have laid out these particular services and their attendant firewall configuration. \u00a0The special rules we created to get this working are not really scalable. \u00a0However, these challenges are surmountable, and worth examining as we move forward.<\/p>\n

        In the meantime, we have made a valuable proof-of-concept for cloud application development, and opened up opportunities for some things I have wanted to do, like measure network latency between AWS and ND. \u00a0Perhaps a topic for a future blog post!<\/p>\n

        Onward!<\/p>\n","protected":false},"excerpt":{"rendered":"

        So I have an EC2 instance sitting in a subnet in a VPC on Amazon. \u00a0Thanks to Puppet, It’s got a rails server, nginx, and an Oracle client. \u00a0But it’s got no one to talk to. It’s time to build … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1550,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-228","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/posts\/228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/users\/1550"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/comments?post=228"}],"version-history":[{"count":8,"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/posts\/228\/revisions"}],"predecessor-version":[{"id":252,"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/posts\/228\/revisions\/252"}],"wp:attachment":[{"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/media?parent=228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/categories?post=228"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.nd.edu\/devops\/wp-json\/wp\/v2\/tags?post=228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}