YaoVPN

Connect roles and policy through a topology

YaoVPN serves a network maintained by one trusted administrator. A topology describes proxy exits, site Gateways, a central Hub, an optional remote access node and managed hosts. Preparation reads only the facts required by the selected role.

For clients, the main distinction is whether the target belongs to a private site. Common and Internal share ordinary access rules; Internal has a separate site entry and credentials. Importing a profile does not establish reachability—a real target request does.

Xray, Hysteria2 and Mihomo supply proxy protocols, routing and DNS, while kernel WireGuard links sites. YaoVPN produces material these native engines can use directly and manages admitted local network operations and configuration publication, without another resident custom VPN agent.

Deliver the right native material to each role

A site administrator maintains role locations, site subnets, peers and required credentials. An individual endpoint receives importable Common or Internal client configuration. These inputs serve different tasks: site material establishes interconnection, while client material selects egress and the private paths it is allowed to use.

A complete handoff identifies the native engine that loads the material, the existing network conditions it needs and how to observe a real destination. Document publication distributes material; its URL is not an immediate control channel for every endpoint.

Give site connectivity a precise local scope

The Hub connects the site Gateways, each retaining its existing local-area network (LAN) addresses and site networks. Prepared material specifies WireGuard peers, exact routes and required source addresses. Site-to-site traffic preserves source addresses without source network address translation (SNAT). A remote private-access node has a separately defined return path and conditional address translation.

Finite up and down operations acquire and settle only the role’s own interface, addresses, routes and conditional NAT. A matching name does not authorize takeover of a conflicting object. Completed setup establishes local resources, not continuing peer reachability. LAN, forwarding, firewall and return-path prerequisites remain with the administrator.

Common and Internal express different authority

Common profiles provide ordinary access; Internal profiles additionally permit private-site access. They share ordinary exits and direct-access rules. Common rejects declared site and backhaul destinations. Internal selects a separate private-site entry using VLESS and credentials distinct from ordinary egress. Neither client profile contains WireGuard private keys.

Class and site rules precede ordinary direct-connection (DIRECT) exceptions, preventing those exceptions from expanding private access. Gateways use their own LAN and WireGuard paths. Linux profiles use the engine’s native fallback selection, while imported client profiles use a selection group. Existing failed requests are not automatically replayed.

Internal reaches sites through a separate entry, Hub and Gateway. Neither client type holds site WireGuard private keys.

Complete generation, operation and publication separately

Preparation generates native configurations, executable bindings and service dependencies. Editing source does not immediately change a running network. Before replacing a WireGuard plan, local dependent users must end and the predecessor’s resources must settle. Incomplete teardown retains its actual responsibilities.

An independent publishing service supplies Common and Internal client profiles plus two fixed rule files from a complete catalog loaded at startup. Changing import links can retire old origin paths without revoking downloaded server credentials or cached copies. Public ingress, transport protection and credential changes require administrator coordination.

1. Declare

   Maintain topology, role inputs and explicit access classes.

2. Generate

   Produce native configuration, service material and client documents.

3. Activate

   Let native services establish the resources within their scope.

4. Observe

   Check local state, actual traffic paths and document retrieval separately.

Account for running resources and distributed credentials

A topology change first produces new material; authorized operations then apply it to the actual roles. When replacing a WireGuard plan, settle local consumers of the old plan before removing its owned interfaces, routes and other resources. Unfinished cleanup keeps its original responsibility and blocks a conflicting replacement.

Client updates must also account for old copies. Removing an import path does not retract downloaded credentials, and external caches may still serve content. Revocation must reach server-side credentials and actual admission policy. Check that the old credential can no longer obtain the selected access, rather than checking only that a document URL disappeared.

• Supported conclusion: a destination receives the selected traffic

  Together with actual peer and route observations, this supports the tested path under that deployment’s conditions.

• Unsupported conclusion: an importable configuration controls all traffic

  Native engine loading, host-network conditions and destination scope remain separate. They do not establish a universal isolation guarantee.

• Check next: local activation has completed

  Inspect the remote peer, return route and real request. Established local resources do not imply continuous remote reachability.

Establish paths with real traffic

Valid configuration, an active service, an existing interface and a response from the destination are different results. Specified verification generates material from source, observes actual WireGuard peers and routes, then obtains independent responses through proxies, DNS resolution and virtual network interfaces (TUN). Teardown checks that unrelated resources remain intact.

These scenarios promise no universal traffic capture, throughput figure or complete destination isolation. Client application lifecycle, host network policy and external services retain their own prerequisites. Applicable runtime observations establish the result for a particular deployment.