root
9c0b7e597c
- horus/README.md: Dienst-Discovery (mailcow, bind9, NPM, authentik, hedgedoc, apps), Zugang, WG-Verwaltung (kein wireguard-ui aktiv), watchtower-Problem - issues/: Tracking-Konvention + Vorfall VM101<->Horus WireGuard (Ursache war NAT/Quellport, nicht Keys; Fix ListenPort 51871) - README.md: Horus in Hosts-Tabelle + Verzeichnisbaum - shared/horus-opnsense-wireguard: Key-Verwechslungs-Warnungen Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
74 lines
4.0 KiB
Markdown
74 lines
4.0 KiB
Markdown
# VM 101 ↔ Horus WireGuard tot — Ursache war NAT, nicht die Keys
|
|
|
|
**Datum:** 2026-06-28
|
|
**Status:** gelöst
|
|
**Betroffen:** WireGuard-Tunnel VM 101 (`server5`, `10.1.1.5`) ↔ Horus VPS (`10.1.1.1`)
|
|
|
|
---
|
|
|
|
## Symptom
|
|
|
|
- `ping 10.1.1.1` von VM 101 → 100 % Loss, **0 Bytes empfangen**
|
|
- WireGuard-Handshake auf VM 101 kam nie zustande (latest handshake blieb stehen)
|
|
- Der **OPNsense**-Tunnel zu Horus (`10.1.1.22`) lief dagegen normal weiter
|
|
|
|
## Falsche Spur (kostete viel Zeit)
|
|
|
|
Das Vorgänger-Handover führte alles auf **Key-/PSK-Chaos** zurück („kimi hat die Keys verstellt"). Das war für **dieses** Problem **falsch**:
|
|
|
|
- VM-101-Seite: PrivateKey → Pubkey `VB3Cf8kD…`, PSK `xeXr67…` — korrekt
|
|
- Horus-Seite (Peer `VB3Cf8kD…`): **identischer** PSK `xeXr67…`, korrekte AllowedIPs `10.1.1.5/32, 10.2.2.0/24`
|
|
- Probeweises Setzen anderer PSKs (OPNsense-PSK `fBnIJ…`, leer) brachte **keinen** Handshake → es war kein Crypto-Problem
|
|
|
|
## Diagnose, die zur Wahrheit führte
|
|
|
|
Mit Root auf Horus (Zugang siehe unten) Paketfluss direkt gemessen:
|
|
|
|
```
|
|
# Auf Horus, tcpdump während VM 101 sendet:
|
|
In 93.199.218.174:46165 → 207.180.222.207:61951 UDP len 148 (Handshake-Init kommt an)
|
|
Out 207.180.222.207:61951 → 93.199.218.174:46165 UDP len 92 (Handshake-Response geht raus)
|
|
# Auf VM 101 gleichzeitig: In = 0 (Antwort kommt NIE an)
|
|
```
|
|
|
|
→ **Hinweg VM 101 → Horus OK, Rückweg Horus → VM 101 tot.** Horus antwortete korrekt an den Quellport (`:46165`), aber das Paket erreichte VM 101 nie.
|
|
|
|
## Echte Ursache
|
|
|
|
VM 101 sitzt hinter OPNsense (NAT). Ihr WireGuard nutzte den **festen** Quellport `61951`, der **konstant** auf WAN-Port `46165` ge-NAT-et wurde. Durch kimis `qm stop 104` + manuelle Wiederherstellung wurde der **NAT-/State-Tisch von OPNsense durchgewirbelt** — diese eine, langlebige Zuordnung `61951↔46165` war danach **verwaist**: Hinweg funktionierte, der Rückweg lief ins Leere.
|
|
|
|
Da **UDP** verbindungslos ist, merkte WireGuard nichts und sendete endlos weiter, ohne je eine Antwort zu sehen. (Bezeichnend: **TCP-SSH** von VM 101 zu Horus' Public-IP ging — frischer Zufalls-Port = frische, gesunde NAT-Zuordnung.)
|
|
|
|
## Lösung
|
|
|
|
**Frischen Quellport auf der Client-Seite erzwingen** → neue, saubere NAT-Zuordnung:
|
|
|
|
```bash
|
|
# Auf VM 101:
|
|
sudo wg set wg0 listen-port 51871 # Live-Test → Handshake sofort da
|
|
sudo sed -i 's/^ListenPort = 61951/ListenPort = 51871/' /etc/wireguard/wg0.conf # persistent
|
|
```
|
|
|
|
- **Nur Client-Seite (VM 101) geändert.** Horus' Port `61951` und alle Keys blieben unverändert.
|
|
- **Kein** Eingriff an OPNsense / VM 104.
|
|
- Reboot-getestet: `systemctl restart wg-quick@wg0` → kommt auf `51871` hoch, Handshake < 3 s.
|
|
|
|
## Verifikation
|
|
|
|
- `ping 10.1.1.1` von VM 101 → 3/3, ~24 ms
|
|
- SSH durch den Tunnel (`ssh root@10.1.1.1`) wieder OK
|
|
- Überlebt wg-Neustart
|
|
|
|
## Nützliche Zugangswege (für nächstes Mal)
|
|
|
|
- **Horus Root, wenn Tunnel läuft:** `ssh jean@192.168.10.10` → `ssh root@10.1.1.1`
|
|
- **Horus Root, wenn Tunnel tot ist:** über die **Public-IP** `ssh root@207.180.222.207` — aber nur erreichbar, wenn auf Horus per ufw Port 22 offen ist (Notfall: am Contabo-VNC `ufw allow ssh`, danach wieder `ufw delete allow ssh`). VM 101 hat den Horus-SSH-Key, geht also auch von dort über die Public-IP.
|
|
- **Horus WireGuard wird per `wireguard-ui` verwaltet**, Config-Datei `/etc/wireguard/wg0.conf` (nicht manuell editieren — wird regeneriert). Live-Kernel vs. Datei können auseinanderlaufen; Wahrheit ist `wg show wg0` / `wg showconf wg0`.
|
|
- VM 101 hat **kein** wireguard-ui — nur `wg-quick@wg0`.
|
|
|
|
## Prävention / offene Risiken
|
|
|
|
- Der eigentliche Übeltäter — **OPNsenses fragiler NAT/CARP-Zustand nach dem VM-104-Stop** — besteht weiter. Wird dort erneut State geflusht (Reboot/Failover), kann ein WireGuard-Tunnel wieder „einschlafen". Workaround dann: Client-Port wechseln.
|
|
- Lehre: Bei „Handshake-Init kommt an, aber 0 empfangen" **zuerst den Rückweg/NAT prüfen** (tcpdump auf beiden Seiten), nicht stundenlang an PSK/Keys.
|
|
- **VM 104 / OPNsense** nie per `qm stop/start` anfassen (Auslöser dieses ganzen Vorfalls).
|