feat(devops): complete phase 3 infrastructure
This commit is contained in:
@@ -0,0 +1,118 @@
|
||||
Berikut adalah **Master Prompt & Blueprint Dokumentasi Teroptimasi** yang dirancang khusus untuk diberikan kepada AI Developer (seperti GPT-4, Claude 3.5 Sonnet, atau Cursor AI).
|
||||
|
||||
Prompt ini telah dioptimalkan untuk **OpenCode**, artinya kode akan bersih, modular, terdokumentasi dengan standar industri, dan mudah dipindahkan (migrasi).
|
||||
|
||||
---
|
||||
|
||||
# 🚀 MASTER PROMPT: NexusGuard SD-WAN Orchestrator
|
||||
|
||||
**Role:** Senior Software Architect & DevOps Engineer.
|
||||
**Task:** Build a 3-tier Software-Defined WAN (SD-WAN) system based on WireGuard with Zero-Trust Isolation.
|
||||
**Architecture:** 3 Distributed Repositories.
|
||||
|
||||
---
|
||||
|
||||
## 1. GLOBAL ARCHITECTURE SPECIFICATION
|
||||
NexusGuard is a private network orchestrator. It uses WireGuard for tunneling but abstracts it away for the user. It enforces security via `nftables` at the server level and hardware-binding at the agent level.
|
||||
|
||||
### Key Features (Must Implement):
|
||||
- **Zero-Trust Isolation:** Every user has their own `nftables` set. Peers in different sets cannot communicate by default.
|
||||
- **Stealth Agent:** No `/etc/wireguard` files. Configuration exists only in memory.
|
||||
- **Dynamic Firewall:** Support for Port Ranges, IP Ranges, and CIDR via `nftables` Verdict Maps.
|
||||
- **UDP Hole Punching:** STUN-based coordination for NAT-to-NAT P2P connection.
|
||||
- **Hitless Key Rotation:** 30-day automated rotation with a 5-minute grace period.
|
||||
|
||||
---
|
||||
|
||||
## 2. REPOSITORY SPECIFICATIONS
|
||||
|
||||
### [REPO 1] nexus-server-core (The Control Plane)
|
||||
- **Stack:** Go (Gin), PostgreSQL (GORM), Redis, `google/nftables` library.
|
||||
- **Responsibilities:**
|
||||
- **API:** Provisioning, Device Management, Rule Management.
|
||||
- **IPAM:** Automatic /32 IP assignment for WireGuard peers.
|
||||
- **Hook Engine:** Listens for rule updates and applies them to `nftables` dynamically.
|
||||
- **Firewall Logic:** Use `nftables` sets for user isolation and `vmaps` for granular port access.
|
||||
- **Migration Readiness:** Provide `docs/API_SPEC.md` using OpenAPI/Swagger format so the API can be migrated to PHP in the future.
|
||||
|
||||
### [REPO 2] nexus-dashboard-ui (The Client Management)
|
||||
- **Stack:** Vue.js 3 (Vite), Pinia, Tailwind CSS, Capacitor.js.
|
||||
- **Responsibilities:**
|
||||
- **Multi-Platform:** Web Dashboard and Android App (via Capacitor).
|
||||
- **Device Lifecycle:** Register new devices, generate registration tokens, monitor heartbeat status.
|
||||
- **Firewall UI:** Intuitive interface to manage "Allow Internet" and "Peer-to-Peer Access" rules.
|
||||
|
||||
### [REPO 3] nexus-device-agent (The Stealth Edge)
|
||||
- **Stack:** Go, `wireguard-go` (embedded library).
|
||||
- **Responsibilities:**
|
||||
- **Identity:** Generate HWID based on hardware metadata (CPU/Disk).
|
||||
- **Provisioning:** One-time use registration token to exchange for an encrypted WG Config.
|
||||
- **Memory-Only:** Use `device.NewDevice` to inject config. Never write keys to disk.
|
||||
- **Auto-Healing:** Detect handshake failure and trigger re-provisioning or STUN punching.
|
||||
|
||||
---
|
||||
|
||||
## 3. DATABASE SCHEMA (PostgreSQL)
|
||||
Ensure the AI implements these relations:
|
||||
- `users` (1:N) `devices`
|
||||
- `devices` (1:N) `firewall_rules`
|
||||
- `devices` (N:1) `wg_servers` (For multi-hop support)
|
||||
|
||||
---
|
||||
|
||||
## 4. AGENT.MD (Instructions for AI Sub-Agents)
|
||||
*Save this part into each repository to guide the AI development.*
|
||||
|
||||
```markdown
|
||||
# Agent Instructions: NexusGuard Module Development
|
||||
|
||||
## General Coding Standards
|
||||
- **Clean Code:** Use SOLID principles. Interfaces for Network and Storage.
|
||||
- **Error Handling:** Structured JSON logging. No `panic()`.
|
||||
- **Security:** Use AES-256-GCM for any sensitive data transmission.
|
||||
- **Concurrency:** Use Go Channels for STUN keep-alive and Handshake monitoring.
|
||||
|
||||
## Specific Task Focus
|
||||
### If you are developing REPO_SERVER:
|
||||
- Focus on the `nftables` manager. Ensure it doesn't flush the entire table, only update specific sets/elements to prevent network blips.
|
||||
- Implement Redis-based heartbeat to track device 'Online' status.
|
||||
|
||||
### If you are developing REPO_AGENT:
|
||||
- Focus on `wireguard-go` integration. Ensure the process name is obfuscated.
|
||||
- Implement a 'Graceful Handover' logic for Key Rotation.
|
||||
|
||||
### If you are developing REPO_UI:
|
||||
- Ensure the API client is modular. All calls must go through a central `services/api.ts` to allow easy base-URL changes.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. OPTIMIZATION FOR OPENCODE & DEVOPS
|
||||
- **CI/CD:** Provide a GitHub Action / Gitea Action template to build static binaries for `linux/amd64` and `linux/arm64`.
|
||||
- **Private Pull:** Provide a Bash script using `X-Token-Auth` header to fetch the agent binary from a private Gitea instance.
|
||||
- **Environment:** Use `.env` files for all secrets. Provide `.env.example` in all repos.
|
||||
|
||||
---
|
||||
|
||||
## 6. EXECUTION STEPS FOR AI
|
||||
1. **Phase 1:** Generate the PostgreSQL GORM models and the basic Gin API structure for Repo 1.
|
||||
2. **Phase 2:** Implement the `nftables` Set/Map management logic in Go.
|
||||
3. **Phase 3:** Create the Vue 3 dashboard boilerplate with Capacitor integration for Repo 2.
|
||||
4. **Phase 4:** Build the core WireGuard tunneling logic using the `wireguard-go` library for Repo 3.
|
||||
5. **Phase 5:** Implement the STUN Signaling flow between Agent and Server.
|
||||
|
||||
---
|
||||
|
||||
**Prompt Final:**
|
||||
*"AI, please start by generating the **Entity Relationship Diagram (ERD)** in Mermaid format and the **PostgreSQL Migrations** for REPO_SERVER that support multi-user isolation and granular firewall rules as described above."*
|
||||
|
||||
---
|
||||
|
||||
### Review Akhir:
|
||||
Sistem ini sekarang memiliki **pemisahan tanggung jawab (Separation of Concerns)** yang sempurna:
|
||||
1. **Repo Server** (Backend/DevOps) - Mengurus kernel dan data.
|
||||
2. **Repo UI** (Frontend/Mobile) - Mengurus interaksi user.
|
||||
3. **Repo Agent** (System/Embedded) - Mengurus konektivitas di alat.
|
||||
|
||||
Dengan dokumentasi **OpenCode** ini, divisi mana pun bisa masuk ke kodenya, membacanya, dan melakukan improvisasi tanpa merusak dependensi repositori lain.
|
||||
|
||||
Reference in New Issue
Block a user