Scaffold for troubleshooting MakerFLOSS hosts at the makerspace. Reference + thin runbooks model — authoritative data stays in the source repos (AnsibleBaobabV4, MakerFLOSS_Mikrotik, MakerFLOSS). - access.md: reach paths for mamba-on-LAN and fisi-tunneling-in (netbird on-demand, VPS bastion, ProxyJump via kuku->mamba), with the isolation rule. - network-map.md: subnet pointers + open question on makerspace addressing (10.2.30/172.17.3/10.0.0). - runbooks/switch-crs310.md: CRS310 connectivity + lockout recovery. - incidents/: dated log scaffold. - CLAUDE.md: operating rules for this repo. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
43 lines
2.7 KiB
Markdown
43 lines
2.7 KiB
Markdown
# Network map (thin)
|
||
|
||
Pointers, not the source of truth. Authoritative data is in the source repos —
|
||
links below. Confirm live values before acting.
|
||
|
||
## Subnets seen across the repos
|
||
|
||
| Subnet | Role | Source of truth |
|
||
|--------|------|-----------------|
|
||
| `10.2.30.0/24` | **CRS310 data VLAN 30** (the new switch). Uplink `ether1` → gateway `10.2.30.1`; access ports `ether2–7`. | `MakerFLOSS_Mikrotik/host_vars/crs310-maker.yml`, `docs/superpowers/specs/2026-06-09-crs310-flat-mgmtvlan-design.md` |
|
||
| `192.168.88.0/24` | **CRS310 mgmt VLAN 99** — isolated, switch at `192.168.88.1`, reachable only from `ether8`. DHCP `.10–.254`. | same |
|
||
| `172.17.3.0/24` | OrangeMakers LAN — `makerfloss1` at `.51`. | `AnsibleBaobabV4/host_vars/makerfloss1.yml` |
|
||
| `10.0.0.0/24` | Makerspace LAN — `mf04` at `.184`. | `AnsibleBaobabV4/host_vars/mf04.yml` |
|
||
| `10.13.0.0/24` | **makerfloss WireGuard plane (`wg1`)**. Hub `10.13.0.1` (VPS), `makerfloss1` `.2`, `mf04` `.3`, `sjat-roaming` `.5`. UDP `:51820`. | `AnsibleBaobabV4/host_vars/makerfloss.yml`, `specs/2026-05-12-makerfloss-wireguard-design.md` |
|
||
| `100.92.0.0/16` | **Netbird overlay** (`wt0`), control plane `nb.makerfloss.eu`. | `specs/2026-05-27-makerspace-vpn-design.md` |
|
||
| `10.8.0.0/24` | baobab (home) WireGuard plane. Hub **kuku** `10.8.0.1` (UDP `:51194`); mamba `10.8.0.4`. | `AnsibleBaobabV4` |
|
||
| `10.20.10.0/24` | homelab LAN — **fisi** `.17`, kuku `.118`, papa `.11`. | `AnsibleBaobabV4` |
|
||
|
||
## ⚠️ Open question — makerspace addressing
|
||
|
||
The makerspace shows **three different subnets** for hosts that are all
|
||
physically there: `10.2.30.0/24` (new CRS310 data VLAN), `172.17.3.0/24`
|
||
(`makerfloss1`), and `10.0.0.0/24` (`mf04`). It's not yet documented here how
|
||
they relate — i.e. whether the new switch sits in front of the existing
|
||
OrangeMakers `172.17.3.x` / `10.0.0.x` network, replaces part of it, or is a
|
||
parallel segment.
|
||
|
||
**To resolve (sjat to confirm on-site):**
|
||
- What IP does an ethernet client on the new switch's data ports (`ether2–7`)
|
||
actually get, and from which DHCP server / gateway?
|
||
- Are `makerfloss1` (`172.17.3.51`) and `mf04` (`10.0.0.184`) reachable from a
|
||
data-port client on the new switch, or are they on a different segment?
|
||
- Is the `10.2.30.1` uplink gateway the OrangeMakers router, or something new?
|
||
|
||
Update this section (and the host IPs in [access.md](access.md)) once confirmed.
|
||
|
||
## Public services (makerfloss VPS, `88.99.32.236`)
|
||
|
||
All TLS-terminated at the VPS via Traefik, certs via Gandi DNS-01:
|
||
`docs.makerfloss.eu`, `slides.makerfloss.eu`, `forgejo.makerfloss.eu` (git SSH
|
||
`:7577`), `mail.makerfloss.eu` (Poste.io), `discourse.makerfloss.eu`,
|
||
`snipeit.makerfloss.eu`, `nb.makerfloss.eu` (Netbird).
|
||
Source: `AnsibleBaobabV4/host_vars/makerfloss.yml`.
|