gcp VPC - ghdrako/doc_snipets GitHub Wiki

VPC - Virtual Private Cloud

gcloud compute networks create my-vpc-network \
--subnet-mode=custom \
--bgp-routing-mode=global \
--description="This is my vpc network"

VPS is global resource and vpc subnet is regional resource vpc subnets in different region to connect not reqiure vpn gatway. Is not need vpn to traffic between regions.

Quota - 5 vpc per project

• VPN
• Cloud Router
• Firewall
• NAT
• Subnets
• IP Ranges
• VPC Peering
• Cloud Interconnect
• Flow Logs - enable logging of the actual flows from your VMs
• Private Google Access
• Shared VPC
• Interconnection to Google Cloud
• Routes
• Carrier Peering

VPC Flow Logs allow you to record network flows to and from VM instance, including instances used as GKE nodes. The flows are recorded in 5-second intervals. Note that only the flows are recorded rather than the full network packet capture. These logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization.

VM instances that only have internal IP addresses (no external IP addresses) can use Private Google Access. They can reach the external IP addresses of Google APIs and services. The source IP address of the packet can be the primary internal IP address of the network interface or an address in an alias IP range that is assigned to the interface. If you disable Private Google Access, the VM instances can no longer reach Google APIs and services; they can only send traffic within the VPC network.

Private Google access is enabled on a subnet by subnet basis and supports most Google cloud services except for App Engine Memcache, Filestore, and Memorystore.

Once you enable private Google access for subnet on that VPC network, Google cloud will allow any virtual machines that are attached to that subnet to send traffic to the external IP addresses of Google APIs and services.

More specifically, traffic to Google APIs and services is allowed from the primary internal IP address of a virtual machine’s network interface, as long as it’s attached to a subnet enabled for private google access AND as long as it doesn’t have an external IP address assigned to it. Traffic to Google APIs and services is also allowed from an internal IP address that is part of an alias IP range of a virtual machine’s network interface that’s attached to a subnet that’s been enabled for private google access.

enabling private Google access doesn’t automatically enable any APIs. The APIs that you want to use need to be separately enabled through the APIs and services page in the Google cloud console.

Serverless VPC Access enables you to connect from a serverless environment on Google Cloud (Cloud Run, Cloud Functions, or the App Engine standard environment) directly to your VPC network. This connection makes it possible for your serverless environment to access Compute Engine VM instances, Memorystore instances, and any other resources with an internal IP address.

The dynamic routing mode of a VPC network—either regional or global— determines which subnet routes the Cloud Routers in that network advertise.

When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it. The VPC networks in the host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.

This allow the resources to communicate with each other securely and efficiently using internals IPs from that network.

Shared VPC work only in the same organization accros project

Shared VPC lets organization administrators delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources like subnets, routes, and firewalls.

Roles in Shared VPC

• Organisation Admin - nominates Shared VPC Admin
• Shared VPC Admin (roles/compute.xpnAdmin) - enable shared VPC for host project, attach service project, delegate access to subnest in shared VPC
  • Network admin: Full control over networks, excluding firewall rules and SSL certificates
  • Security admin: Control over firewall and SSL certificates
• Service Project Admin - create and control resource in shared VPC , network user

The configuration of a shared VPC requires a few steps, as follows:

1. Create host and service projects if they do not exist yet.

gcloud projects create host-project-34341212 \
–-name="host-project"
gcloud projects create serviceproject1-247521 \
–-name="development"
gcloud projects create serviceproject2-247521 \
-–name="production"

2. Create a shared VPC network inside the host project.

gcloud compute networks create shared-vpc \
--subnet-mode=custom

3. Create subnets inside the shared VPC network, assuming that we have created a Custom mode VPC network.

gcloud compute networks subnets create dev-subnet\
--network=shared-vpc \
--region=us-central1 \
--range=10.100.0.0/24
gcloud compute networks subnets create prod-subnet \
--network=shared-vpc \
--region=europe-west1 \
--range=10.200.0.0/24

4. Create an appropriate firewall rule in the shared VPC network.

gcloud compute firewall-rules create allow-icmp-inbound \
--network=shared-vpc \
–-allow icmp \
–-source-ranges=0.0.0.0/0
gcloud compute firewall-rules create allow-ssh-inbound \
--network=shared-vpc \
–-allow tcp:22 \
–source-ranges=0.0.0.0/0

5. Configure the shared VPC, defining the host project along with its subnets, and select the service projects.

• To configure Shared VPC by enabling the host project, select the subnets (dev-subnet and prod-subnet), select users by role, and provide permissions by attaching service projects (development and production).

gcloud compute shared-vpc get-host-project <project>  # show host project for <project>
gcloud compute network subnets list-usable --project <host project> # list of usable subnets shared from me 
gcloud compute network subnets describe  <subnet name> --regon <region> --project <host project> # return selfLink need to create instance in subnet 
gcloud compute firewall-rules list --project <host project>  # fw rule in host project
gcloud compute instance create <instance name> --project <project> --zone <zone> --subnet <subnet selfLink>
 

https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2#gcloud_1

You can connect two existing VPC networks together as long as the primary and secondary subnet IP address ranges in each network don't overlap. Requirements:

• Place one HA VPN gateway in each VPC network.
• Place both HA VPN gateways in the same Google Cloud region.
• Configure a tunnel on each interface of each gateway.
• Match gateway interfaces

Example

• NETWORK_1 contains the following subnets:

  • A subnet named SUBNET_NAME_1 in REGION_1 that uses the IP range RANGE_1.
  • A subnet named SUBNET_NAME_2 in REGION_2 that uses the IP range RANGE_2.

• NETWORK_2 contains the following subnets:

  • A subnet named SUBNET_NAME_3 in REGION_1 that uses the IP range RANGE_3.
  • A subnet named SUBNET_NAME_4 in REGION_3 that uses the IP range RANGE_4.

1. Create the HA VPN gateways

gcloud compute vpn-gateways create GW_NAME_1 \
   --network=NETWORK_1 \
   --region=REGION_1 \
   --stack-type=IP_STACK
gcloud compute vpn-gateways create GW_NAME_2 \
   --network=NETWORK_2 \
   --region=REGION_1 \
   --stack-type=IP_STACK

2. Specify the peer VPN gateway resource
3. Create Cloud Routers

gcloud compute routers create ROUTER_NAME_1 \
   --region=REGION_1 \
   --network=NETWORK_1 \
   --asn=PEER_ASN_1
gcloud compute routers create ROUTER_NAME_2 \
   --region=REGION_1 \
   --network=NETWORK_2 \
   --asn=PEER_ASN_2

4. Create VPN tunnels

gcloud compute vpn-tunnels create TUNNEL_NAME_GW1_IF0 \
    --peer-gcp-gateway=GW_NAME_2 \
    --region=REGION_1 \
    --ike-version=IKE_VERS \
    --shared-secret=SHARED_SECRET \
    --router=ROUTER_NAME_1 \
    --vpn-gateway=GW_NAME_1 \
    --interface=INT_NUM_0

gcloud compute vpn-tunnels create TUNNEL_NAME_GW1_IF1 \
    --peer-gcp-gateway=GW_NAME_2 \
    --region=REGION_1 \
    --ike-version=IKE_VERS \
    --shared-secret=SHARED_SECRET \
    --router=ROUTER_NAME_1 \
    --vpn-gateway=GW_NAME_1 \
    --interface=INT_NUM_1

gcloud compute vpn-tunnels create TUNNEL_NAME_GW2_IF0 \
    --peer-gcp-gateway=GW_NAME_1 \
    --region=REGION_1 \
    --ike-version=IKE_VERS \
    --shared-secret=SHARED_SECRET \
    --router=ROUTER_NAME_2 \
    --vpn-gateway=GW_NAME_2 \
    --interface=INT_NUM_0

gcloud compute vpn-tunnels create TUNNEL_NAME_GW2_IF1 \
    --peer-gcp-gateway=GW_NAME_1 \
    --region=REGION_1 \
    --ike-version=IKE_VERS \
    --shared-secret=SHARED_SECRET \
    --router=ROUTER_NAME_2 \
    --vpn-gateway=GW_NAME_2 \
    --interface=INT_NUM_1

Makes services available privately across different VPC networks within and across organizations. This allows workloads to communicate in private RFC 1918 space.

Each site of the peering is set up independently and peering is only established once both sides are configured. The project owner/editor and network admin roles are allowed to perform the configuration. It is important to remember that the CIDR prefixes cannot overlap between peering VPCs' subnets. Once peering has been established, every internal IP becomes accessible across peered networks.

two networks can be peered as long as they don't have overlapping IP address ranges. What peering means is that their route tables will be shared, and the underlying platform (Google's software-defined network) will be set up so that these two networks can be reached by each another. This effectively means you will have all your subnetworks (layer 2 network domains) across both VPC networks connected via a managed layer 3 router (which you do not need to concern yourself with).

When networks are peered, they can use internal IPs to communicate and save on those egress costs.

• Regular network pricing still applies to all traffic.

Decentralized approach to multi project networking.

VPC Network Peering work accros organisation but too witin project

VPC peering limitations:

• No subnet IP range overlap across peered VPC networks
• Legacy networks are not supported in VPC Network Peering
• No Compute Engine DNS across projects

VPC Network Peering limits:

• Maximum number of connections to a single VPC network 25 - The maximum number of networks that can connect to a given VPC network using VPC Network Peering.
• Maximum number of VM instances in a peering group 15,500
• Subnets and alias ranges
• ILBs forwarding rules
• Static and dynamic routes

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

• Network Latency: Public IP networking suffers higher latency than private networking. All peering traffic stays within Google’s network.
• Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
• Network Cost: GCP 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.

Establish VPC peering

0. Create VPC network

gcloud compute create network vpcnetwork1 --subnet-mode=custom
gcloud compute create network vpcnetwork2 --subnet-mode=custom
gcloud compute network subnets create vpcnetwork1-ew1 --network=vpcnetwork1 --region=europe-west1 --range=10.128.0.0/20
gcloud compute network subnets create vpcnetwork2-ew1 --network=vpcnetwork2 --region=europe-west1 --range=172.16.0.0/20
gcloud compute firewall-rule create vpcnetwork1-allow-icmp --direction=INGRESS --priority=65534 --network=vpcnetwork1 --action=ALLOW --rules=icmp --source-ranges=0.0.0.0/0
gcloud compute firewall-rule create vpcnetwork2-allow-icmp --direction=INGRESS --priority=65534 --network=vpcnetwork2 --action=ALLOW --rules=icmp --source-ranges=0.0.0.0/0
gcloud compute firewall-rule create vpcnetwork1-allow-ssh --direction=INGRESS --priority=65534 --network=vpcnetwork1 --action=ALLOW --rules=tcp:22 --source-ranges=0.0.0.0/0

# creates peering from vpc1 to vpc2
gcloud compute networks peerings create peering-vpc1-vpc2 \ 
--network=vpc-01 \
--peer-network=vpc-02 \
--peer-project= concise-cinema-312907
# creates peering from vpc2 to vpc1
gcloud compute networks peerings create peering-vpc2-vpc1 \ --
network=vpc-02 \
--peer-network=vpc-01 \
--peer-project=my-first-project-320319

# check VPC peering
gcloud compute networks peerings list

Both use to talk VPS each other. With VPN between VPC A and VPC B you could whant that only subnet A will be advertised across that. VPC peering is binary sa allsubnet in VPC A will get advertised to all subnets in VPC B - so peering make smashing both VPCs together to make one VPC. Fundamental difference is security polices. IN VPC peering security policew are done at the VPC level. Even if you smash two VPCs together to make one logical VPC in-term of preconfigured routes you still have two separate security polices.

• VPN tunel
• VPN peering ???
• VPC peering

Best practice: User interconect but leave VPN as a buckap to flip when hit problem with interconnect.

interconnect your VPC with an on-premises network

It resolves domain names into corresponding IP addresses. It can be used to publish and manage millions of DNS zones and records with ease. Cloud DNS can also host private zones accessible only from one or more VPC networks that you specify.

Cloud CDN is a service that allows the caching of HTTP(S) load balanced content, from various types of backends, including Cloud Storage buckets. Caching reduces content delivery time and cost. It can also protect you from a Distributed Denial-of-Service (DDoS) attack. Data is cached on Google's globally distributed edge points. On the first request, when content is not cached, data is retrieved from a backend origin. The subsequent requests for the same data will be served directly from the cache until the expiration time is reached.

Cloud NAT is a regional service that allows VMs without external IPs to communicate with the internet (firewall rules must allow this communication). It's a distributed, software-defined managed service that can be configured to automatically scale the number of NAT IP addresses that it uses. It works with both GCE and GKE. It is a better alternative for NAT instances that need to be managed by users.

Google Cloud recommends using Cloud NAT when you have many private VMs that need to access public services such as public repositories or upgrades.

Whenever a Cloud Router performs a NAT operation that is translating the private IP address into a public one and vice versa, the entire process is composed of two different stages.

For the outbound traffic, the translation is performed on the source IP address (private to public), and we call it SNAT. For the return packets, it is the destination IP address that is translated (public to private), and that is what we call DNAT.

Cloud NAT embeds Cloud Router to route outbound traffic out of one GCP region.

GCP Firewall is a service that allows for micro-segmentation. Firewall rules are created per VPC and can be based on IPs, IP ranges, tags, and service accounts. Several firewall rules are created by default but can be modified.

Example firewall rule allows SSH and ICMP incoming traffic to all GCE instances that are running on the networking-in-gcp-vpc VPC network. The firewall rule is valid for all traffic coming from any network range.

gcloud compute firewall-rules create my-first-rule \ --
network=networking-in-gcp-vpc \
--allow tcp:22,icmp \
--source-ranges=0.0.0.0/0

Cloud Armor is a service that allows protection against infrastructure DDoS attacks using Google's global infrastructure and security systems. It integrates with global HTTP(S) load balancers and blocks traffic based on IP addresses or ranges. The preview mode allows users to analyze the attack pattern without cutting off regular users.

• Pre-program routes

  • you cannot delete or change

• Default routes

  • Pre-programmed 0.0.0.0/0 rout to Internet Gateway
  • can be change

• Cloud router - Dynamic routing

  • Control plane only device; not data plan traffic traversses cloud ruter process
  • BGP speaker
  • Routing table are containing on host
  • Google-managed process, controlled by you, that runs on Google host

• Two routing modes

  • Regional - learn rout on region subnets
  • Global routing
    • Configured at VPC level
    • Allows all subnets to be advertised over BGP independent of region

• Default network - preconfigured Firewall Roles to allow all instances on the network to talk with each other
• Auto network - Auto mode: Automatically creates one subnet per region with predefined IP ranges with the /20 mask from the 10.128.0.0/9 CIDR block. Each subnet is expandable to the /16 mask.
• Custom network - It does not create subnets automatically and delegates complete control to the user. You decide how many subnets should be created and in which regions, dynamic routing mode (either regional or global) and MTU size. You can also specify if you wish for Flow Logs and private Google access to be enabled.

• Primary IP address rang - These can be assigned to a VM primary internal IP addresses, VM alias IP addresses, and the IP addresses of internal load balancers. Note that there are always four addressesreserved in this range.
• Secondary IP address range can only be used for alias IP addresses. There are no addresses reserved in those ranges.

• VMs with the same network can communicate using the internal IP, even if they are in a different region.
• VMs in a different network can communicate using external IPs, even if they are in the same regions.

• Egress between zones within the regions
• Egress between regions
• Internet egress (note: VPN traffic is treated as egress)

• Premium Tier provides high-performance routing. On top of that,it offers global load balancing and a Content Delivery Network (CDN) service. It is aimed at use cases where global presence is required. This tier comes with Service-Level Agreements (SLAs).
• Standard Tier is a lower performance network with no SLAs attached. The CDN service is not available and load balancers are regional.

is a service that allows you to dynamically exchange routes between VPC and on-premises networks by using Border Gateway Protocol (BGP) It eliminates the need for the creation of static routes.

When used in cooperation with an interconnect option, between your on- prem network and your VPCs, it uses the BGP protocol to dynamically exchange routes between your networks.

Cloud Router announces by default all visible subnets, depending on whether you choose Regional or Global dynamic routing mode. In Regional mode, only the subnets within the Cloud Router region will be advertised. In Global mode, all the VPC subnets will be advertised.

With a Cloud Router, you do not have to explicitly refer to the network IP ranges that you are using in your networks., In particular, any modification to the IP ranges that you are using on-prem as well as in your VPC does not require any human intervention to make this update knowable at the other side of the BGP peering. BGP, as a dynamic routing protocol, is in charge of exchanging any routing information dynamically. Therefore, BGP can automatically add new IP ranges and/or remove any range that is no longer used or reachable in your network.

A Cloud Router must be present in your GCP environment in the following cases:

• Creating a VLAN attachment for Dedicated Interconnect
• Creating a VLAN attachment for Partner Interconnect
• Creating a VPN tunnel connected to an HA VPN gateway
• Creating a cloud network address translation (NAT) gateway

A Cloud Router is not mandatory for classic VPNs (but is still recommended if your on-premises VPN gateway supports BGP).

Use Gracefull Restart BGP to eliminate data plane disruption from failure. Recomment to run multiple router in enviroment - typical practice is run two.

Advenced routes = static routes Common scenario to direct trafic from VPC to 3rd part Firrewall Next hop for advenced route:

• Internet gateway
• VM instance
• IP Address
• VPN Tunnel

gcloud compute routers \
create networking-in-google-cloud-router \
--project=<PROJECT_ID> \
--region=europe-west2 \
--network=networking-in-google-cloud-vpc \
--asn=65470

# Before creating any BGP peering, your Cloud Router needs a static external IP address

gcloud compute addresses create \
cloud-router-static-ext-ip \
--project=<PROJECT_ID> \
--region=europe-west2