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:

# 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.

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.

5.8 KiB Raw Blame History Unescape Escape