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>
168 lines
6.8 KiB
Markdown
168 lines
6.8 KiB
Markdown
# Horus ↔ OPNsense WireGuard (Site-to-Site)
|
||
|
||
Direkter WireGuard-Tunnel zwischen **OPNsense** (lokales Netz) und **Horus** (VPS), ohne Umweg über VM 101.
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Horus** | `horus.jeanavril.com` / `207.180.222.207`, WG-Port **61951**, Tunnel-IP **10.1.1.1** |
|
||
| **OPNsense** | Tunnel-IP **10.1.1.22** (Peer `opnsense-jeanavril`) |
|
||
| **VM 101** (legacy) | Tunnel-IP **10.1.1.5** (Peer `server5`) — **eigener Tunnel**, bleibt |
|
||
|
||
Configs inkl. Private Keys: **privates Repo** — siehe Dateien in diesem Ordner.
|
||
|
||
## Keys nicht verwechseln (VM ≠ OPNsense)
|
||
|
||
Zwei getrennte Tunnel = **zwei getrennte Keypairs**. Horus kennt jeden Peer nur über den **Public Key**.
|
||
|
||
| Tunnel | Private Key (Datei) | Public Key (muss in GUI stehen) |
|
||
|--------|-------------------|----------------------------------|
|
||
| **OPNsense** `10.1.1.22` | `opnsense-client.conf` → `AGEam06B9…` | `walbWTYXAGOD1mOxPK+NwKT6qUhLyY0qieWBeTIbdXU=` |
|
||
| **VM 101** `10.1.1.5` | `vm101-client.conf` → `SKMnLpkj…` | `VB3Cf8kDxpzO+FyMrLxPyJ0vUjm8yJ/qIKmhY2KeeyI=` |
|
||
|
||
**Falscher Private Key auf OPNsense** → GUI zeigt evtl. trotzdem einen Public Key, Horus antwortet aber nicht zum richtigen Peer → Symptom: **Bytes gesendet, 0 empfangen, kein Handshake**.
|
||
|
||
OPNsense-Instanz: Private Key **nur** aus `opnsense-client.conf`, **nicht** aus `vm101-client.conf`.
|
||
|
||
## Subnetz-Aufteilung (kein Teilen zwischen Peers)
|
||
|
||
| Netz | Horus-Peer | Wer routet |
|
||
|------|------------|------------|
|
||
| `10.1.1.5/32` | VM | VM-WG-Tunnel |
|
||
| **`10.2.2.0/24`** (docbr0) | **VM** | VM → docbr0; OPNsense nur `→ 192.168.10.10` im LAN |
|
||
| `10.1.1.22/32` | OPNsense | OPNsense-WG-Tunnel |
|
||
| `10.100.2.0/24` (Services pve2) | OPNsense | OPNsense opt7 |
|
||
| `192.168.10–60.0/24` (VLANs) | — (nicht auf Horus) | OPNsense **NAT** → Horus sieht nur `10.1.1.22` |
|
||
|
||
**Schritt A (NAT):** Horus ✅ · OPNsense → [opnsense-step-a-nat.md](opnsense-step-a-nat.md)
|
||
|
||
**Nicht:** `10.2.0.0/16` auf VM-Peer — war zu groß; nur **`10.2.2.0/24`**.
|
||
|
||
| Datei | Inhalt |
|
||
|-------|--------|
|
||
| [opnsense-client.conf](opnsense-client.conf) | OPNsense Client (Private Key, PSK, Endpoint) |
|
||
| [horus-server-peer-opnsense.conf](horus-server-peer-opnsense.conf) | Gegenstück auf Horus |
|
||
| [vm101-client.conf](vm101-client.conf) | VM 101 Client (Referenz / Migration) |
|
||
| [horus-server-peer-vm101.conf](horus-server-peer-vm101.conf) | VM-Peer auf Horus |
|
||
|
||
## Topologie
|
||
|
||
```
|
||
LAN/VLANs (192.168.x.0/24, 10.2.2.0/24)
|
||
↓
|
||
OPNsense (10.1.1.22) ←——WireGuard——→ Horus (10.1.1.1)
|
||
↓ ↓
|
||
10.2.2.0/24 → 192.168.10.10 (docbr0) Services / SSH / …
|
||
```
|
||
|
||
**10.2.2.0/24 (docbr0):** Horus schickt Traffic dorthin an OPNsense; OPNsense leitet weiter an **192.168.10.10** (bestehende Route/Gateway `VM101_DOCKER` — siehe [opnsense-docker-subnet-routing.md](../opnsense-docker-subnet-routing.md)).
|
||
|
||
## Public Keys
|
||
|
||
| Rolle | Public Key |
|
||
|-------|------------|
|
||
| Horus (Server) | `qXxhgerS2ORypVadhKCBuxgIX5Pu4J75nSWazdtd+Qk=` |
|
||
| OPNsense | `walbWTYXAGOD1mOxPK+NwKT6qUhLyY0qieWBeTIbdXU=` |
|
||
| VM 101 | `VB3Cf8kDxpzO+FyMrLxPyJ0vUjm8yJ/qIKmhY2KeeyI=` |
|
||
|
||
## OPNsense einrichten
|
||
|
||
Werte aus [opnsense-client.conf](opnsense-client.conf) in die GUI übernehmen.
|
||
|
||
**VPN → WireGuard → Local → +**
|
||
|
||
| Feld | Wert |
|
||
|------|------|
|
||
| Enabled | ✓ |
|
||
| Name | `wg_horus` |
|
||
| Listen port | leer oder `51820` (nur ausgehend nötig) |
|
||
| Tunnel Address | `10.1.1.22/32` |
|
||
| MTU | `1250` |
|
||
| Private key | `[Interface] PrivateKey` aus `opnsense-client.conf` |
|
||
|
||
**VPN → WireGuard → Endpoints → +** (Peer Horus)
|
||
|
||
| Feld | Wert |
|
||
|------|------|
|
||
| Enabled | ✓ |
|
||
| Name | `horus` |
|
||
| Public Key | `qXxhgerS2ORypVadhKCBuxgIX5Pu4J75nSWazdtd+Qk=` |
|
||
| Shared Secret | `[Peer] PresharedKey` aus `opnsense-client.conf` |
|
||
| Allowed IPs | `10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24, 10.8.0.0/24` |
|
||
| Endpoint Address | `horus.jeanavril.com` |
|
||
| Endpoint Port | `61951` |
|
||
| Persistent Keepalive | `25` |
|
||
|
||
Instance und Endpoint verknüpfen (Peer der Instance zuweisen — je nach OPNsense-Version unter **Local → Peers** oder Endpoint an Instance binden).
|
||
|
||
### Interface zuweisen
|
||
|
||
**Interfaces → Assignments → New → `wg_horus` (optX) → Save**
|
||
|
||
Interface aktivieren, ggf. **Block private networks** auf WG-Interface deaktivieren (Site-to-Site).
|
||
|
||
### Firewall
|
||
|
||
| Regel | Interface | Direction | Source | Destination | Beschreibung |
|
||
|-------|-----------|-----------|--------|-------------|--------------|
|
||
| Pass | LAN / VLAN10 / … | in | Netz(e) | `10.1.1.0/24`, `10.8.0.0/24`, … | LAN → Horus-Netze |
|
||
| Pass | `optX` (WG) | in | `10.1.1.0/24` | LAN / VLANs | Horus → Heimnetz (Rückweg) |
|
||
|
||
### Routing auf Horus
|
||
|
||
Siehe [horus-server-peer-opnsense.conf](horus-server-peer-opnsense.conf) — bereits auf Horus aktiv.
|
||
|
||
## Test
|
||
|
||
```bash
|
||
# Handshake auf Horus:
|
||
ssh jean@192.168.10.10 'ssh root@10.1.1.1 wg show wg0 | grep -A6 walbWTYX'
|
||
|
||
# Von LAN-PC:
|
||
ping 10.1.1.1
|
||
ssh root@10.1.1.1
|
||
```
|
||
|
||
## Horus: fehlende WG-Routen (wichtig)
|
||
|
||
`wg syncconf` auf Horus legt **keine Kernel-Routen** für die OPNsense-`AllowedIPs` an. Ohne Fix gehen Antworten von Horus zu euren LANs über **eth0/Internet** statt **wg0**.
|
||
|
||
Symptom auf Horus: `ip route get 192.168.20.2` zeigt `via 207.180.222.1 dev eth0` statt `dev wg0`.
|
||
|
||
**Fix (auf Horus, persistent):**
|
||
|
||
```bash
|
||
/usr/local/sbin/wg0-opnsense-routes.sh # siehe wg0-opnsense-routes.sh in diesem Ordner
|
||
systemctl enable --now wg0-opnsense-routes.service
|
||
```
|
||
|
||
**iptables/ufw:** wg0 ist offen (61951/udp, `Anywhere on wg0` IN + FWD). Kein IP-spezifischer Block für 10.1.1.22.
|
||
|
||
## OPNsense: falsche Route (LAN → Horus)
|
||
|
||
Wenn der Tunnel steht, aber vom LAN nichts ankommt: oft eine **alte Static Route** auf OPNsense.
|
||
|
||
Traceroute von intern sollte sein: `… → OPNsense → 10.1.1.1` (via WG).
|
||
|
||
Falsch (beobachtet): Hop 2 = `192.168.178.1` — Traffic geht zur alten Fritz/VM-Route statt WireGuard.
|
||
|
||
**Prüfen:** System → Routes → Einträge für `10.1.1.0/24` / `10.8.0.0/24` — muss über **WireGuard-Gateway** (`horusopnsense`), nicht `192.168.178.1`.
|
||
|
||
**Firewall:** VLAN20 → Destination `10.1.1.0/24` → Pass.
|
||
|
||
## VM 101 — eigener Tunnel (bleibt)
|
||
|
||
VM 101 behält **eigenes** WireGuard zu Horus (`10.1.1.5`) — für Cert-Rsync, SSH, Automation.
|
||
|
||
Horus `AllowedIPs` VM-Peer: **`10.1.1.5/32`, `10.2.2.0/24` only** — siehe [horus-server-peer-vm101.conf](horus-server-peer-vm101.conf).
|
||
|
||
Wenn OPNsense stabil läuft: **kein** Abschalten der VM-WG nötig. Nur **keine überlappenden Subnetze** zwischen VM- und OPNsense-Peer auf Horus.
|
||
|
||
## Referenzen
|
||
|
||
| Thema | Doc |
|
||
|-------|-----|
|
||
| Horus SSH-Keys | [../ssh/README.md](../ssh/README.md#horus-vps-wireguard) |
|
||
| Route-Skript | [wg0-opnsense-routes.sh](wg0-opnsense-routes.sh) |
|
||
| docbr0 / 10.2.2.0/24 | [../../pve1/guests/vm101-ubuntu/docbr0-opnsense-routing.md](../../pve1/guests/vm101-ubuntu/docbr0-opnsense-routing.md) |
|
||
| VLAN-Übersicht | [../infrastruktur-netzwerk.md](../infrastruktur-netzwerk.md) |
|