f2c80e17f1
Co-authored-by: Luca Prete <lucaprete@google.com> |
||
|---|---|---|
| .. | ||
| 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. |