GCP Networking tips (Road to Google Associate Cloud Engineer 2020 Certification)

Introduction

The GCP networking topic is quite large but, as in the previous articles about the certification, we can identify some specific subjects helping to cover a good portion of the questions we can find in the certification.

Knowing basic concepts around the Firewall rules, the subnet ranges, the VPC networking Peering, the Shared VPC, the Cloud VPN and Cloud Interconnect, allows to be ready to face and answer correctly many questions.

VPC and Firewall

When you create a Google Cloud Account, you get a Virtual Private Cloud (VPC) network with a subnet by default. The VPC provides the connectivity for the Compute Engine Virtual Machine, the Kubernetes clusters and for the App Engine flexible environment. It can also connects to on-premise networks and you can create multiple VPC in a single project.

VPC creation and Subnet

You have 2 modes to create a VPC network

• auto mode: it creates automatically a subnet in each region where the VPC is located. The IP ranges of the created subnets come from a predefined set of ranges.
• custom mode: you can create the subnets you want in the region of your choice.

One needed argument to deal with questions about VPC and networking is the CIDR ranges of the IP addresses. It’s important to be able to determine how many IP addresses are available for the hosts in a specific CIDR range and identify which CIDR range contains more addresses in a list of proposed notations.

First thing to keep in mind is that a range has 32 bits available for the addresses. Let’s consider the IP range 10.0.0.1/28. With this, 28 bits are used for the network ID. We have in this case 4 bits available for the hosts addresses. So, if a questions ask which of the following 2 ranges have more available IPs:

• 10.0.0.1/28
• 192.168.1.1/20

the second one is the right response because it will have 2^12 assignable IP addresses (because 32–20 = 12)

The supported internal IP Address ranges by the IETF (Internet Engineering task force) are:

1. 24-bit block 10.0.0.0/8 (16777216 IP Addresses)
2. 20-bit block 172.16.0.0/12 (1048576 IP Addresses)
3. 16-bit block 192.168.0.0/16 (65536 IP Addresses)

10.0.0.0/8 gives you the largest range — 16777216 IP Addresses.

Attention: The IP range 172.17.0.0/16 is reserved for the Docker bridge network. For example, any Cloud SQL instances created in a VPC with an IP in that range will be unreachable. Connections from any IP within that range to Cloud SQL instances using private IP will fail.

Another concept that is often present in certification questions is around expanding the IP range for an existent subnets belonging (or that belonged to) an auto mode network. In this case there is the risk of overlap the range with other subnets. When expanding the IP range of an automatically created subnet in an auto mode network (or in a custom mode network that was previously an auto mode network), the broadest prefix (subnet mask) you can use is /16.

Any prefix broader then /16 would conflict with the primary IP ranges of the other automatically created subnets. So, when creating 2 subnets inside the same VPC the CIDR ranges must be different.

However, for custom VPC networks using custom subnets it’s possible to use /8 CIDR.

So:

• Automatic created subnet => start from /16 address range
• Custom VPC with custom subnets => start from /8 address range

Firewall rules

You define how your network is accessed and how it interacts with the external world with the firewall rules that help you to protect the service you will deploy.

Basically you have 2 firewall rules when you create a VPC:

• all the ingress traffic (from outside to your network) is blocked
• all the egress traffic is allowed

These rules are valid also for the default VPC but they’re not explicitly listed in the cloud console. They are called “Implied rules”, they can’t be removed and they have the lowest priority (65536).

Priority in GCP is higher the lower the value is and it goes from 0 to 65536.

Priority is an important concept that you can find in several questions. The firewall rules are applied starting from the ones with highest priority (0) and they are immediately applied. Consider you have this rule:

• allow ingress traffic for protocol TCP on port 22 and priority 1000

since priority is higher (1000) than the implied rule denying the ingress traffic (priority 65536), the TCP traffic on that port will be allowed. Any TCP traffic with a different port will be, instead, still blocked.

The default network has, anyway, some ingress rules with priority 65534 to allow some basic connection to the VM like SSH, RDP (Windows), ICMP (PING) and connection from VM inside the same network:

You can’t change these rules during the VPC creation but later you can change them in the firewall section.

A tip for writing firewall rules

You can use a combination of IP ranges and tags or IP ranges and service accounts for traffic filter, but service accounts and tags combination is not supported at the time of writing.

Using tags or service accounts will keep your firewall rule tidy as easy to understand because if you have to apply the same rule to hundreds of instances you can avoid going through each and every instance and adding their IP in the source. Instead, you can just use common tag or service account among VMs.

The following example create a firewall rule called “secure-billing-data” in the “web-network” network allowing a TCP connection on port 443 from VM/applications identified by the service account billing-frontend@…. to VM/applications identified by the service account billing-data@….

gcloud compute firewall-rules create secure-billing-data \
    --network web-network \
    --allow TCP:443 \
    --source-service-accounts billing-frontend@web.iam.gserviceaccount.com \
    --target-service-accounts billing-data@web.iam.gserviceaccount.com

VPC Network Peering

Google Cloud VPC Network Peering allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks regardless of whether they belong to the same project or the same organization.

VPC Network Peering enables you to connect VPC networks so that workloads in different VPC networks can communicate internally. Traffic stays within Google’s network and doesn’t traverse the public internet.

VPC Network Peering is useful in these environments:

• SaaS (Software-as-a-Service) ecosystems in Google Cloud. You can make services available privately across different VPC networks within and across organizations.
• Organizations that have several network administrative domains that need to communicate using internal IP addresses.

If you have multiple network administrative domains within your organization, VPC Network Peering allows you to make services available across VPC networks by using internal IP addresses. If you offer services to other organizations, VPC Network Peering allows you to make those services available by using internal IP addresses to those organizations. The ability to offer services across organizations is useful if you want to offer services to other enterprises, and it is also useful if you own or control more than one organization.

VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including:

• Network Latency: Connectivity that uses only internal addresses provides lower latency than connectivity that uses external addresses.
• Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks
• Network Cost: Google Cloud charges egress bandwidth pricing for networks using external IPs to communicate even if the traffic is within the same zone. If however, the networks are peered they can use internal IPs to communicate and save on those egress costs. Regular network pricing still applies to all traffic.

Shared VPC

In GCP you can create a VPC in project (called host) and share it across other projects in the same organization. Practically you attach other projects to this host project. In this way organization can delegate services administration but keep centralized the networking (subnets, routes and firewalls).

A host project can have multiple shared networks. A project can be host and be attached to a shared VPC at the same time but it can be associated with only another single project.

When a Shared VPC is in place you will have the following admin roles involved:

Organization Admin => Shared VPC Admin => Service Project Admins

Cloud VPN

Cloud VPN securely extends your on-premise network to Google’s network through an IPsec VPN tunnel. Traffic is encrypted and travels between the two networks over the public internet. Cloud VPN is useful for low-volume data connections.

If you need to encrypt traffic to Google Cloud, or you need a lower throughput solution, or you are experimenting with migrating your workloads to Google Cloud, you can choose Cloud VPN.

On the other hand, if you need an enterprise-grade connection to Google Cloud that has higher throughput, you can choose Dedicated Interconnect or Partner Interconnect.

Create a Classic VPN Gateway

You need to have the role newtrokAdmin to create a VPN connection

Before creating a Classic VPN gateway and tunnel, you must create a Virtual Private Cloud network and at least one subnet in the region where the Classic VPN gateway will reside.

1. Create a VPN gateway and a tunnel
2. Reserve an external regional IP Address
3. Get and note the IP Address with the describe command
4. Create 3 forwarding rules allowing Google to redirect ESP (IPsec), UDP 500, and UDP 4500 traffic to the gateway
5. Create a Cloud Router if not already done (in this case use an existing ones)
6. Create the VPN Tunnel
7. Configure a BGP session for the Cloud Router

Google Cloud Router enables you to dynamically exchange routes between your Virtual Private Cloud (VPC) and on-premises networks by using Border Gateway Protocol (BGP). The Cloud Router automatically learns new subnets in your VPC network and announces them to your on-premises network.

A Cloud Router is identified by a unique identifier called ASN (autonomous system number)

VPN connections are not ideal for large constant flow of data between on-premise and GCP

Direct Interconnect vs VPN

Google Cloud Dedicated Interconnect provides direct physical connections and RFC 1918 communication between your on-premises network and Google’s network. Dedicated Interconnect enables you to transfer large amounts of data between networks, which can be more cost-effective than purchasing additional bandwidth over the public Internet or using VPN tunnels.

A dedicated interconnect network would provide a more highly available, low latency connection.

Setup access to Google Cloud Services from on premise without setting up an access to Internet

When you want to access to Google Cloud Services (for example Storage) from an on-premises machine without setting up an access to Internet you can:

• configure the on-premises DNS and map *.googleapis.com to restricted.googleapis.com which resolves to 199.36.153.4/30
• Configure Cloud Router to advertise the 199.36.153.4/30 range through the VPN tunnel
• Add a custom static route to the VPC direct traffic with the destination 199.36.153.4/30 to the default Internet gateway
• Created a Cloud DNS managed private zone for *.googleapis.com that maps to 199.36.153.4/30 and authorize the zone for use by VPC network

Focus on CLI commands

Create a VPC

gcloud compute networks create NETWORK \
    --subnet-mode=[auto|custom] \
    --bgp-routing-mode=DYNAMIC_ROUTING_MODE \
    --mtu=MTU

Expand a subnet range

gcloud compute networks subnets expand-ip-range SUBNET_NAME --region=… --prefix-length=27