routing…
blueprint
The one topology the platform supports today: a single cluster in one region of your own GCP project, gateways meshed within it, workload networks peered to them, and host-level policy across the lot. Built by hand, because the steps Telaron will eventually take for you are not running yet.
Not operating yet
Step three cannot be completed yet: there is no way to get a gateway into your project. Gateways will arrive either provisioned by Telaron when you onboard or from a cloud marketplace listing, and neither is available. Every other step can be done today, and the page is written so it stays useful up to that point.
Your project sits in your own GCP organisation, not ours, and nothing in this blueprint moves it. Keep the three estates apart in your head, because each has a different owner and a different answer to what happens when something breaks.
Same project and same region is not an arbitrary choice. It is the shape Telaron’s own GCP integration builds, so a layout that matches it now will not need rework when the integration takes these steps over.
Follow the GCP setup guide to the end: configure the trust, register the account and validate it. Validation is the one step here that Telaron performs against your project today, and it proves the rest of the trust path works.
Create one cluster in the region you chose. Any role will do: the role is recorded and changes nothing.
Mint an enrolment token for the cluster, then bring up two or more gateways in the gateway network, with the token in their startup configuration. Give each an external address, because gateways reach each other over WireGuard on UDP 51820 and both ends must be routable. This step cannot be done from your project yet — see the banner above.
Enable IP forwarding on each instance when you create it, because GCP drops a packet addressed elsewhere before the operating system sees it, and the setting cannot be changed afterwards. Then enable it in the operating system as well, with net.ipv4.ip_forward, which the gateway does not yet do for you. Missing either one gives you the same symptom: a gateway that reports healthy and forwards nothing. Gateways Telaron builds have the cloud setting on already; a gateway you build yourself needs it from you, and every gateway needs the operating-system setting.
Each gateway presents its token, registers against the cluster and receives the other gateways in the cluster as its peers. Allow UDP 51820 between the gateways’ external addresses in your firewall. The mesh covers this cluster only — there is no peer outside it.
Peer each workload network with the gateway network. On the gateway side, export custom routes; on the workload side, import them. That asymmetry is what lets a route defined next to the gateways reach the workload network without the workload network routing anything back.
Put an internal passthrough load balancer in front of the gateways, health-checked over TCP on port 8081 where each gateway serves its health, and allow Google’s health-check ranges to reach that port. Check any other port and the balancer holds no healthy backend, so a gateway reporting healthy on 8081 while the balancer reports none healthy points at the check, not the gateway. Then add a route in the gateway network, with the load balancer as its next hop, for each destination you want to pass through the fabric. Name the destinations. Steering everything would send the workload networks’ internet traffic through the gateways at a higher priority than their own default route, which is almost never what you meant.
Name each host you care about as an endpoint and write the flows between them as rules, as in Getting started. Activate a version to push it to the gateways in the cluster.
Do not register the spokes yet
Registering a workload network with Telaron as a spoke is refused with 501 on GCP until the platform carries attachments out. Nothing is lost: forwarding is set entirely by the peering and route you built.