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
55 lines
4.0 KiB
Markdown
55 lines
4.0 KiB
Markdown
# 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](https://cloud.google.com/vpn/docs/concepts/overview), optionally providing full-mesh networking via [custom route advertisements](https://cloud.google.com/router/docs/how-to/advertising-overview).
|
|
|
|
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](../../modules/project) or with the following commands:
|
|
|
|
``` shell
|
|
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](../../modules/net-vpn-ha).
|
|
|
|
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.
|
|
|
|
<!-- BEGIN TFDOC -->
|
|
## Variables
|
|
|
|
| name | description | type | required | default |
|
|
|---|---|:---: |:---:|:---:|
|
|
| project_id | Project id for all resources. | <code title="">string</code> | ✓ | |
|
|
| *bgp_asn* | BGP ASNs. | <code title="map(number)">map(number)</code> | | <code title="{ hub = 64513 spoke-1 = 64514 spoke-2 = 64515 }">...</code> |
|
|
| *bgp_custom_advertisements* | BGP custom advertisement IP CIDR ranges. | <code title="map(string)">map(string)</code> | | <code title="{ hub-to-spoke-1 = "10.0.32.0/20" hub-to-spoke-2 = "10.0.16.0/20" }">...</code> |
|
|
| *bgp_interface_ranges* | BGP interface IP CIDR ranges. | <code title="map(string)">map(string)</code> | | <code title="{ spoke-1 = "169.254.1.0/30" spoke-2 = "169.254.1.4/30" }">...</code> |
|
|
| *ip_ranges* | IP CIDR ranges. | <code title="map(string)">map(string)</code> | | <code title="{ hub-a = "10.0.0.0/24" hub-b = "10.0.8.0/24" spoke-1-a = "10.0.16.0/24" spoke-1-b = "10.0.24.0/24" spoke-2-a = "10.0.32.0/24" spoke-2-b = "10.0.40.0/24" }">...</code> |
|
|
| *regions* | VPC regions. | <code title="map(string)">map(string)</code> | | <code title="{ a = "europe-west1" b = "europe-west2" }">...</code> |
|
|
|
|
## Outputs
|
|
|
|
| name | description | sensitive |
|
|
|---|---|:---:|
|
|
| vms | GCE VMs. | |
|
|
<!-- END TFDOC -->
|