Protect Your Network with Cloud NAT (Networking End to End)

Protect Your Network with Cloud NAT (Networking End to End)


STEPHANIE WONG: As
a Cloud Developer, one realization
you quickly have is that despite being
on the cloud, you don’t want everything
publicly accessible. In this episode of
Cloud Networking, we cover how to protect
your internal endpoints using Cloud NAT. Stay tuned. Let’s say you’ve got
a cloud application with internal
services and you want to restrict inbound
communication while still allowing outbound. One of the traditional
ways to do this would be through a VPN service
that secures, authorizes, and handles that connection
for you, which is fine but runs into a large problem
that you’re still using public IPs,
which leaves you vulnerable to malicious actors. Another secure setup
would be something called a bastion host– basically an external endpoint
which allows your clients to SSH from the public
internet and still keep your apps from being
public-facing, which, again, works, but this
only deals with one side of the problem. Namely, inbound communication. But let’s say you have a
multi-tiered application setup in the cloud and you have
an update server on premise. You want to allow your
instances outbound access to the internet for
updates, patching, config management, and more
without having an external IP address. That way, you can
keep your instances entirely internet-facing in
a controlled and efficient manner. For this, it makes
a lot more sense to setup a Network
Address Translation, NAT, gateway machine, which routes
traffic and lets multiple VMs in a subnet reach the internet
using a single public IP address. Now, normally, this
requires a fair bit of toil. Building a high availability
and high bandwidth NAT gateway usually requires reserving
static IP addresses, creating compute instance
groups as the NAT gateways, creating health checks to
monitor their responsiveness, and adding default routes
to these instances. And with traditional NATs,
you’d have a NAT proxy instance between
your cloud instances and their destination. This means a potential
choke point in the path, undermining performance,
throughput, and availability. Fortunately, Google Cloud NAT
is a software-defined networking SDN solution that
avoids these problems. It’s a fully managed offering
that lets Google Cloud VM instances without
external IP addresses and private GKE clusters
connect to the internet. It doesn’t require custom
routing and simplifies and delivers scale,
because it uses SDN instead of being an
instance or an appliance that you have to manage. And better yet,
outside resources can’t directly access any of the
private instances behind Cloud NAT, thereby helping to keep
your VPCs isolated and secure. The best part? It doesn’t use a proxy. Instead, each of your
internal instances is given a unique set of
NAT IPs and port ranges, which are used by Andromeda,
Google’s network virtualization stack, to perform that. This means no choke
points, better scalability, performance, and availability. Cloud NAT scales seamlessly
with the number of instances and the volume of
network traffic. And you get as much bandwidth
as instances that do have external IP addresses. Let’s dive into how
to set up Cloud NAT. Here I have two VMs set up
in the same VPC and subnet. I want web server to be
private, so I’ve set it up with no external IP address. In order to access it,
I’ve set up a second VM to act as a bastion host,
which does have an external IP and allows for inbound
traffic to my web server. I’ve also set up
firewall rules so that I can only use the bastion
host to SSH into the web server. I’m using the local terminal
to SSH into the bastion host to then SSH into the web server. You can see here I
don’t have the ability to access the public
internet, because when I try to pull content from
example.com, it hangs. Now, let’s set up Cloud
NAT to route egress traffic from the web server to the
internet using Cloud NAT’s allocation of IP addresses. Head to the Google Cloud NAT
page and click Get Started. Enter a gateway name. Choose the VPC network
your instances are in. Set the region for
the NAT gateway, which should be the same as
where your instances are. Now create a Cloud Router in
the region and give it a name. Leave the rest as
default. Leave the NAT IP addresses to automatic, which
is recommended and automatically allocates IP addresses
based on usage. These IPs are used to translate
the internal addresses of instances. And now click Create. Now, going back to my
web server instance, I can now access example.com and
see its content while it still has no external IP address. It’s important to note that
Cloud NAT doesn’t set up inbound NAT. So instances outside
your VPC can’t initiate their own new
connections to your cloud instances with NAT. But Cloud NAT is a
great managed service for things like fetching
periodic updates from an external server
and another network. As you grow your
cloud environment, centralizing control and
simplifying your network topology is going to save
you cycles in the long run. Stay tuned for the next episode. And remember,
optimizing your network means freeing up your bandwidth. [MUSIC PLAYING]

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *