Persist central network intent and compile complete per-device configs with secure credentials, ACL policy, and dedicated Gateway runtimes. Expose network, credential, device registry, and runtime observation APIs. Treat central management and external Console as alternative consumers of the upstream ClientManager. Register central devices through a local webhook handler and publish through existing runtime reconciliation. Serialize public mutations with enrollment, reject direct credential changes to managed instances, and retain REST revision invalidation. Keep Gateway lifecycle publication in the central service and remove obsolete incremental result bookkeeping. Restore persisted networks and retire orphan runtimes through the same serialized publisher. Add Core and protocol support for Gateway and WireGuard management, including GUI bindings and serialized GUI config writes. Bootstrap IPv4 for DHCP-only networks and retain assigned addresses without peer IPv4. Cover intent transactions, complete configuration publication, offline recovery, authentication, revocation, Gateway lifecycle, and DHCP. Validate central candidates before persistence using Core URL, config, and portal-client rules. Reject unsupported peer schemes, unconvertible proxy subnets, and invalid portal clients without changing live intent. Expose existing pure Core validators without changing runtime behavior. Gate API-facing credential validation on API-enabled Core builds so minimal WASM targets do not reference omitted management types. Preserve session-backed device views in external Console mode. Bound Gateway admissions without cancelling transport upgrades, and cancel pending peer handshakes before retiring runtimes. Batch registry reads and bound runtime observation concurrency. Randomize DHCP bootstrap and conflict retries, keep an advertised current subnet, and select fallback subnets deterministically. Cover concurrent startup, Gateway admission lifetime, and external Console regressions. Allow DHCP bootstrap with no remote routes. Count network members through one tenant-scoped query without write transactions. Cover zero- peer allocation and tenant/empty-network counts. Preserve direct Web configurations and disabled states in central device snapshots. Remove obsolete central rows atomically with membership changes. Stop online managed instances before deleting or blocking devices, retaining intent when shutdown or deletion fails. Persist automatic IPv4 allocations separately from manual overrides so subnet changes reallocate only automatic members. Normalize mapped proxy routes to their advertised CIDRs when granting temporary credentials. Cover publication, deletion rollback, subnet migration, and grant updates. Read central intent in deferred transactions so polling does not reserve the SQLite writer lock. Test reads with an active writer and assert the temporary-member secret constraint using a valid device fixture. Persist patched WireGuard clients from the saved Web or GUI candidate without a follow-up RPC. Preserve pending settings and ownership, and cover disconnects and failed patches. Resolve named credential and config mutations against the live Core instance before checking central ownership. Forward authorized mutations by UUID on the same session, including while network renames are pending. Cover all mutation methods and preserve direct Console behavior. * feat(web-ui): add central network console and WireGuard management Add network and device views with central membership, credentials, ACL policy, temporary peers, and per-instance runtime details. Update console navigation, styling, theme handling, and API clients. Extend shared configuration and status components for central networks. Add a WireGuard portal dialog for setup and running-device management, with matching translations and network configuration types. Use secure UUID generation on HTTP, discard stale member configuration responses, and stop node-detail polling when the component unmounts. Update frontend workspace dependencies and include component, dashboard, configuration serialization, and central console end-to-end tests. Add isolated real-Core E2E coverage for central data-plane traffic, ACL, DHCP, recovery, device lifecycle, and native WireGuard clients. Record all 59 functional checks with evidence and confirmed validation/UI defects; keep runtime artifacts and test credentials out of Git. Normalize protobuf logger levels and render translated labels correctly. Cover all six levels across setting, reload, and language changes. Add real configuration-rejection E2E checks for database and Core stability and uninterrupted traffic, and record the resolved audit findings. Gate central navigation and registry actions by console mode. Refresh WireGuard settings on mounted status views and preserve explicit portal listener endpoints. Explain the trusted permanent-member ACL boundary. Cover external Console rendering, portal refresh retries and teardown, and explicit IPv4/IPv6 listener exports. Preserve PublicServer discovery when saving its settings, including when its URL matches the Gateway. Cover renaming and endpoint edits in the browser. Display automatic member addresses without converting them to manual overrides during edits. Derive offline address prefixes from the network subnet. Add browser regression coverage and real-Core checks for direct configuration preservation, temporary proxy mappings, automatic subnet migration, and shutdown before device deletion. Build enrollment commands from the configured API hostname, including IPv6 and relative endpoints. Use the PublicServer connector in temporary credential CLI and TOML exports. Add browser regression coverage. Preserve form credentials across repeated normalization and GUI storage reloads. Keep explicit form values authoritative over backend keys and cover JSON persistence, idempotence, replacement, and clearing.
6.4 KiB
EasyTier Domain Context
Module layers
easytier-core layers dependencies from foundation upward through the
portable networking domains. foundation contains infrastructure Modules
that have no dependency on a networking domain and may be used by any higher
layer.
Operation broker
An operation broker owns the lifecycle of asynchronous work submitted by an external caller to core. It allocates opaque operation IDs, arbitrates completion, cancellation, and disposal, retains terminal outcomes, and publishes a batch-drainable completion queue.
The broker does not interpret operation kinds, outcomes, resources, wire formats, or domain errors. Each domain Module owns those semantics and composes the broker under the same lock as any state that must change atomically with an operation transition.
Host capability operations use a separate seam. They turn Host readiness into Rust task wakeups and do not share the caller-to-core broker state machine.
Credential grant
A credential grant contains the authorization constraints shared by generated, imported, managed, and attached-peer credentials: ACL groups, relay permission, allowed proxy CIDRs, and whether concurrent reuse is allowed. It does not own credential identity, key material, lifetime, persistence, or runtime ownership. Each credential intake path normalizes the grant before installing it.
Peer Relay advertisement
A platform peer may prefer an eligible directly connected credential relay by omitting covered credential-leaf edges from only its own advertised OSPF connection row. Its local route calculation still uses the complete physical adjacency so direct-destination fallback remains available. Other peers' source-owned rows and versions are never rewritten, cached for promotion, or otherwise changed by this projection.
Before a graceful Instance stop, the owner publishes a new-version empty connection row while keeping its physical adjacencies available for route synchronization. It waits for the current direct route Sessions to acknowledge that withdrawal up to a bounded deadline, then continues shutdown. Abrupt process loss cannot publish this withdrawal and retains the normal route expiry behavior.
Relay eligibility comes from the transport-authenticated credential identity and grant, not self-reported route metadata. The advertisement Module does not support changing a credential's relay permission in place; such a permission change is a credential revocation and new authenticated Session.
Attached peer
An attached peer is an ordinary PeerManagerCore connected to another
PeerManagerCore through an authenticated in-process transport. Each
authenticated portal client owns one complete peer manager. The managers are
protocol peers; attached describes only the local transport and its trusted
ingress provenance, not a parent/child peer role.
An attached peer owns one complete IPv4 CIDR (for example 10.144.0.5/16).
Its address and advertised network are independent of the network manager's
own static or DHCP address. A VPN portal derives the attached peer route and
the external client's allowed network from that single CIDR; it does not infer
either value from the portal-hosting instance.
An external portal client uses that same IPv4 address on its native tunnel interface. The portal validates the source address and forwards IPv4 packets unchanged between the native tunnel and the attached peer; it does not assign a second tunnel-only address or perform address translation.
Each manager owns its ACL execution state, route service, RPC endpoint, secure sessions, packet processing, and lifecycle. Portal code supplies raw packets and peer configuration but does not build, reload, or coordinate ACL filters.
When the network manager uses Secure Mode, an attached peer authenticates as a credential peer. Its portal-owned, in-memory credential grant carries ACL groups and is revoked with the attached runtime; the peer never receives the network secret or ACL group secrets. A non-Secure-Mode network retains the legacy admin-attached identity for compatibility. A credential peer cannot host a portal because it cannot issue credential grants. Each live portal Session owns a fresh attached-peer identity, while the external client key remains stable across Sessions; a replacement Session must never reuse the previous non-reusable credential identity.
Compact compatibility Host
A compact compatibility Host retains accepted values in the authoritative TOML model for management readback, while the shared host-aware normalization path omits capabilities that the compact runtime cannot execute. Omitted settings are silent no-ops and must not be advertised as live network capabilities.
Web compatibility Host
The Web compatibility Host runs the portable EasyTier guest in JavaScript runtimes that provide WebAssembly JSPI. Its shared runtime Module owns guest lifecycle, Host capability operations, data-plane resources, and WebSocket message handling. Browser and Cloudflare Adapters own only the platform-specific way that WebSockets are dialed or accepted and the matching guest artifact.
The Browser Adapter is an outbound-only EasyTier instance with a smoltcp TCP data plane. The Cloudflare Adapter is an inbound-only relay hosted by one named Durable Object. Their public configuration exposes only capabilities each Host can execute; guest ABI details and serialized TOML remain internal.
Web configuration consumers
Central network management and an external Console are alternative consumers
of ClientManager. An external webhook selects Console mode; otherwise the
central service registers devices through an in-process webhook handler and
publishes each device's complete compiled configuration through the existing
Full reconcile API. ClientManager owns persistence, offline replay, and
runtime reconciliation without knowing central network business state.
The central service owns network intent, device registration and bans, and Gateway runtimes. Central HTTP mutations and direct public configuration writes share its mutation lock so ownership checks cannot race with enrollment. Internal Console APIs retain their upstream behavior and central routes and publication workers are disabled in Console mode.
Device deletion uses the upstream disconnect semantics: an already in-flight validation may register the device again. A persisted ban rejects subsequent validations. Deletion does not introduce device generations or session fences.