From 8edc27b030bae6e43404e820909c40de6b9f3017 Mon Sep 17 00:00:00 2001 From: Code-Barby Date: Mon, 20 Jul 2026 13:16:18 +0200 Subject: [PATCH] Netzwerk-Analyse VM302 2026-07-20: Sicherheitsluecke, Tailscale-Direktverbindung, RSC-Tuning, Routing-Beweise, eigene Fehler --- netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md | 98 +++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md diff --git a/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md b/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md new file mode 100644 index 0000000..8ee4192 --- /dev/null +++ b/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md @@ -0,0 +1,98 @@ +# VM302 Netzwerk-Analyse & Optimierung — 2026-07-20 + +Vollständige Untersuchung der Latenz Deutschland ↔ Kansas City (VM302, A40-Workstation) +sowie zweier kritischer Sicherheits-/Performance-Befunde. + +## TL;DR +- **Routing über Relays bringt NICHTS** — der direkte Pfad ist bereits physikalisch optimal (3 Beweise) +- **Der echte Gewinn lag auf der Maschine:** RSC abschalten = −7 ms, mehr als jedes Gateway geboten hätte +- **VM302 stand ungeschützt im Internet** (ComfyUI/Ollama ohne Auth) — geschlossen +- **Tailscale lief über Relay statt direkt** — Port-Forward-Fix: 162 → 127 ms, Jitter 40 → 0,8 ms + +## 1. Sicherheitslücke (kritisch) +**Befund:** VM302s Windows-Firewall-Profil „Private" war **deaktiviert**, und die öffentliche NIC lag in genau diesem Profil. +Folge: ComfyUI (:8188), Studio (:8502), Ollama (:11434), LiteLLM (:4000) waren **unauthentifiziert aus dem Internet erreichbar**. +ComfyUI erlaubt Datei-Zugriff und via Custom-Nodes faktisch Code-Ausführung → A40 und System offen für jeden. + +**Fix — nur VM-Ebene filtern, Hosts offen lassen:** +``` +/etc/pve/firewall/cluster.fw enable: 1, policy_in: ACCEPT # Subsystem an, Default offen +/etc/pve/nodes//host.fw enable: 1 # erbt ACCEPT = ungefiltert +/etc/pve/firewall/302.fw policy_in: DROP + Ausnahmen # NUR hier wird gefiltert +qm set 302 --net1 ...,firewall=1 # nur die öffentliche NIC +``` +Ausnahmen in 302.fw: 3389 (RDP), 47984-48010 (Moonlight), 41641 (Tailscale), ICMP. +**net0 (intern/NAT) bleibt ungefiltert = Rettungsleine**, RDP über die NAT-IP bleibt immer erreichbar. + +## 2. Tailscale: Relay statt Direktverbindung +**Befund:** `tailscale status` zeigte `relay "ki1-us"` — jede Verbindung lief über Virginia, also DE→USA→DE. +**Ursache:** VM302 sitzt hinter NAT auf gpu1. Forwards für RDP und Moonlight existierten, **für Tailscale UDP 41641 nicht.** + +**Fix — BEIDE Regeln nötig:** +```bash +# eingehend +iptables -t nat -A PREROUTING -i vmbr0 -p udp --dport 41641 -j DNAT --to-destination 10.10.10.102:41641 +iptables -I FORWARD -p udp -d 10.10.10.102 --dport 41641 -j ACCEPT +# ausgehend: Quellport ERHALTEN +iptables -t nat -I POSTROUTING 1 -o vmbr0 -p udp -s 10.10.10.102 --sport 41641 \ + -j SNAT --to-source 173.208.162.26:41641 +netfilter-persistent save +``` +**Nur DNAT reicht nicht** — MASQUERADE würfelt sonst den Quellport, STUN meldet einen anderen Port +als den geforwardeten, und das Mapping passt nicht zusammen. +**Ergebnis:** 162 ms / 40 ms Jitter (Relay) → **127 ms / 0,8 ms Jitter (direkt)**. + +## 3. RSC — der eigentliche Latenz-Fresser +**Befund:** nas2 → VM302 = 143,9 ms, nas2 → gpu1 = 134,8 ms. **9,1 ms Unterschied im selben Rechenzentrum.** +**Ursache:** Recv Segment Coalescing (RSC) auf den virtio-NICs aktiv — bündelt eingehende Pakete, spart CPU, kostet Latenz und Jitter. + +```powershell +Disable-NetAdapterRsc -Name "Ethernet 2" +Disable-NetAdapterRsc -Name "Ethernet" +``` +**Ergebnis:** VM302 132,3 ms · Abstand zu blankem Blech **9,1 → 2,0 ms** · netto **~7 ms Gewinn**. +RSS war bereits aktiv (16 Queues), Offloads korrekt. + +## 4. Routing-Analyse — warum kein Relay hilft +| Weg | Ergebnis | +|---|---| +| Direkt DE → VM302 | **121 ms**, ±2 ms Jitter, 0 % Verlust | +| über Netcup DE (gw) | +15 ms | +| über Netcup Virginia | +9 ms | +| alle VM302-Ziele über gw | +15…20 ms | + +**Traceroute:** beide Wege über Arelion/Telia (62.115.x). Direkter Pfad **ohne Umweg**, Zielnetz ab Hop 13. +**Geografie:** Virginia = Ostküste (94 ms), Kansas City = Landesinneres (121 ms) → über Virginia fährt man 27 ms extra. + +**Messfallen, die zu Fehlschlüssen führen:** +- **TCP-Handshake über einen nginx-Stream-Proxy misst nichts** — nginx nimmt lokal an, bevor es das Backend kontaktiert (zeigte 3,5 ms statt der echten Strecke). Stattdessen echten Protokoll-Roundtrip messen (RDP X.224 CR→Confirm). +- **Ping-Summen unterschätzen Relays systematisch** — Annahme/Pufferung/Neuversand tauchen darin nicht auf. Gemessene Realität bei gw: +15 ms, obwohl die Summe „gleichauf" vorhersagte. +- `tailscale netcheck` nutzt einen **eigenen Socket** — der dort gemeldete Port ist NICHT tailscaleds 41641. + +**Fazit:** 7.000 km über ein Tier-1-Backbone sind ~121 ms. Kein Relay, Tunnel oder Peering-Trick geht darunter. +Echte Hebel: Protokoll (Moonlight statt RDP), Maschine (RSC), Architektur (Ergebnisse nach DE pushen statt mehrfach queren). + +## 5. Zwei eigene Fehler — zur Warnung +**a) Proxmox-Cluster-Falle.** gpu1 und pm1 bilden `consoro-cluster`. `/etc/pve/` ist **geteiltes Cluster-Dateisystem** — +`cluster.fw` mit `enable: 1` auf gpu1 schaltete die Firewall auch auf pm1 ein → dort SSH tot, Web-UI-Timeouts bei VM-Details +(PVEFW-HOST-IN lässt SSH nur aus IPSET `management`, und das war leer). +➡️ **Vor jedem Proxmox-Firewall-Eingriff `pvecm status` prüfen.** + +**b) `policy_in` ist keine gültige `host.fw`-Option** (gehört in `cluster.fw`). Falsch gesetzt → Host-Policy fiel auf DROP zurück +→ **Selbst-Aussperrung per SSH**. Gerettet hat Tailscale, weil `ts-input` **vor** der PVE-Kette akzeptiert. +➡️ Bei Firewall-Arbeiten immer einen zweiten, ungefilterten Zugangsweg offen halten. + +**c) Unbelegte Behauptung.** Ich hatte gewarnt, der DERP auf dem Mailserver störe die Mailzustellung — **ohne zu messen**. +Nachgemessen: 0,1 % CPU, 2 Verbindungen, 1 Logzeile/Stunde. Die Behauptung war falsch. +➡️ Erst messen, dann warnen. + +## 6. Latenz-Matrix (Referenz) +Gemessen von nas2 (Standort Bär, ohne WARP-Verfälschung): +| nas2 → | ms | | Server → gpu1 | ms | +|---|---|---|---|---| +| DERP-DE (Mailserver) | 24,3 | | **Mailserver** | **111,4** (bestes Peering) | +| DERP-US (Virginia) | 106,6 | | Hub | 120,5 | +| gpu1 | 130–135 | | nas2 | 134,8 | +| VM302 (nach Tuning) | 132,3 | | | | + +**Wichtig:** Bär nutzt Cloudflare WARP → Messungen an seinem Client sind verfälscht. **Immer von nas2 oder gpu1 aus messen.**