Peer-to-Peer VPN Still Has Central Dependencies

Peer-to-peer describes how application packets travel, and nothing more. The peers still had to find each other, prove who they are and, sometimes, fall back to a relay when a direct path could not be built. Those are three separate services, and a deployment can be peer-to-peer for data while being entirely centralized for everything else. Comparing designs means comparing those jobs, not the arrow on the diagram.

A diagram without a central forwarding arrow can hide an enrolment authority, a discovery service and a relay, all of which are operational dependencies.

Direct Path, Shared Control Plane

Two machines exchanging packets directly may still depend on a shared authority that issued their certificates and a service that told each one where the other lives. Neither role forwards application traffic, which is why the topology drawing omits them. When that authority or service is down, existing sessions may continue while a new peer cannot join. The difference between starting a session and continuing one is the first question to ask of any design.

Draw each job separately even when a single host performs all of them. Otherwise the drawing shows a decentralized data plane and hides the operational reality that every new peer needs the same two services.

Discovery, Trust and Relay Are Three Jobs

Nebula's design is a useful example because its documentation keeps them apart. Hosts carry certificates for identity, lighthouses answer the where-is question and help with NAT traversal, and relays forward traffic when a direct path cannot be established. The relay role is deliberately distinct from the lighthouse role, so a reachable lighthouse does not promise that a given pair can talk. Other products draw the lines elsewhere, which is why this is an example rather than a template.

For a proposed deployment, write down the supported fallback for a pair that cannot connect directly. A failed hole-punch is one data point about one network, not a proof that two NATed peers can never meet; the opposite claim, that direct connectivity works across arbitrary policy, is just as unsupported.

What Each Dependency Fails

Evaluate four cases separately while the dependency under test is unavailable: existing peer traffic, a brand-new peer connection, a peer whose endpoint changed, and access that was just revoked. Each relies on different services and fails differently. Existing sessions may survive a discovery outage while a revoked key still gets refused, and a new peer may fail for reasons that have nothing to do with forwarding. Test them individually instead of concluding from one.

A connection that survives a single outage does not establish indefinite independence. It establishes that the outage you caused was not the one that breaks that path, which is still useful information provided you wrote down what you caused.

Ask Which Outage You Can Survive

Requirements that sound similar lead to different designs. Avoiding a single forwarding bottleneck is not the same as avoiding a vendor-hosted control plane, and neither matches continuing to operate while a coordinator is down. Name which of those three the deployment must satisfy, then check the mapping. A design that meets the first and fails the second is common and not dishonest, as long as nobody calls it fully decentralized.

Record who operates discovery, trust and relays, and how each is replaced. That record is what lets the next person answer a real question: which failures does this network survive, and who maintains the state that remains shared?

The word decentralized earns its place when it names those failures. Without that list it describes a diagram rather than a system.