Netzwerk-Analyse VM302 2026-07-20: Sicherheitsluecke, Tailscale-Direktverbindung, RSC-Tuning, Routing-Beweise, eigene Fehler

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/<node>/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.**