MakerFLOSS_Troubleshooting/access.md

# 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.

Key state (2026-08-16): ubongo's `claude` key (`~/.ssh/id_ed25519.pub`,
`claude@ubongo`) is appended to `~sjat/.ssh/authorized_keys` on **both the VPS
and mf01** — done by hand via mamba, *not* via the users catalog in
`AnsibleBaobabV4/group_vars/all/50-users_catalog.yml`, which still lists only
the mamba + phone keys. A users-play run against those hosts will drop it again
unless the catalog is updated first (TODO). Verified working end-to-end from
ubongo the same day.

### 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.