Zum Inhalt

Connectivity Validation

Stand: 2026-05-25

VLAN 70 AI Services

Ziel: Validierung der vorbereiteten UniFi-Allow-Regeln ohne Service-Migration.

Nicht durchgeführt:

  • keine Guest-IP-Änderung
  • keine NPM-Backend-Umstellung
  • keine AD-DNS-Änderung
  • keine Deny-/Block-Regelaktivierung

Firewall Policy Check

UniFi/UDM Pro meldet:

Check Ergebnis
Primäre AI70_ALLOW_* Regeln 13 aktiv
Automatisch erzeugte Return-Regeln 13 aktiv
AI70_* Block-Regeln 0
deaktivierte AI70_* Regeln 0

Die Regeln sind reine Allow-Regeln für definierte Source/Destination/Port-Kombinationen. Es wurde keine pauschale Freigabe VLAN70 -> any angelegt.

DNS Authority Check

Name UniFi DNS LANDC1 direkt
openwebui.ad.lanstyle.de 10.222.70.10 leer
ollama.ad.lanstyle.de 10.222.70.11 leer
searxng.ad.lanstyle.de 10.222.70.12 leer
openterminal.ad.lanstyle.de 10.222.70.13 leer
agent-runtime.ad.lanstyle.de 10.222.70.20 leer
up-ai-port.ad.lanstyle.de 10.222.70.21 leer

Policy bestätigt: DNS-Schreibziel ist UniFi/UDM Pro. AD DNS wird für diese Namen nicht beschrieben.

Bestehende Altpfade

Diese Tests prüfen, dass bestehende produktive Pfade nach Aktivierung der Allow-Regeln weiterhin funktionieren.

Quelle Ziel Ergebnis
Open WebUI 10.222.70.10 Ollama 10.222.70.11:11434/api/tags HTTP 200
Open WebUI 10.0.0.250 SearXNG 10.0.1.240:8888 HTTP 200
Open WebUI 10.222.70.10 Open Terminal 10.222.70.13:8001-8004/health HTTP 200 je Port
Open WebUI 10.222.70.10 Tools API 10.222.70.20:3010/health HTTP 200
Agent Runtime 10.222.70.20 Ollama 10.222.70.11:11434/api/tags HTTP 200

Zukünftige Zielpfade

Agent Runtime, Ollama/GB10 und Open Terminal laufen VLAN70-only. SearXNG und Open WebUI sind weiterhin als Canary zusätzlich im VLAN70 aktiv. UP AI Port ist DNS/IPAM-seitig vorbereitet, aber noch nicht auf dem Zielgerät aktiv.

Quelle Ziel Ergebnis
NPM 10.0.0.5 Agent Runtime 10.222.70.20:4000/health HTTP 401, erreichbar, Auth erwartet
NPM 10.0.0.5 MCPHub 10.222.70.20:3000 HTTP 200
NPM 10.0.0.5 Tools API 10.222.70.20:3010/health HTTP 200
NPM 10.0.0.5 Qdrant Health 10.222.70.20:6333/healthz HTTP 200
Open WebUI 10.0.0.250 Agent Runtime 10.222.70.20:4000/health HTTP 401, erreichbar, Auth erwartet
Open WebUI 10.0.0.250 MCPHub 10.222.70.20:3000 HTTP 200
Open WebUI 10.0.0.250 Tools API 10.222.70.20:3010/health HTTP 200
Agent Runtime lokal LiteLLM Completion 10.222.70.20:4000/v1/chat/completions HTTP 200, Antwort OK
Open WebUI 10.0.0.250 SearXNG 10.222.70.12:8888 HTTP 200
Open WebUI 10.0.0.250 SearXNG DNS searxng.ad.lanstyle.de:8888 HTTP 200
NPM 10.0.0.5 SearXNG 10.222.70.12:8888 HTTP 200
Open WebUI 10.0.0.250 Open Terminal 10.222.70.13:8001-8004/health HTTP 200 je Port
NPM 10.0.0.5 Open Terminal 10.222.70.13:8001-8004/health HTTP 200 je Port
NPM 10.0.0.5 Open WebUI 10.222.70.10:8080 HTTP 200
NPM 10.0.0.5 Open WebUI DNS openwebui.ad.lanstyle.de:8080 HTTP 200
NPM 10.0.0.5 Ollama 10.222.70.11:11434 HTTP 200
NPM 10.0.0.5 Ollama DNS ollama.ad.lanstyle.de:11434 HTTP 200

Nicht bereite Ziele sind kein Fehler, solange die jeweiligen Guests noch nicht migriert wurden.

Agent Runtime VLAN70-only

Stand: 2026-05-28. LXC 259 ist nicht mehr dual-homed:

Interface IP Zweck
eth1 10.222.70.20/24, VLAN Tag 70 produktiver Zielpfad

Docker-Bindings laufen nur noch auf 10.222.70.20 für LiteLLM 4000, MCPHub 3000, Tools API 3010, Remote MCP 3011 und Qdrant 6333/6334.

Tests nach Cutover:

  • Proxmox-Config enthält kein net0 mehr, nur net1 mit 10.222.70.20/24 und Gateway 10.222.70.1.
  • Container-Route: Default via 10.222.70.1 auf eth1.
  • Legacy 10.0.1.243 auf 3000, 3010, 3011, 4000, 6333: nicht erreichbar, erwarteter Timeout.
  • VLAN70: LiteLLM /health ohne Key HTTP 401, MCPHub /health HTTP 200, Tools API /health HTTP 200, Remote MCP ohne Token HTTP 401, Qdrant /healthz HTTP 200.
  • Healthcheck: Lanstyle healthcheck OK: 26 checks.

SearXNG Canary

Netzstatus LXC 256:

Interface IP Zweck
eth0 10.0.1.240/20 Altpfad, bleibt aktiv
eth1 10.222.70.12/24, VLAN Tag 70 Canary-Zielpfad

SearXNG läuft nativ als systemd-Service und hört auf 0.0.0.0:8888. Tests:

  • Root-Aufruf über 10.222.70.12:8888: HTTP 200, ca. 0.003s lokal
  • Suchabfrage intern: HTTP 200, ca. 0.8-1.3s
  • Fünf parallele Suchabfragen: HTTP 200, ca. 0.8-1.4s
  • Open WebUI und NPM erreichen den neuen Pfad.

Log-Hinweis: Bei parallelen Suchtests traten engine-seitige CAPTCHA-Fehler von DuckDuckGo/Google auf. Das ist kein VLAN-/MTU-Problem, sondern SearXNG-Engine-Verhalten und sollte separat optimiert werden.

NPM Backend Canary: search.lanstyle.de

Stand: 2026-05-26. search.lanstyle.de wurde nach dem DNS-Upstream-Canary auf eine direkte interne VLAN70-Upstream-IP umgestellt. Danach wurde ollama.lanstyle.de zunächst mit DNS-Upstream getestet und wegen eines NPM/OpenResty-Resolver-Problems zurückgerollt. Die aktiven AI-/Streaming-Canaries nutzen direkte interne Upstream-IPs.

Feld Wert
Proxy Host ID 48
Vorher 10.0.1.240:8888
Zwischenstand DNS-Canary searxng.ad.lanstyle.de:8888
Jetzt 10.222.70.12:8888
Access List unverändert 0
Zertifikat unverändert 52, CN search.lanstyle.de
SSL Force aktiv seit 2026-05-27
HTTP/2 aktiv seit 2026-05-27
Block Exploits unverändert aktiv

Tests:

  • https://search.lanstyle.de/: HTTP 200
  • http://search.lanstyle.de/: HTTP 301 auf HTTPS
  • Suchabfragen lanstyle, proxmox, ollama, netbox, openwebui, vlan70: HTTP 200
  • 18 parallele Suchabfragen: alle HTTP 200, Maximum ca. 3.1s
  • Nachbeobachtung: https://search.lanstyle.de/ nach ca. 20 Sekunden weiter HTTP 200
  • NPM Access Log zeigt nach der Direct-IP-Umstellung Sent-to 10.222.70.12

Nicht geändert in diesem Schritt: ai.lanstyle.de, ollama.lanstyle.de, litellm.lanstyle.de, mcphub.lanstyle.de.

Beobachtung: Nach der Direct-IP-Umstellung wurden keine neuen Resolver-Upstream-Fehler beobachtet. Die alten 80.155.133.58:8888-Fehler im NPM-Error-Log liegen zeitlich vor der Direct-IP-Umstellung. SearXNG meldet weiterhin engine-seitige DuckDuckGo-CAPTCHA-Fehler und einzelne Wikidata-/Brave-Timeouts. Diese Fehler treten unabhängig vom NPM-Backend auf und sind getrennt von Proxy-/Netzwerkproblemen zu bewerten.

NPM Backend Canary: ollama.lanstyle.de

Stand: 2026-05-25. Nur ollama.lanstyle.de wurde in diesem Schritt getestet; ai.lanstyle.de, litellm.lanstyle.de und mcphub.lanstyle.de blieben unverändert. Der DNS-basierte Canary wurde wegen eines NPM/OpenResty-Resolver-Problems zurückgerollt. Der Direct-IP-Canary ist aktiv.

Feld Wert
Proxy Host ID 41
Vorher 10.222.70.11:11434
Fehlgeschlagener DNS-Canary ollama.ad.lanstyle.de:11434
Aktuell 10.222.70.11:11434
Access List unverändert 4
Zertifikat unverändert 43, CN ollama.lanstyle.de
SSL Force unverändert aktiv
HTTP/2 unverändert aktiv
WebSocket unverändert aktiv
Block Exploits unverändert aktiv

Tests:

  • https://ollama.lanstyle.de/api/tags: HTTP 200
  • https://ollama.lanstyle.de/v1/models: HTTP 200
  • Streaming-Test mit qwen3.5:latest: erfolgreich, done=true
  • qwen3-coder-next:latest: HTTP 200, Antwortlänge 2, done=true
  • qwen3.5:latest: HTTP 200; kurze Non-Streaming-Antwort kann modellbedingt leer sein, Request schließt sauber mit done=true
  • gpt-oss:120b mit größerem Kontext: HTTP 200; Modell beendete wegen Tokenlimit mit Reason length
  • Embedding-Test mit nomic-embed-text:latest: HTTP 200, 768 Dimensionen
  • 12 parallele Generate-Requests: alle HTTP 200, Maximum ca. 3.8s
  • Fünf Nachbeobachtungsaufrufe auf /api/tags: alle HTTP 200
  • NPM Access Log zeigt für den aktiven Canary Sent-to 10.222.70.11

DNS-Canary-Rollback-Grund: Nach zunächst erfolgreichen Tests löste OpenResty den Host ollama.ad.lanstyle.de im Upstream zeitweise auf 80.155.133.58:11434 auf und lieferte HTTP 502, obwohl die NPM-Shell ollama.ad.lanstyle.de korrekt auf 10.222.70.11 auflöste und das Backend direkt HTTP 200 lieferte. Der Proxy Host wurde per NPM-API zurückgestellt und anschließend mit der direkten Ziel-IP 10.222.70.11:11434 erneut als Canary aktiviert.

Beobachtung: Während der Direct-IP-Canary-Phase gab es keine Streaming-Abbrüche, Proxy-Timeouts oder neuen Resolver-Fehler. Bei großen Requests kann Nginx den Request Body temporär nach /tmp/nginx/body schreiben; das ist ein Performance-/Buffering-Hinweis und aktuell kein Fehler. Ollama meldete bei großen Kontexttests erwartbare Modell-/Kontextwarnungen.

NPM Backend Canary: litellm.lanstyle.de

Stand: 2026-05-25. Nur litellm.lanstyle.de wurde in diesem Schritt umgestellt; ai.lanstyle.de, mcphub.lanstyle.de, search.lanstyle.de und ollama.lanstyle.de blieben unverändert.

Feld Wert
Proxy Host ID 46
Vorher 10.0.1.243:4000
Aktuell 10.222.70.20:4000
Access List unverändert 0
Zertifikat unverändert 50
SSL Force aktiv seit 2026-05-27
HTTP/2 aktiv seit 2026-05-27
WebSocket unverändert aktiv
Block Exploits unverändert aktiv

Tests:

  • /health ohne Key: erwartetes HTTP 401
  • http://litellm.lanstyle.de/: HTTP 301 auf HTTPS
  • /v1/models mit Test-Key: HTTP 200, 5 Modelle
  • lanstyle/agent Chat Completion: HTTP 200; kurzer Test endet modellbedingt mit leerem Content und finish=length
  • lanstyle/architect Chat Completion: HTTP 200; kurzer Test endet modellbedingt mit leerem Content und finish=length
  • längerer lanstyle/agent Request: HTTP 200
  • Streaming: 16 Chunks, done=true
  • lanstyle/embed: HTTP 200, 768 Dimensionen
  • 10 parallele Chat-Completion-Requests: alle HTTP 200, Maximum ca. 2.4s
  • Open WebUI erreicht https://litellm.lanstyle.de/health und erhält erwartetes HTTP 401 ohne Key
  • NPM Access Log zeigt für den aktiven Canary Sent-to 10.222.70.20

Beobachtung: Keine neuen NPM-Upstream-Fehler, keine 502, keine Streaming-Abbrüche. LiteLLM Logs zeigen für unautorisierte Healthchecks erwartete Auth-Fehler und fuer autorisierte Tests HTTP 200.

NPM Backend Canary: mcphub.lanstyle.de

Stand: 2026-05-25. Nur mcphub.lanstyle.de wurde in diesem Schritt umgestellt; ai.lanstyle.de, search.lanstyle.de, ollama.lanstyle.de und litellm.lanstyle.de blieben unverändert.

Feld Wert
Proxy Host ID 47
Vorher 10.0.1.243:3000
Aktuell 10.222.70.20:3000
Access List unverändert 0
Zertifikat unverändert 51
SSL Force aktiv seit 2026-05-27
HTTP/2 aktiv seit 2026-05-27
WebSocket unverändert aktiv
Block Exploits unverändert aktiv

Tests:

  • Root /: HTTP 200
  • /health: HTTP 200
  • http://mcphub.lanstyle.de/: HTTP 301 auf HTTPS
  • /api/health und /api/tools ohne Token: erwartetes HTTP 401
  • /mcp und /sse ohne Token: erwartetes HTTP 401
  • Open WebUI erreicht Root und /health: HTTP 200
  • 16 parallele /health-Requests: alle HTTP 200
  • NPM Access Log zeigt für den aktiven Canary Sent-to 10.222.70.20

Beobachtung: Keine neuen NPM-Upstream-Fehler, keine 502/504 und keine Timeouts im Canary-Fenster. MCPHub-Logs enthalten ältere EROFS-Fehler auf /oauth/register mit Altpfad 10.0.1.243; das ist ein vorhandenes MCPHub-Konfigurationsthema und nicht durch den VLAN70-Canary entstanden.

Open Terminal VLAN70-only

Netzstatus LXC 255:

Interface IP Zweck
eth0 10.222.70.13/24, VLAN Tag 70 produktiver Zielpfad

Die vier User-Container bleiben unverändert und binden innerhalb des LXC auf 0.0.0.0:8001-8004; produktiv ist nur der VLAN70-Pfad des LXC aktiv. Tests:

  • Lokal auf 10.222.70.13:8001-8004/health: HTTP 200
  • Open WebUI zu 10.222.70.13:8001-8004/health: HTTP 200
  • NPM zu 10.222.70.13:8001-8004/health: HTTP 200
  • Legacy 10.0.1.253:8001-8004/health: nicht erreichbar, erwarteter Zustand seit VLAN70-only-Cleanup.

Open WebUI Canary

Stand: 2026-05-25. LXC 250 ist dual-homed:

Interface Adresse Zweck
eth0 10.0.0.250/20 Altpfad, bleibt als Rollback aktiv
eth1 10.222.70.10/24, VLAN Tag 70 Canary-Zielpfad

Open WebUI läuft nativ als open-webui.service und hört auf 0.0.0.0:8080. Tests:

  • lokal 127.0.0.1:8080, 10.0.0.250:8080 und 10.222.70.10:8080: HTTP 200
  • /api/config und /api/version auf 10.222.70.10:8080: HTTP 200
  • NPM zu 10.222.70.10:8080 und openwebui.ad.lanstyle.de:8080: HTTP 200
  • Agent Runtime zu 10.222.70.10:8080 und openwebui.ad.lanstyle.de:8080: HTTP 200
  • WebSocket-Upgrade-Probe auf dem neuen Pfad: HTTP 101
  • 30 parallele /api/version Requests: alle HTTP 200, durchschnittlich ca. 0.0064s, Maximum ca. 0.0135s

Abhängigkeiten aus dem Open-WebUI-LXC:

  • Agent Runtime/LiteLLM über agent-runtime.ad.lanstyle.de:4000: HTTP 401, erreichbar, Auth erwartet
  • MCPHub über agent-runtime.ad.lanstyle.de:3000: HTTP 200
  • Tools API über agent-runtime.ad.lanstyle.de:3010/health: HTTP 200
  • SearXNG über searxng.ad.lanstyle.de:8888: HTTP 200
  • Open Terminal über openterminal.ad.lanstyle.de:8001-8004/health: HTTP 200
  • Ollama bleibt bis zur Ollama-Migration auf dem Altpfad gb10-01.ad.lanstyle.de:11434 beziehungsweise 10.222.70.11:11434: HTTP 200

Nicht getestet: echter interaktiver Login, authentifizierte Chat-Session, Datei-Uploads und GPT-OSS-Chat über die Open-WebUI-Session, da dafür ein Benutzer-/Browser-Token nötig wäre. Die Netzwerk- und Servicepfade für die Canary sind grün.

NPM Backend Canary: ai.lanstyle.de

Stand: 2026-05-26. ai.lanstyle.de wurde per NPM-API von 10.0.0.250:8080 auf die direkte VLAN70-Upstream-IP 10.222.70.10:8080 umgestellt. Es wurden keine weiteren Proxy Hosts geändert, keine Guest-IP entfernt, keine Firewall-Deny-Regeln aktiviert und keine AD-DNS-Änderungen durchgeführt.

Feld Wert
Proxy Host ID 40
Forward vorher http://10.0.0.250:8080
Forward aktiv http://10.222.70.10:8080
Rollback-Ziel http://10.0.0.250:8080
Access List unverändert 3
Zertifikat unverändert 44
SSL Force aktiv
HTTP/2 aktiv
WebSocket aktiv
Block Common Exploits aktiv

Precheck

Test Ergebnis
https://ai.lanstyle.de/ vor Umstellung HTTP 200
https://ai.lanstyle.de/api/config vor Umstellung HTTP 200
Open WebUI Alt-IP 10.0.0.250:8080 HTTP 200
Open WebUI VLAN70-IP 10.222.70.10:8080 HTTP 200
open-webui.service aktiv

Funktionstests nach Umstellung

Test Ergebnis Bewertung
https://ai.lanstyle.de/ HTTP 200 OK
https://ai.lanstyle.de/api/config HTTP 200 OK
/api/models ohne Token HTTP 401 erwartet
/api/models authentifiziert HTTP 200, 11 Modelle OK
Browser-Session bestehende Session blieb angemeldet OK
Parallel-Tab Session persistiert OK
Modellwahl litellm.lanstyle/agent-stable produktiver Default nutzbar
Chat sichtbare Antwort OK VLAN70 Canary OK
Parallele Modelllisten-Requests 4/4 HTTP 200 OK
Open Terminal API /api/v1/terminals/ HTTP 200, 4 Einträge OK
Tools API in Open WebUI /api/v1/tools/ HTTP 200, 2 Einträge OK
Functions in Open WebUI /api/v1/functions/ HTTP 200, 3 Einträge OK
Browser-Konsole keine Fehler, eine Manifest-Warnung nicht kritisch

NPM Access Logs zeigen nach der Umstellung Sent-to 10.222.70.10 für ai.lanstyle.de, darunter /api/config, /api/models, /api/chat/completions, /api/v1/terminals/, /api/v1/tools/ und statische Assets. Es wurden keine neuen 502/504-Fehler beobachtet.

Beobachtung: Ein einzelner WebSocket-101-Eintrag zeigte am Cutover-Rand noch Sent-to 10.0.0.250. Das passt zu einer bereits bestehenden Browser-/WebSocket-Session vor vollständigem Reload. Nachfolgende Requests liefen über 10.222.70.10; die Beobachtung bleibt während der Canary-Phase im Blick.

NPM-Syntaxcheck war erfolgreich. Die bekannten OpenResty-Warnungen zu Access-List-CIDRs mit gesetzten Hostbits sind vorbestehend und blockieren den Canary nicht.

AI-Suite E2E Readiness vor ai.lanstyle.de Cutover

Stand: 2026-05-26. Der technische Readiness-Test wurde vor dem ai.lanstyle.de-Canary erfolgreich abgeschlossen. Der eigentliche NPM-Backend-Canary ist nun aktiv und wird oben separat dokumentiert.

Open WebUI Browser- und HTTP-Tests

Test Ergebnis Bewertung
http://10.222.70.10:8080/ im Browser Login-Seite lädt VLAN70-Webpfad grundsätzlich funktionsfähig
http://10.222.70.10:8080/health HTTP 200 Service gesund
http://10.0.0.250:8080/ HTTP 200 Altpfad bleibt erreichbar
https://ai.lanstyle.de/ HTTP 200, Login-Seite FQDN erreichbar, jetzt per NPM auf VLAN70-Backend
Browser-Login erfolgreich validiert bestehender Benutzer konnte sich über https://ai.lanstyle.de anmelden
Modellliste HTTP 200, 11 Modelle sichtbar Open-WebUI-Modellzugriff für normalen Betrieb vorhanden
Modellwahl litellm.lanstyle/agent-stable auswählbar produktiver Default nutzbar
Chat sichtbare Antwort OK OpenWebUI E2E, HTTP 200 echter UI-Chat erfolgreich
Uploads und lange Multi-Tab-Sessions nicht tief getestet optional vor finalem Cutover nachholen

Open-WebUI-Logs zeigten während des Tests HTTP 200 für statische Assets, /api/config, /api/version, Login, Modellliste und den echten Chat. Zwei 400-Einträge auf /api/chat/completions stammen von direkten Roh-API-Testpayloads ohne vollständigen Open-WebUI-Chat-Kontext vor dem UI-Test; der echte Chat danach war erfolgreich.

Open WebUI zu VLAN70-Zielpfaden

Quelle Ziel Ergebnis
Open WebUI LXC 250 Ollama direkt 10.222.70.11:11434/api/tags HTTP 200
Open WebUI LXC 250 https://ollama.lanstyle.de/api/tags HTTP 200
Open WebUI LXC 250 https://litellm.lanstyle.de/health ohne Key HTTP 401, erwartet
Open WebUI LXC 250 https://litellm.lanstyle.de/v1/models ohne Key HTTP 401, erwartet
Open WebUI LXC 250 https://mcphub.lanstyle.de/ HTTP 200
Open WebUI LXC 250 https://mcphub.lanstyle.de/health HTTP 200
Open WebUI LXC 250 https://mcphub.lanstyle.de/mcp ohne Token HTTP 401, erwartet
Open WebUI LXC 250 Open Terminal 10.222.70.13:8001-8004/health HTTP 200 je Port
Open WebUI LXC 250 Tools API 10.222.70.20:3010/health HTTP 200
Open WebUI LXC 250 SearXNG Direct-IP 10.222.70.12:8888/search?q=openwebui HTTP 200
Open WebUI LXC 250 https://search.lanstyle.de/ nach Direct-IP-Fix HTTP 200

Wichtig: search.lanstyle.de nutzt jetzt den direkten Upstream 10.222.70.12:8888. Der vorherige DNS-Upstream searxng.ad.lanstyle.de:8888 zeigte denselben Resolver-Effekt wie zuvor bei Ollama und versuchte zeitweise Upstream-Zugriffe auf 80.155.133.58:8888.

LiteLLM / Modellrouting

Alias Ergebnis Bewertung
lanstyle/fast HTTP 200, sichtbarer Content, finish=stop, ca. 0.2-4.9s OK
lanstyle/agent OK/JSON HTTP 200, längerer Prompt aber content_len=0, reasoning_len=2214, finish=length Routing OK, als produktiver Default aktuell nicht robust genug
lanstyle/agent-stable HTTP 200, sichtbarer Content, finish=stop, ca. 0.7-5.3s produktiv robust
lanstyle/architect HTTP 200, sichtbarer Content, finish=stop, ca. 2.0-20.4s OK, erwartbar langsamer
lanstyle/embed HTTP 200, Embeddings mit 768 Dimensionen OK

Ollama-Logs zeigten bei großen GPT-OSS-Tests erwartbare Context-Warnungen, wenn die angeforderte Context Size größer als die Modellkapazität war. Es wurden keine VLAN70-spezifischen Streaming-Abbrüche beobachtet.

MCPHub, Open Terminal und Tools

Komponente Ergebnis Bewertung
MCPHub Root und /health HTTP 200 OK
MCPHub geschützte Pfade ohne Token HTTP 401 erwartet
Open Terminal 8001-8004 HTTP 200 je /health OK
Lanstyle Tools API /health HTTP 200 OK

MCPHub-Logs enthielten ältere EROFS-Fehler bei /oauth/register mit Schreibversuch auf /app/mcp_settings.json. Am 2026-05-26 wurde der Config-Mount nach Backup persistent schreibbar gemacht; seit dem MCPHub-Restart wurden keine neuen EROFS-Fehler beobachtet.

Cutover-Bewertung

Status: ai.lanstyle.de-Canary aktiv. Die Alt-IP bleibt als Rollback-Ziel aktiv.

Verbleibende Blocker vor dem Cutover:

  • Das LiteLLM-Alias lanstyle/agent ist für längere sichtbare Antworten nicht robust genug. Empfehlung: produktiver Open-WebUI-Default vor Cutover auf lanstyle/agent-stable, keine Modelländerung ohne separate Freigabe.
  • Open WebUI nutzt intern jetzt VLAN70-Zielpfade für SearXNG, Ollama/RAG, Open Terminal und Lanstyle Tools API. Altpfade bleiben während Dual-Home als Rollback erhalten.
  • Datei-Uploads, längere Multi-Tab-Sessions und Toolausführung direkt aus einem Chat wurden in diesem E2E-Lauf nicht tief getestet.

Ollama/GB10 VLAN70-only

Stand: 2026-05-28. GB10 ist nicht mehr dual-homed im Legacy-LAN; Ollama nutzt ausschließlich VLAN70.

Interface Adresse Zweck
enP7s7 keine IPv4 Parent-Link für VLAN70, Legacy-IPv4 deaktiviert
enP7s7.70 10.222.70.11/24, VLAN ID 70 produktiver Ollama-Zielpfad

NetworkManager-Status:

  • Name: LS_AI_Services_VLAN70
  • Typ: VLAN
  • Parent: enP7s7
  • Default Route: 10.222.70.1
  • Legacy-Floating-IP-Dispatcher: deaktiviert

Tests nach Cutover:

  • GB10 lokal 10.222.70.11:11434/api/tags: HTTP 200
  • Open WebUI zu 10.222.70.11:11434/api/tags: HTTP 200
  • Agent Runtime zu 10.222.70.11:11434/api/tags: HTTP 200
  • https://ollama.lanstyle.de/api/tags: HTTP 200, NPM Access Log Sent-to 10.222.70.11
  • Legacy 10.222.70.11:11434/api/tags: nicht erreichbar, erwarteter Timeout
  • Legacy 10.0.14.43:11434/api/tags: nicht erreichbar, erwarteter Timeout
  • Healthcheck: Lanstyle healthcheck OK: 26 checks

Vor dem GB10-Cutover wurden Agent Runtime OLLAMA_API_BASE und die RAG/Qdrant-Defaults auf http://10.222.70.11:11434 umgestellt und LiteLLM minimal neu gestartet.

Ollama/GB10 Canary History

Stand: 2026-05-25. GB10 ist dual-homed:

Interface Adresse Zweck
enP7s7 10.0.14.43/20, 10.0.0.249/20 Altpfad, NPM/Open WebUI bleiben produktiv aktiv
enP7s7.70 10.222.70.11/24, VLAN ID 70 Canary-Zielpfad

NetworkManager-Verbindung:

  • Name: LS_AI_Services_VLAN70
  • Typ: VLAN
  • Parent: enP7s7
  • ipv4.never-default yes

Tests:

  • GB10 lokal 10.222.70.11:11434/api/tags: HTTP 200
  • Open WebUI zu 10.222.70.11:11434/api/tags und ollama.ad.lanstyle.de:11434/api/tags: HTTP 200
  • Agent Runtime zu 10.222.70.11:11434/api/tags und ollama.ad.lanstyle.de:11434/api/tags: HTTP 200
  • NPM zu 10.222.70.11:11434/api/tags und ollama.ad.lanstyle.de:11434/api/tags: HTTP 200
  • Altpfad 10.222.70.11:11434/api/tags: HTTP 200
  • MTU-DF-Ping mit Payload 1472 von Open WebUI, Agent Runtime und NPM zu 10.222.70.11: erfolgreich

Modelltests über 10.222.70.11:

  • qwen3-coder-next:latest: sichtbarer Content OK, HTTP 200
  • qwen3.5:latest: Streaming erfolgreich, done=true
  • gpt-oss:120b: begrenzter Large-Context-Test HTTP 200; sichtbarer Content bei ausreichendem Tokenbudget
  • nomic-embed-text:latest: Embedding bei sinnvoller Chunkgröße HTTP 200, Dimension 768
  • bewusst zu großer Embedding-Input: HTTP 400 mit Context-Length-Hinweis; erwartetes Chunking-Limit, kein Netzwerkfehler

Hinweis: qwen3.6:35b-a3b und kurze gpt-oss:120b Prompts können Tokens im Feld thinking verbrauchen, bevor sichtbarer response-Text entsteht. Für sichtbare Antworten muss das Tokenbudget ausreichend groß sein oder das Modellrouting/Prompting angepasst werden.

Policy-Risiko

Aktuell existieren im UniFi-Policy-Modell weiterhin generische Systemregeln wie Allow All Traffic innerhalb der Internal-Zone. Die neuen AI70_ALLOW_* Regeln sind korrekt vorbereitet, ersetzen aber noch keine spätere Segmentierungsphase. Harte Deny-Regeln dürfen erst nach Wartungsfenster, Ziel-IP-Migration und erfolgreicher App-Validierung folgen.