Mobycast

{{ show.title }}Trailer Bonus Episode {{ selectedEpisode.number }}
{{ selectedEpisode.title }}
|
{{ displaySpeed }}x
{{ selectedEpisode.title }}
By {{ selectedEpisode.author }}
Broadcast by

Summary

You may know that it is best practice to use private subnets for your cloud network. But, have you actually implemented them?

They can be challenging to setup, especially if you have an existing VPC. And using private subnets creates a new dilemma... how do you even connect to these resources?

Jon sometimes complains that Mobycast makes him eat his "security broccoli". Well, its time we add "networking cauliflower" to the mix to ensure that he (and you!) have a well-balanced cloud-native diet.

In this episode of Mobycast, we kick off a three-part series detailing step-by-step how to incorporate private subnets for your cloud network. After listening to these episodes, you'll be able to setup your VPC like a true networking ninja!

Show Notes

Support Mobycast
https://glow.fm/mobycast

Show Details

In this episode, we cover the following topics:
  • Subnet 101
    • Public subnets
      • Used for public facing resources which allow inbound connections from the public Internet
    • Private subnets
      • What are they?
        • Used for resources that should not be exposed to open Internet
        • Do not allow direct access from open Internet
        • Require use of network address translation (NAT) for egress-only Internet access
      • Why use private subnets?
        • Protect your cloud servers from script kiddies
        • Limit exposure
    • Security groups and routing tables allow resources on public subnets to communicate with private subnets
  • NAT (network address translation) deep dive
    • What is NAT?
      • Remaps one IP address space into another
        • Done by modifying network address information in IP header of packets while in transit across routing device
      • Tool to deal with IPv4 address exhaustion
        • Only need single public IP address for NAT, which hides entire private network behind it
      • Note: Actual role of NAT device is both address translation and port address translation
    • How does it work?
      • IP header consists of:
        • Source IP
        • Source port
        • Destination IP
        • Destination port
      • Routing device modifies IP address in packets
        • Outgoing packets (from private-to-public)
          • Source IP and port changed to NAT values
            • I.e. packets appear to originate from NAT (instead of private IP itself)
        • Incoming packets (public-to-private)
          • Dest IP and port changes to private values
      • For TCP/UDP
        • NAT keeps in memory table that maps traffic to private IPs
          • Table includes each active connection (particularly the destination address and port)
          • When reply comes back to router, uses table to determine private IP that reply should be forwarded to
          • Port numbers are changed so combination of IP and port on returned packet can be unambiguously mapped to corresponding private destination
          • Note: conversation to open Internet has to originate in private network!
            • This is because initial message establishes required information in translation table
  • How can a single computer have both public and private IP addresses?
    • A quick primer on IP addresses and network interface cards
      • MAC (media access control) address
        • Physical address
        • Unique ID assigned to NIC
      • IP address
        • Logical address
      • Network switches maintain Address Resolution Protocol (ARP) tables that map IP addresses to MAC addresses
        • ARP table used to know which MAC address to attach to packet
      • Single NIC can have multiple IP addresses
  • Alas, private subnets are less convenient than public subnets.
    • Instances on private subnet won't be publicly accessible, they can only be accessed from inside the network.
    • This leads to the problem of how to connect to an instance on a private subnet from a remote location?
      • Three broad categories of solutions:
        • Direct Connect
          • Dedicated network connection over private lines straight into AWS backbone
          • Requires network equipment on customer side
          • Cons:
            • Requires dedicated hardware
            • Expensive
            • Applicable only when you have an on-prem location that needs to be physically connected to VPC
        • Bastion host (jump host)
          • Public-facing server running SSH daemon
            • Once connected to bastion host, users can then ssh to machines on private subnet
          • Typically have a single instance on public subnet
            • Minimizes surface area to be protected
          • Cons:
            • Adds an extra layer of indirection
            • ssh key management is more complicated
            • SPOF
            • Security risk of protecting the bastion host
        • VPN (virtual private network)
          • Many different options, ranging in cost and equipment requirements
          • For both connecting on-prem location, as well as general remote user access
  • VPN
    • Available options
      • Managed VPN
        • Managed IPsec VPN connection over existing internet
        • Quick and usually simple method for making secure connection to VPC
        • Can be used as redundant link for Direct Connect
        • Supports static routes or BGP peering/routing
        • How to setup:
          • Designate an appliance to act as your customer gateway (usually the on-prem router)
          • Create VPN connection in AWS and download config file for your customer gateway
          • Configure customer gateway with config file
      • VPN CloudHub
        • Connect locations in hub and spoke manner using Virtual Private Gateway
        • Allows remote locations to communicate with each other via the hub (Virtual Private Gateway in AWS)
        • Each remote location uses Site-to-Site VPN connection to connect to hub
        • Reuses existing internet connection
        • Supports BGP routes to direct traffic
          • e.g. use MPLS first then CloudHub VPN as backup
        • How to setup:
          • Assign multiple Customer Gateways to a Virtual Private Gateway, each with their own BGP ASN and unique IP ranges
      • Third-party software VPN
        • You provide your own VPN endpoint/software
        • Use this option if you must manage both ends of VPN connection
        • How to setup:
          • Install VPN software via Marketplace appliance or on EC2 instance
    • TIL... AWS has increased the options
      • Managed VPN is now known as "AWS Site-to-Site VPN"
      • New option: "AWS Client VPN"
        • Fully managed, highly available software-only VPN
        • Supports OpenVPN-based clients
      • We'll discuss "AWS Client VPN" in-depth in a future episode
    • Our choice for this episode: let's setup a third-party software VPN solution
      • Rationale:
        • Not too much $$$
        • Pretty sophisticated solution that's easy to manage
Links
End Song
Zero Gravity by Roy England

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

What is Mobycast?

A Podcast About Cloud Native Software Development, AWS, and Distributed Systems