f62b9362a2
* rename infrastructure folder to networking * example WIP: VPCs * move ip forwarding to its own variable in compute-vm module * add per-instance metadata support to compute-vm module * ipip tunnels on linux savepoint * simple multinic gateways example * remove stale files * resolve conflicts * update diagram * rename folder * use a template for gw cloud config, rename some resources and files * Update README.md * Update README.md * add basic plan tests for all networking e2e examples * fix test for foundations/environments e2e example * fix shared vpc e2 example count error in gke node service account permissions * use module path for assets in onprem e2e example * use project id from module in ilb e2e example * add mising boilerplates in tests * run examples tests in ci * update module's README * rename ilb example * Update README.md * fix rp_filter configuration * README * Update README.md * Update README.md * Update README.md * update CHANGELOG * update CHANGELOG * Update README.md |
||
|---|---|---|
| .. | ||
| README.md | ||
| backend.tf.sample | ||
| diagram.png | ||
| main.tf | ||
| outputs.tf | ||
| provider.tf | ||
| variables.tf | ||
README.md
Hub and Spoke via VPN
This example creates a simple Hub and Spoke VPN setup, where the VPC network connects satellite locations (spokes) through a single intermediary location (hub) via IPsec VPN, optionally providing full-mesh networking via custom route advertisements.
The example has been purposefully kept simple to show how to use and wire the VPC and VPN modules together, and so that it can be used as a basis for more complex scenarios. This is the high level diagram:
Managed resources and services
This sample creates several distinct groups of resources:
- one VPC for each hub and each spoke
- one set of firewall rules for each VPC
- one VPN gateway, one tunnel and one Cloud Router for each spoke
- two VPN gateways, two tunnels and two Cloud Routers for the hub (one for each spoke)
- one DNS private zone in the hub
- one DNS peering zone in each spoke
- one Cloud NAT configuration for each spoke
- one test instance for each spoke
Operational considerations
A single pre-existing project is used in this example to keep variables and complexity to a minimum, in a real world scenarios each spoke would probably use a separate project. The provided project needs a valid billing account and the Compute and DNS APIs enabled. You can easily create such a project with the project module or with the following commands:
MY_PROJECT_ID="<desired project id>"
gcloud projects create $MY_PROJECT_ID
gcloud alpha billing projects link --billing-account=XXXXXX-XXXXXX-XXXXXX $MY_PROJECT_ID
gcloud services enable --project=$MY_PROJECT_ID {compute,dns}.googleapis.com
The example does not account for HA, but the VPN gateways can be easily upgraded to use HA VPN via the net-vpn-ha module.
If a single router and VPN gateway are used in the hub to manage all tunnels, particular care must be taken in announcing ranges from hub to spokes, as Cloud Router does not explicitly support transitivity and overlapping routes received from both sides create unintended side effects. The simple workaround is to announce a single aggregated route from hub to spokes so that it does not overlap with any of the ranges advertised by each spoke to the hub.
Variables
| name | description | type | required | default |
|---|---|---|---|---|
| project_id | Project id for all resources. | string |
✓ | |
| bgp_asn | BGP ASNs. | map(number) |
... |
|
| bgp_custom_advertisements | BGP custom advertisement IP CIDR ranges. | map(string) |
... |
|
| bgp_interface_ranges | BGP interface IP CIDR ranges. | map(string) |
... |
|
| ip_ranges | IP CIDR ranges. | map(string) |
... |
|
| regions | VPC regions. | map(string) |
... |
Outputs
| name | description | sensitive |
|---|---|---|
| vms | GCE VMs. |