Peerlify
All posts

Guide · 8 min read

How to build a private network between servers in different locations

Servers in two clouds, a colo and an office can share one private network. The options, from VPC peering to site-to-site VPN to a mesh VPN, and how to set up the last one with auth keys.

P

Peerlify team

Engineering

To put servers in different locations on one private network, you either connect the networks (VPC peering, site-to-site VPN tunnels between gateways) or connect the servers themselves with a mesh VPN that gives each one a private address reachable from the others. Connecting networks suits whole sites; connecting servers suits a set of machines scattered across providers, offices and NATs.

Why you'd want it

  • An app server in one cloud talking to a database in another, without exposing the database publicly.
  • Monitoring, backups and log shipping between machines in different places.
  • Administering a fleet of servers from one place, without a public SSH port on each.
  • Lab or edge machines behind NAT that need to reach central services.

Option 1: cloud-native peering

Within one cloud provider, VPC/VNet peering or a transit gateway joins private networks directly. It's the simplest option when everything lives in one provider, and it needs no software on the servers. It doesn't extend to other clouds, a colo or an office, and it requires non-overlapping address ranges.

Option 2: site-to-site VPN

An IPsec (or similar) tunnel between two gateways makes two networks routable to each other. It's the standard way to connect an office to a cloud VPC.

  • Needs: a gateway at each site, with a public address or a provider-managed VPN endpoint, and non-overlapping subnets.
  • Exposes: the gateways' VPN ports.
  • Scales as: one tunnel per pair of sites, plus routing between them.
  • Grants: network-level reachability. Anything at site A can reach anything at site B unless you add firewall rules.

Option 3: a mesh VPN between the servers

Install a client on each server. Each one gets an address on a private overlay network and connects to the others: directly when the networks allow it, through a relay when they don't. How mesh VPNs work explains the model.

  • Needs: a client on each server.
  • Exposes: nothing; servers connect outbound, so this also works for machines behind NAT or CGNAT.
  • Scales as: add a server, it joins the network.
  • Grants: per-server access, controlled by rules that name servers by tag.

The trade-off is the inverse of site-to-site: you don't need gateways, but every machine that takes part needs the client.

Step by step with Peerlify

Peerlify is a mesh VPN with clients for Linux, Windows and macOS. For a fleet of Linux servers:

1. Create a reusable, pre-tagged auth key

In the console, open Settings → Keys and create an auth key. Make it reusable, set an expiry, and add an auto-tag such as tag:server so every server that enrolls with it is tagged. See Auth keys.

2. Install and enroll each server

shell
curl -fsSL https://pkgs.peerlify.net/install.sh | sh
peerlify login --auth-key=<key>

The install script adds Peerlify's package repository for apt, dnf/yum or zypper and installs the client as a systemd service. Each server gets an address from your network's subnet, 100.100.0.0/16 by default. More options in Add servers with auth keys.

3. Check connectivity

From any server:

shell
peerlify list peers -s
peerlify ping 100.100.0.15 --until-direct

p2p means the two servers found a direct path; ERPFServer means they're talking through an encrypted Peerlify relay, which happens when one side's network blocks UDP or uses a NAT Peerlify can't traverse.

4. Point your services at the private addresses

Configure the app to connect to the database at its Peerlify address, for example 100.100.0.15:5432. On Linux, use addresses rather than names; Peerlify writes device names to the hosts file on Windows and macOS only. Consider binding internal services to the Peerlify address, or firewalling them to the Peerlify subnet, so they're not reachable any other way.

5. Write the rules

A new network allows all traffic between its devices. Replace that with rules that match how the servers actually talk. Tag the app and database servers first (for example with separate auth keys that auto-tag tag:app and tag:db, or from the Devices page), because a rule only matches devices that carry its tags:

json
{
  "name": "app-to-db",
  "action": "accept",
  "source": ["tag:app"],
  "destination": ["tag:db"],
  "ports": ["5432"],
  "protocol": ["tcp"]
}

The receiving server enforces the rule. Add policy tests so a later edit can't silently break the path. See Write your first rule.

Things to know

  • IPv4 overlay. The private network carries IPv4 traffic between devices.
  • Only enrolled machines. Peerlify doesn't route to other machines on a server's LAN; each one you want to reach needs the client.
  • Auto-update. Clients update themselves by default; admins can turn this off per network, for example to control rollout on production servers.
  • Plan limits. The free Personal plan covers up to 3 users and 50 devices; see pricing for larger networks.

For reaching those servers from your laptop as well, see how to access a server behind NAT.