# 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.