anti/DECNET
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: Detail attachable Swarm overlay backend in FUTURE.md

Browse Source
This commit is contained in:
anti
2026-04-10 03:00:03 -04:00
parent fa8b0f3cb5
commit 38d37f862b
1 changed files with 21 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
development/FUTURE.md
View File

@@ -40,3 +40,24 @@ By procedurally generating `tc` rules as the network scales, we can inject mathe
tc qdisc add dev eth1 root netem delay 45ms 10ms distribution normal loss 0.1% tc qdisc add dev eth1 root netem delay 45ms 10ms distribution normal loss 0.1%
``` ```
As an attacker pivots deeper into the "Spider Network," this injected latency compounds automatically. A proxy chain going 4 levels deep would realistically suffer from 150ms+ of latency and erratic jitter, perfectly mimicking the experience of routing over slow, multi-site corporate VPNs. As an attacker pivots deeper into the "Spider Network," this injected latency compounds automatically. A proxy chain going 4 levels deep would realistically suffer from 150ms+ of latency and erratic jitter, perfectly mimicking the experience of routing over slow, multi-site corporate VPNs.
---
## Distributed Scale: Swarm Overlay Architecture
To scale DECNET across multiple physical racks or sites, DECNET can leverage **Docker Swarm Overlay Networks** to create a unified L2/L3 backbone without surrendering control to Swarm's "Orchestration" scheduler.
### The `--attachable` Paradigm
By default, Docker's `overlay` driver requires Swarm mode but tightly couples it to `docker service` (which abstracts and randomizes container placement to balance loads). In honeypot deployments, absolute control over physical placement is critical (e.g., placing the `scada-archetype` explicitly on bare-metal node C in the DMZ).
To solve this, DECNET will initialize the swarm control plane simply to construct the backend VXLAN, but completely ignore the service scheduler in favor of `--attachable` networks:
1. **Initialize the Control Plane** (manager node + remote worker joins):
```bash
docker swarm init
```
2. **Create the Attachable Backbone**:
```bash
docker network create -d overlay --attachable decnet-backbone
```
3. **Deploy Standalone**: Keep relying entirely on local `decnet deploy` scripts on the individual physical nodes. Because the network is `attachable`, standalone container instances can seamlessly attach to it and communicate with containers running on completely different hardware across the globe as if they were on a local layer 2 switch!