zlayer_overlayd/lib.rs
1//! `zlayer-overlayd` — the standalone `ZLayer` overlay daemon.
2//!
3//! This crate is the long-lived process that owns every mechanism touching the
4//! overlay/network plane: the `WireGuard`/Wintun device + adapter, peers,
5//! `AllowedIPs`/service subnets, IP allocation, DNS, NAT, Linux bridges +
6//! veth/netns attach, and the Windows HCN Internal network + endpoints. The
7//! main `zlayer` daemon keeps the cluster brain and drives overlayd over the
8//! IPC contract in [`zlayer_types::overlayd`].
9//!
10//! Running overlayd as its own OS service decouples the overlay adapter's
11//! lifetime from the main binary: updating/reinstalling `zlayer` no longer
12//! tears the adapter down, because overlayd is a separate process. The overlay
13//! is removed only on a full uninstall.
14//!
15//! ## Layout
16//! - [`transport`] — length-prefixed JSON framing over UDS / named pipe.
17//! - [`client`] — [`OverlaydClient`], used by the main daemon (the agent's
18//! `overlay_manager` shim wraps it).
19//! - [`server`] — [`OverlaydServer`], the engine that executes every
20//! [`OverlaydRequest`] by performing the same overlay mechanics the agent's
21//! `OverlayManager` did (cluster `WireGuard` transport, Linux bridges +
22//! veth/netns attach, Windows HCN Internal network + endpoints, IPAM, DNS,
23//! NAT).
24//! - [`network_state`] — the on-disk marker for host-level networks (HCN).
25//! - [`netlink`] — Linux RTNETLINK helpers for bridges, veth, routes, netns.
26//!
27//! [`OverlaydRequest`]: zlayer_types::overlayd::OverlaydRequest
28
29pub mod client;
30pub mod error;
31pub mod network_state;
32pub mod server;
33pub mod transport;
34
35#[cfg(target_os = "linux")]
36pub mod netlink;
37
38pub use client::OverlaydClient;
39pub use error::{OverlaydError, Result, MAX_FRAME_BYTES};
40pub use server::OverlaydServer;
41
42/// The IPC wire contract, re-exported for convenience.
43pub use zlayer_types::overlayd as protocol;