3.7 KiB
Implementation Plan
Basis: the approved specification. This document defines the order of work without changing the requirements. Specific libraries and serialization formats remain implementation decisions.
1. Model and configuration
Create the Rust project and types for clients, address ranges, managed metadata, drafts, and applied state. Resolve application settings relative to the executable. Require root when launching the management interface, while allowing module tests to run without root.
Outcome: settings are loaded with required fields validated; data locations do not depend on the working directory.
2. Preserving the server file
Implement document parsing that preserves original fragments, editing restricted to [Peer] sections and managed comments, import, and anomaly detection. Define a versioned comment format. Do not replace the entire configuration using ordinary INI serialization, which may discard comments and unknown parameters.
Validation: fixture configurations covering comments, IPv4/IPv6, unknown parameters, and existing clients; untouched portions must remain byte-for-byte identical.
3. Keys and vault
Choose a maintained cryptographic library with an established asymmetric encryption format. Use the operating system's random number generator, a password-protected secret key, and a versioned vault format. Do not develop custom cryptographic primitives. Keep temporarily decrypted secrets out of logs and the ordinary TUI model.
Validation: encryption without a password, correct and incorrect passwords, corrupted records, key matching during import, and absence of plaintext client secrets in persisted application data.
4. Backups, Commit, and restore
Define a versioned archive with a manifest describing its contents, creation reason, and verified application status. Prevent recursive inclusion of archives and arbitrary writes from archive entries outside permitted destination paths.
Organize file and vault persistence so that write failures cannot be reported as a successful Commit. This protects write integrity and is not a concurrent editing mechanism. Create the mandatory backup before modifying operations.
Validation: a complete save/restore cycle in a temporary directory, no restart during Commit, operation cancellation on backup failure, and restoration without vault decryption.
5. Running VPN adapter
Choose a minimal mechanism for reading current peers, handshakes, and counters; consider a direct Linux API instead of invoking utilities. Restart the configured systemd service, wait with a timeout, then verify the interface and clients. Isolate system calls from application logic.
Validation: a controllable test adapter for failures and state transitions, plus a separate integration environment for real WireGuard/systemd. Do not use the production VPN as a test environment.
6. Connection delivery and TUI
Choose maintained TUI and QR libraries. Build the list, creation and alias forms, deletion confirmation, change preview, Commit, restart, import, and backup list. Add masked password input, output path selection, and retrying initial delivery after a failure.
Validation: user scenarios from creation through delivery, deletion through address release, restoration without a password, and exiting with a draft. Verify terminal restoration after errors and absence of secret display outside explicit delivery actions.
7. Acceptance and operation
Prepare example settings, instructions for running from a dedicated root-only directory, and documentation for import, password custody, backups, and manual recovery. Run formatting, static analysis, tests, and a build for the target host architecture. Record integration results and any limitations not verified on the server separately.