sjat/MakerFLOSS_Troubleshooting
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
MakerFLOSS_Troubleshooting/access.md
sjat 2194a26970 access: rewrite for the ubongo era; srv07 incident; refresh network map 
fisi is decommissioned and boma retired Netbird (ADR-036), so the old
Claude-on-fisi/Netbird access doctrine is gone. New order: VPS bastion
ProxyJump onto wg1 (primary, isolation-clean), via mamba over the boma hub
when on-site. Netbird control plane kept but demoted to legacy (operator
decision, not an access path). Network map refreshed from live probing
2026-07-17: rack LAN is 10.0.0.0/24, wifi 172.17.3.0/24 does not route to
it, 10.2.30.0/24 likely gone. Incident log covers the srv07/mf04 identity
fix and re-established access.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 17:23:18 +02:00

140 lines
6.8 KiB
Markdown
Raw Blame History

# Access — reaching MakerFLOSS / makerspace hosts
How to get a shell on the hosts we troubleshoot, from each place you might be
working. **Read the section that matches your situation.**
Rewritten 2026-07-17 for the ubongo era (fisi decommissioned, boma ADR-036).
Live-verified facts are dated; everything else is best-known and can drift.
There are two actors:
- **You (sjat)** — at the makerspace with **mamba** (laptop), or elsewhere.
- **Claude** — lives on **ubongo** (homelab control node, `10.20.10.151`) and
must *tunnel in* to help at the makerspace. fisi is gone; anything that
says fisi is stale.
---
## The hosts and where they live
| Host | Address | SSH | Where it sits | Notes |
|------|---------|-----|---------------|-------|
| **makerfloss VPS** | `88.99.32.236` / `makerfloss.eu` | `:7576` | Public (Hetzner) | Public entrypoint + bastion. Forgejo on `:7577`. `wg1` hub `10.13.0.1` (UDP `51820`). Netbird control plane `nb.makerfloss.eu` (**legacy — kept for now**, see §D). |
| **srv07** (ex-mf04) | wg1 **`10.13.0.3`** (canonical); rack LAN `10.0.0.183` (DHCP) | `:7576` | Makerspace rack (rack01, shf02/1) | Testmachine, Debian 13. Renamed mf04 → srv07 on 2026-07-17 (matches sticker). wg unit `wg-quick@mf-srv07` auto-dials the VPS on boot. |
| **mf01** (docs: srv02) | wg1 `10.13.0.8`; rack LAN `10.0.0.223` (DHCP) | `:7576` | Makerspace rack | Docker/dev host, publishes `*.mf01.makerfloss.eu` via the VPS. OS hostname still `mf01`. |
| **makerfloss1** | recorded `172.17.3.51` | `:7576` | OrangeMakers LAN? | **Did not answer 2026-07-17** (LAN or wg1 `.2`). Status unknown — verify on-site before relying on it. |
| **flossfw** | wg1 `10.13.0.9`; likely the rack gateway `10.0.0.1` | `:22` | Makerspace rack | TaPPaaS FLOSSFirewall (FreeBSD). wg1 peer down 2026-07-17. See `runbooks/` for peer-key swap on operator onboarding. |
| **crs310-maker** (switch) | mgmt `192.168.88.1` | `:22` | Makerspace rack (sw01) | Mgmt VLAN reachable only from the mgmt port (sw01 p8, patched out via pp01:3, currently non-active). Rack re-cabling means the switch runbook may be stale — verify on-site. |
| **mamba** (laptop) | LAN-dependent | `:7576` | Roams | boma wg spoke **`10.99.0.10`** (how Claude reaches it anywhere); makerfloss `wg1` roaming peer `10.13.0.5` (profile dormant, hub still has the peer); Netbird peer (legacy). |
The rack LAN is `10.0.0.0/24` (gw `.1`). Also seen there 2026-07-17: a trio of
fresh Debian 13 boxes at `.10/.11/.12` (ssh `:22`, unidentified — likely
TaPPaaS cluster nodes) and unidentified ssh hosts at `.158/.165/.209`.
---
## A. You're at the makerspace with mamba
**Plug in the cable.** Wired, mamba lands on the rack LAN (`10.0.0.0/24`).
The wifi (`172.17.3.0/24`, OrangeMakers house LAN) does **not** route to the
rack LAN (verified 2026-07-17) — wifi-only is not enough.
```bash
ssh -p 7576 sjat@10.0.0.183 # srv07 by its current DHCP lease
ssh -p 7576 sjat@10.0.0.223 # mf01
```
The leases are DHCP and can drift; the wg1 addresses (§B) are the stable
names. If a box doesn't answer, check the physical layer first — srv07 was
dark for weeks because its patch-panel run lost its rear patch (see
`incidents/2026-07-17-srv07-access.md`).
## B. You're roaming (anywhere with internet)
Single hop via the VPS bastion — works with your normal key, nothing to
bring up first:
```bash
ssh -J sjat@makerfloss.eu:7576 -p 7576 sjat@10.13.0.3 # srv07
ssh -J sjat@makerfloss.eu:7576 -p 7576 sjat@10.13.0.8 # mf01
```
This rides each box's own always-on `wg1` tunnel to the VPS, so it survives
makerspace LAN renumbering. Verified end-to-end 2026-07-17.
Alternative: bring up mamba's own `wg1` roaming profile (`10.13.0.5`, config
hand-deployed on mamba) and reach `10.13.0.x` directly without the jump. The
hub still carries the peer; the profile has simply not been up lately.
## C. Claude tunneling in from ubongo
Ordered by preference under the **isolation rule** (§E). ubongo has **no
Netbird agent** (removed estate-wide, boma ADR-036) — the old fisi/Netbird
path is gone.
### C1. VPS bastion (primary)
Same as §B: ubongo only ever talks to the public VPS, which hops onward over
`wg1`. No makerspace network ever exists on ubongo.
```bash
ssh -J sjat@makerfloss.eu:7576 -p 7576 sjat@10.13.0.3 # srv07
```
First use on a fresh control node: accept/pin `makerfloss.eu`'s host key.
### C2. Via mamba (when mamba is at the makerspace)
ubongo reaches mamba anywhere over the **boma wg hub** (`ssh mamba` =
`10.99.0.10:7576`, pinned in the boma-managed ssh config). If mamba is wired
at the makerspace, hop onward to the rack LAN:
```bash
ssh -o ProxyJump=mamba -p 7576 sjat@10.0.0.183 # srv07 via mamba
```
Useful when the VPS or a box's wg1 tunnel is down but the LAN is up (this is
how srv07 was found and fixed on 2026-07-17). Breaks when mamba leaves.
### Choosing
| Need | Use |
|------|-----|
| Reach srv07/mf01/VPS services, any time | **C1** (bastion) |
| Box's wg1 is down / raw LAN work, mamba on-site | **C2** (via mamba) |
| The switch mgmt plane | Neither directly — needs a host on the mgmt port; see the switch runbook and verify the post-recabling mgmt path on-site. |
---
## D. Netbird (legacy — kept, not used for access)
The self-hosted control plane `nb.makerfloss.eu` still runs on the VPS, and
srv07's agent is still enrolled (`100.99.133.190`). It is **no longer an
access path**: fisi (the only Claude-side peer) is decommissioned, ubongo is
deliberately not enrolled (isolation + boma ADR-036 doctrine: static
WireGuard, config-as-code, no coordinator). Operator decision 2026-07-17:
keep it running for now; do **not** enroll new peers for management access.
Retirement is the eventual direction — that decision is logged, not taken.
## E. Isolation rule (unchanged, important)
> **Keep the makerspace and the homelab apart.** ubongo must not hold a
> standing tunnel into the makerspace and must not join makerspace overlays
> (wg1, Netbird). The bastion path (C1) puts no makerspace network on ubongo
> at all; the mamba path (C2) rides boma's own hub and ends at mamba. The
> concern is preventing any compromise at the makerspace from reaching the
> homelab.
## F. Secrets & credentials (where they live — not stored here)
- **Ansible vault (baobab/prod):** `~/.ansible/vault-keys/prod.txt` (present
on ubongo); secrets in `AnsibleBaobabV4/group_vars/all/90-secrets.vault.yml`.
WG/Netbird/service secrets are `vault_*` keys there
(`vault_wireguard_makerfloss_peers.*` — srv07's keypair is still under the
historical name `mf04`).
- **Ansible vault (switch):** identity `makerfloss`,
`~/.ansible/vault-keys/makerfloss.txt`; switch admin password in
`MakerFLOSS_Mikrotik/group_vars/mikrotik.vault.yml`.
- **SSH:** operator key `~/.ssh/id_ed25519`; project-wide SSH port is **7576**
(switch SSH `:22`, flossfw `:22`, Forgejo git `:7577`).
Never commit secrets to this repo.
Reference in a new issue View git blame Copy permalink