From 70a983eaa31e9a333e55f1b8436f9a6985758034 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 30 Aug 2026 12:29:35 +0200 Subject: [PATCH] F4 praezisiert: n8n-mcp blockt private IPs per SSRF-Schutz Gefunden mit derselben Abnahme-Methode wie der gitea-mcp-Token: ein echter tools/call statt nur initialize. n8n_health_check -> "SSRF protection: Private IP addresses not allowed" fuer apiUrl http://n8n:5678. Damit ist die Container-DNS-Adresse des laufenden Containers gar nicht funktionsfaehig, und mein urspruenglicher F4-Vorschlag (genau diese URL im Compose festschreiben) haette den kaputten Zustand zementiert. Umgekehrt war https://n8n.emsenhuber.net im Compose vermutlich Absicht - oeffentliche Adresse passiert den Schutz - nur eben ueber den CF-Umweg, was TP16.3 gerade abbauen will. F4 ist damit ein Zielkonflikt, kein reines Datei-Angleichen. Ausfallumfang: Doku-Tools laufen (search_nodes ok, das ist die Hauptfunktion), nur die n8n_*-Management-Tools sind tot. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 5acb28b..3a22dec 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -573,7 +573,17 @@ und Letzteres verlangt die **physische Bestätigung am Gerät** — ap1 Technik | `docker-compose.yml` | `https://n8n.emsenhuber.net` (hartkodiert, ignoriert die `.env`) | `web` | `${HOST_PORT:-3000}` | | **laufender Container** | `http://n8n:5678` ← korrekt, Container-DNS | `n8n_default` | `3001` | - Zu tun: Netz als `external: true` auf `n8n_default`, `N8N_API_URL` aus der Env statt hartkodiert, + 🔴 **Vorsicht — die naheliegende Lösung ist die falsche.** Ein `tools/call n8n_health_check` (statt + nur `initialize`) zeigt: **n8n-mcp hat einen SSRF-Schutz und lehnt private Adressen ab** — + `"SSRF protection: Private IP addresses not allowed", apiUrl: http://n8n:5678`. Die + Container-DNS-Adresse des laufenden Containers **funktioniert also gar nicht**; sie im Compose + festzuschreiben würde den Zustand zementieren, nicht heilen. Umgekehrt war + `https://n8n.emsenhuber.net` im Compose vermutlich **Absicht**, kein Drift — nur eben über den + CF-Umweg, was der TP16.3-Stossrichtung zuwiderläuft. Ein Abschalter für den Schutz ist im Image + nicht ersichtlich (nur `TRUST_PROXY`). **F4 muss diesen Zielkonflikt lösen**, nicht nur Dateien angleichen. + ⚠️ **Aktueller Ausfallumfang:** die **Doku-Tools laufen** (`search_nodes` ✅ — das ist die + Hauptfunktion von `n8n-documentation-mcp`), nur die **n8n-Instanz-Management-Tools** (`n8n_*`) sind tot. + Zu tun: Netz als `external: true` auf `n8n_default`, `N8N_API_URL` **erst nach Klärung des SSRF-Punkts**, Image auf den laufenden Digest pinnen (`sha256:2c8ff077…` = v2.57.1; heute `:latest` + `pull_policy: always`, was bei jedem Recreate unkontrolliert hochzieht), Bind auf `10.40.20.167`. ⚠️ **`N8N_API_KEY` ist in allen drei Quellen verschieden**; der laufende und der aus