name: nullfeld-qdrant-ollama-loopback-bind
description: "Qdrant + Ollama auf nullfeld: erst Loopback-only bestätigt, dann für crumbzero01 via wg0-scoped nginx-Proxy geöffnet (NICHT durch Rebind der Dienste selbst) — inkl. eines echten Fehlers unterwegs, der gefunden und korrigiert wurde"
metadata:
node_type: memory
type: project

Ursprungsfund (2026-08-12): Qdrant und Ollama auf nullfeld (194.164.194.191) lauschten ausschließlich auf 127.0.0.1, nicht auf 10.42.0.1 (wg0) oder 0.0.0.0. WireGuard-Peer crumbdesktop selbst war gesund, nur die Dienste dahinter waren loopback-only. Damals als sauberes Sicherheitsmuster bewertet (Kontrast zu MariaDBs *:3306).

2026-08-13, Versuch 1 — echter Fehler, live gefunden und korrigiert: Um crumbzero01 (10.42.0.21, per Pong-Ping-Test bestätigt online) direkten Zugriff auf Qdrant/Ollama zu geben, wurden die Dienste selbst umgebunden (host: 10.42.0.1 in /etc/qdrant/config.yaml, OLLAMA_HOST=10.42.0.1:11434 per systemd-Override). Das brach zwei andere Dinge, die niemand vorher explizit genannt hatte:
- Der öffentliche nginx-Reverse-Proxy qdrant.crumbforest.org (upstream qdrant_upstream { server 127.0.0.1:6333; }) — Qdrant war nicht mehr dort erreichbar, wo der Proxy hinzeigte.
- Die produktive Python-Crumbforest-App selbst (/opt/crumbforest/.env: QDRANT_HOST=localhost, OLLAMA_BASE_URL=http://localhost:11434/v1) — spricht intern über Loopback mit beiden Diensten.

Gefunden durch grep -rl '127.0.0.1:6333\|localhost:6333\|...' /etc/systemd/system/ /opt/ vor dem eigentlichen Funktionstest — ein direkter curl localhost:6333 nach der Umbindung bestätigte den Bruch (000/Connection refused) sofort, bevor ein echter Nutzer betroffen war. Kein dokumentierter Ausfall, aber ein Beinah-Vorfall, der die Lehre wert ist.

Fix (korrekt, nicht nur zurückgerollt): Qdrant/Ollama zurück auf 127.0.0.1 (App + öffentlicher Proxy unberührt). Stattdessen ein schlanker nginx-Reverse-Proxy, der nur auf der wg0-Adresse lauscht und lokal weiterleitet:

# /etc/nginx/sites-available/wg-internal-services.conf
server { listen 10.42.0.1:6333; location / { proxy_pass http://127.0.0.1:6333; ... } }
server { listen 10.42.0.1:11434; location / { proxy_pass http://127.0.0.1:11434; ... } }

Wer diesen Port erreichen darf, regelt weiterhin UFW (wg_hub_service_access in Ansible-Crumbforest/host_vars/nullfeld.yml, per Ansible-Rolle wireguard_hub verwaltet — neuer INPUT-Regeltyp, getrennt vom bestehenden wg_route_pairs-FORWARD-Muster, s. Rolle für Details), nicht der Proxy selbst.

Verifiziert von crumbzero01 aus (nicht nur ss -tlnp auf dem Server): curl http://10.42.0.1:6333/ → 200, curl http://10.42.0.1:11434/ → 200, 10.42.0.1:3306 (MariaDB) weiterhin dicht als Kontrolltest.

Lehre: vor dem Umbinden eines geteilten Dienstes IMMER prüfen, wer den bisherigen Bind bereits nutzt (grep über App-Configs, Systemd-Units, nginx-Upstreams) — nicht nur, ob der neue Bind das eigentliche Ziel erreicht. Ein Dienst umzubinden ist nie lokal isoliert, wenn ein Reverse-Proxy oder eine App-Config ihn bereits über den alten Bind anspricht. Der bessere Weg ist fast immer: Dienst-Bind unangetastet lassen, stattdessen einen zusätzlichen, eng gescopten Zugriffspunkt (hier: nginx auf der Ziel-Adresse) davorsetzen.

Update 2026-08-13, Timeout-Nachschärfung: der 10.42.0.1:11434-Proxy-Block hatte kein proxy_read_timeout gesetzt (nginx-Default 60s) — reichte für llama3.2, aber nicht für größere Modelle wie gemma3 (504 Gateway Time-out). Auf 300s angehoben. Rate-Limit-Zonen (gitea/bots/openai) sind nur in git.crumbforest.orgs Server-Blöcken referenziert, nicht global — dieser Proxy ist davon unberührt (geprüft).

Verwandt: [[nullfeld-mariadb-socket-bind-fix]] (gleicher Abend, gleiches "wo bindet was wirklich"-Muster, aber dort ohne Kollateralschaden), [[krumel-onboarding-token-gate]] (Maya-Eule/DeepBit-OpenRouter→Ollama-Umstellung nutzt diesen Proxy tatsächlich).