Add GCP deployment examples: create Terraform configurations for GCP, including network setup, instance definitions, and routing, along with a README for usage instructions.

2026-08-27 21:23:47 +02:00
parent 245d0dfd96
commit c8f54ca865
12 changed files with 465 additions and 2 deletions
@@ -0,0 +1,48 @@
+# GCP example
+
+Deploys `vpn-router` on a GCE instance: a two-NIC router (external/WAN and internal/protected,
+each its own VPC network), a demo protected `workload` subnet in the internal network routed
+through it, and cloud-init that installs and configures the package on first boot. See the
+repository's top-level [README](../../README.md) for what the package itself does, and
+[../azure/](../azure/) for the equivalent Azure example - the two share the same design.
+
+## Prerequisites
+
+- A GCP project and credentials Terraform can pick up (`gcloud auth application-default login`
+  or a service account).
+- An SSH key pair for `admin_ssh_public_key`.
+- A build of the `vpn-router` package published to the repository at `repo_url` (default: the
+  project's Gitea Debian registry). See [../../debian-package](../../debian-package) for
+  `build.sh`/`publish.sh`. That repository must allow anonymous reads, since the router pulls
+  the package with no credentials configured.
+
+## Usage
+
+```sh
+cp terraform.tfvars.example terraform.tfvars
+$EDITOR terraform.tfvars
+export TF_VAR_psk='change-me'   # keep secrets out of tracked files
+```
+
+`platform = gcp` and `mode = auto` are hard-coded into the cloud-init template call in
+`router.tf`: the router has exactly two NICs, and on GCP the system default route always goes
+out NIC0 (the external one here) while a secondary NIC only reaches its own subnet unless
+policy-routed - exactly the case `mode = auto` is designed to detect reliably. See the
+top-level README's "What mode decides" section.
+
+Unlike the Azure example, `ext` and `internal` are two separate VPC networks (GCP instances
+attach one NIC per network), with `int` and `workload` as two subnets inside the same
+`internal` network. GCP routes apply network-wide rather than per-subnet, so `routes.tf`
+needs no separate subnet association - the route in `internal` already covers both subnets.
+
+## Verifying
+
+```sh
+ssh <admin_username>@$(terraform output -raw router_public_ip)
+systemctl status vpn-router-setup
+swanctl --list-sas
+```
+
+Set `deploy_workload_vm = true` and re-apply to add a VM on the `workload` subnet (no public
+IP - reach it via the router or IAP) for confirming that its traffic to `remote_cidrs` actually
+flows through the router.