Networking

• Tiers:
  • Premium: google backend is used for routing packets between different regions
    • required if using Cloud CDN or Global Load Balancing
  • Standard: network traffic exits nearest to GCP source, then it travel on general internet
• Pricing:
  • ingress is free
  • egress within zone using internal IP, google products (YouTube, drive, map), GCP services in the same region are free
  • External IP address charged. static reserved but unused are charged higher. IPs attached to a forwarding rule are free
• Private access: Allows communication over internal IP
  • Private Google Access: allow VM instances with internal only IPs access most Google APIs and services
  • Private Google Access for on-prem hosts: similar to above but for on-prem hosts
  • Private Service Access: connect to Google or 3rd party VPC through peering
  • Serverless VPC Access: connect from a serverless environment (Cloud Run, App Engine SE, Cloud Functions) to resources in VPC network using their internal IP
• Network Intelligence Center is a google service that lets one visualize topology and test connectivity between VPC to/from {internet,on-prem}

Hybrid Interconnect

• Layer 3 (IP): Cloud VPN, Direct Peering, Carrier Peering
• Layer 2 (MAC): Dedicated Interconnect, Partner Interconnect

Cloud VPN

• VPN is a regional resource with an external IP address
• HA VPN v/s Classic VPN
• Can have one or two interfaces with external IP automatically chosen by Google. SLA is available only for two interfaces
• HA Cloud VPN gateway supports more than 1 tunnel that can connect to multiple on-prem VPN gateways for redundancies
• HA VPN supports only BGP, whereas Classic VPN supports both static and dynamic routing
• connects on on-prem VPN gateway which also has an external IP address
• uses two VPN tunnels for connecting in each direction
• In order to use dynamic routing, must use Cloud Router to use BGP
• BGP requires two link-local IP addresses to communicate routes dynamically

Comparing VPN and Interconnect (Dedicated or Partner)

	IPSec VPN	Dedicated Interconnect	Partner Interconnect
Data flows on	encrypted over Internet	dedicated	dedicated through SP
Requirement	On-prem VPN Gateway	Collocation	Service Provider
Speed (Gbps)	1.5-3 /tunnel	10 or 100 / link	0.05-10 / connection
Access	Internal IP	Internal IP	Internal IP
Encrypted?	Yes	No	No

Peering: exchange BGP routes, can reach Google services like YouTube, g-suite, google APIs

	Direct	Carrier
Requirement	GCP Edge PoPs	Service Provider
Speed Min	10 Gbps	50 Mbps
Access type	Public IP	Public IP

	Interconnect	Peering
Layer	2 / MAC (uses VLAN)	3 / IP
Dedicated	Collocation	GCP PoPs
Shared	Partner	Carrier
Access type	Internal IP (Private Google Access)	External IP (Google's public IPs)
SLA	Yes	No

VPC

• VPC is a global resource whereas subnets are regional resources
• VPC is just a collection of subnets. Subnets need not be derived from a single CIDR block
• Auto mode VPC creates one subnet in each region, whereas, Custom mode allows subnets to be created as and when needed
• Shared VPC allows a host project to share networking resources to other service project, instead of each project creating a VPC
  • Shared VPC project can then host only VPC and be managed by network and security team
  • Service projects can own VMs and other resources and tap into shared VPC for networking, they get billed for network usage
• VMs have routing table and firewall built-in
• Each VPC has an internal network-scoped DNS that resolves hostname (can't lookup by hostname if not in the same network)
  • FQDN: <host>.<zone>.c.<proj-id>.internal
• Cloud DNS: programmatically manage zones using REST API or CLI with 100% uptime SLA
  • Q: What's a use-case? A: To redirect on-prem traffic to cloud in case of prod failure
• Cloud CDN: Use Google's or others available via CDN Partner Interconnect
• VPC Service Control allows context based security by establishing Service Perimeter using Access Context Manager
  • it is an additional layer on top of identity based IAM. Mitigates risk of stolen identities
  • disallows copying data from supported services like Cloud Storage and BigQuery
  • clients with private access within the Service Perimeter cannot access unauthorized resources outside the perimeter
  • Service Perimeter can include on-prem network using VPN or inter-connect
  • access from internet is optionally allowed based on the context (e.g. IP address)
• all VMs in the same VPC network, irrespective of subnets or regions, are reachable via internal IP address.
  • External IP communication doesn't go through public internet but uses google edge routers, but has different pricing and security
• Multiple VPC
  • A single VM with multiple NICs must have each NIC connect to a different VPC
    • CIDR addresses of NICs cannot overlap
  • In a VM, only the primary interface (nic0) is used for name resolution
  • Any traffic that is not directed within the subnets to which multiple interfaces are attached, is directed to primary interface

VPC Peering

• Communicate via private IPs between projects or organizations
• VPCs participating in peering can't have overlapping IP ranges (use VPN instead)
• is non-transitive
• firewall rules are not shared with VPC peering
• BP: potential network egress savings if in the same zone. Using external IP will always have egress charges
• BP: v/s VPN: Peering is sharing all-subnet, VPNs allow you to choose which subnet to share

gcloud

• create new VPC: gcloud compute networks create privatenet --subnet-mode=custom
• create new subnet: gcloud compute networks subnets create privatesubnet-us --network=privatenet --region=us-central1 --range=172.16.0.0/24

subnet

• are regional and can cross multiple zones
• first 2 and last 2 addresses are reserved
• public IP addresses can be used as subnet range, GCP doesn't route traffic to them
• If private google access isn't enabled for subnet, then VMs within will need public IP to access GCP services
  • google APIs still resolve to public IP, but the traffic flows on internal network if private api is enabled
  • subnet must have a route to default-internet-gateway (generally the default route for 0.0.0.0/0)
• Dynamic Routing: Regional or Global, indicates if Cloud Routers will advertise the subnet only in the region or all to the on-prem router
• subnet range can be expanded (without requiring downtime) but cannot be reduced
  • auto-mode subnets can be expanded from /20 to /16 but no larger. Must convert to custom if larger range is needed
• A subnet can have a different sized secondary CIDR range
• A VM network interface, in addition to one primary IP, can have a range of alias IPs which can come from either primary or secondary IP ranges
  • useful for assigning each service in a single VM a different IP address, e.g IP addresses for GKE pods
  • using secondary CIDR range for alias IP addresses allows separate firewall rules for infrastructure (VM) and services (containers)

Routes

• Route types: System (default and subnet), Custom (static and dynamic), Peering
• system routes:
  • default route: 0.0.0.0/0 can be removed/modified
  • subnet route can't be removed/modified directly, but changes when subnets are modified/added, (possibly due to VPC peering)
    • no other route can match or be more specific than subnet route, but can be broader and may contain subnet destination
• Custom routes can be maintained manually or by Cloud Router, cannot overlap or match subnet routes
  • static routes: next hope can be instance an by name/IP, VPN tunnel or Internet Gateway IG
  • dynamic routes: discovered by Cloud Router from its BGP peer (eg onsite router that routes to onsite subnets), next-hop is the BGP peer
• routing order are chose by most specific to least specific order
  • subnet route is considered more specific than any other overlapping route, always chosen regardless of priority
• route priorities determine which route to take when there are multiple routes.
  • e.g. if you have local interconnect and VPN, then local might have a priority 1000 and VPN 2000, will make local prefer over VPN
• advance routing (static routes) used when
  • cloud routing/dynamic routing isn't used
  • force traffic to specific VM/third party devices (such as firewall)
• VPC Flow Logs, enabled at subnet level, can be used for debugging and logging routing decisions

firewall

• rules are at project+network level; use firewall policies for Org level firewalls

• are stateful, i.e. responses to incoming traffic sent out is always allowed

  • if a packet is sent out in the last 10 minutes, a response is allowed
  • components:
  • action: either allow or deny
  • direction: can be either ingress or egress, but not both
  • priority: first matching in order of priority (low priority number => high priority)
    • deny > allow if rules have same priority
  • target: applies to both ingress and egress, always refers to Goggle Compute VMs to which it applies. Can be,
    • all instances
    • instances with specific target tag
    • instances using a specific service account
  • source/destination: applies to ingress/egress rules respectively
  • protocol: {TCP, ICMP, UDP} and port
  • enforcement: enabled or disabled
  • default target is all VMs in the network, default source for ingress is 0.0.0.0/0
  • Certain built-in rules cannot be overridden (such as GRE, SMTP)

  • implied rules are override-able (and hidden)

  • egress to any and ingress from none

  • pre-populated rules in default network can be modified or dropped

  • allow: internal, ssh, rdp and icmp

  • BP: prefer service account over network tags to apply firewall rules because network tags can be used by any VM admin, whereas service account usage requires IAM role
  • gcloud

    gcloud compute firewall-rules create www-firewall --allow tcp:80
    gcloud compute firewall-rules create privatenet-allow-icmp-ssh-rdp --direction=INGRESS --priority=1000 --network=privatenet \
            --action=ALLOW --rules=icmp,tcp:22,tcp:3389 --source-ranges=0.0.0.0/0
    gcloud compute firewall-rules list --sort-by=NETWORK
    

Cloud Router

• Cloud Router v/s real router: cloud router provides control plane only. i.e.
  • Cloud router learns and evaluates routing policy, but does not accept data traffic
  • built routes are pushed to VMs which sends data traffic per the received routes
  • a failure doesn't disrupt data plane, only the control plane (ability to update routes)
• connects to one of: Classic VPN tunnel, HA VPN tunnel, VLAN for dedicated interconnect or VLAN for partner interconnect
• Required for: Cloud NAT, Cloud Interconnect and HA VPN. Recommended for classic VPN
• routing modes: regional or global. In regional mode only advertises subnet in that regions
  • global mode are at VPC level
• work at L3, but the interconnect (ie dedicated or shared ISP) is L2
• BP: have multiple routers for HA, e.g. 1 in US east and 1 in US west in global mode. Local routes will have a lower priority, but can use other routers in case of local router failure
  • Cloud routers are managed by Google, in case of failure, it is spun back up automatically

Cloud NAT

• regional resource
• allows outbound access without inbound access
• needs Cloud Router
• regional solutions, only VMs in the same region can use the NAT defined in the same region
• doesn't use proxy like traditional NAT, it allocates internal NAT IPs and ports to each VM
• v/s manual NAT gateway: manual requires: setting up instance group for HA, reserving static IPs, health checks, default routes, no scale out
• BP: v/s VPN: is complex