From 07c1c0f31df262a3e97e7139236347807ed8a80c Mon Sep 17 00:00:00 2001 From: Code-Barby Date: Mon, 20 Jul 2026 16:01:26 +0200 Subject: [PATCH] Netzwerk-Thema abgeschlossen: Cloudflare-Messfehler korrigiert, Sunshine-WebUI-Luecke, DNAT-Verschleierung, Endstand aller Varianten --- netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git a/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md b/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md index 8ee4192..a4409d6 100644 --- a/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md +++ b/netzwerk/2026-07-20-VM302-Netzwerk-Analyse.md @@ -96,3 +96,74 @@ Gemessen von nas2 (Standort Bär, ohne WARP-Verfälschung): | 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.** + +--- + +# NACHTRAG — Thema abgeschlossen (Endstand 2026-07-20) + +## Weitere Messungen nach dem ersten Bericht + +### Cloudflare Tunnel — mein Messfehler und die Korrektur +Erster Test zeigte scheinbar **90 ms Gewinn** durch einen Cloudflare Quick Tunnel. +**Das war falsch.** Ursache: der Testserver war ein einthreadiger Python-`BaseHTTPRequestHandler`, +der die *Direkt*messung ausbremste (274 ms bei 132 ms echter Netzlaufzeit). + +Neumessung mit `ThreadingHTTPServer` + `TCP_NODELAY` + keep-alive, gleiches Backend für beide Wege: +| Weg | Median Dauerbetrieb | +|---|---| +| Direkt (http) | **130–144 ms** ← entspricht exakt dem Ping | +| Cloudflare-Tunnel (https) | 166–227 ms | + +➡️ **Cloudflare ist 35–80 ms LANGSAMER.** Kein Domain-Umzug nötig. +➡️ **Lehre: bei Latenzmessungen immer prüfen, ob der Testserver selbst der Flaschenhals ist.** + +### Warum Cloudflares 1-ms-Nähe nicht hilft +`gpu1 → 1.1.1.1 = 1,06 ms`, PoP-Kennung **`mci03`** (= Kansas City), 6 Hops, echtes Cloudflare (kein Provider-Hijack). +Aber: Diese 1 ms decken nur den ersten Meter. Der Atlantik bleibt. +**Ein Anycast-Ping misst, wo die nächste Edge steht — nicht, wie schnell das Backbone nach Europa trägt.** + +### Alle Varianten im Endstand +| Variante | Ergebnis | +|---|---| +| **Direkt** | ✅ 121 ms (RZ) · 130 ms (nas2) · 150 ms (Client) | +| Cloudflare-Tunnel | +35…80 ms | +| Netcup-DE-Relay | +15 ms | +| Netcup-Virginia | +9 ms | +| NordVPN Meshnet | ±0 (funktional = Tailscale) | +| Multi-Routing-Broker | nicht bauen — Tailscale leistet das bereits | +| **RSC-Tuning VM302** | ✅ **−7 ms** (einziger echter Gewinn) | + +**Bärs Anschluss ist Starlink** (SpaceX-IP, Berlin) → systembedingter Jitter, nicht wegoptimierbar. +Sein Client misst 150 ms, sein NAS am selben Anschluss 130 ms → Verdacht WLAN/Client-seitig. + +## Weitere Sicherheitsbefunde (alle geschlossen) + +### Sunshine-Admin-Oberfläche stand offen +Port 47990 öffentlich erreichbar, **ohne jede Zugangsdaten** (`credentials/` enthält nur TLS-Zertifikate, +`sunshine.conf` hat kein `username`/`password`). Wer die URL aufrief, konnte sich als Admin einrichten, +Geräte koppeln und **den Desktop streamen**. +➡️ 47990 aus der Proxmox-Regel entfernt **und** die DNAT-Weiterleitung auf gpu1 gelöscht. + +### DNAT verschleierte alle RDP-Absender +``` +DNAT tcp dpt:3389 → 10.10.10.102 destination 0.0.0.0/0 ← griff auch für .43 +``` +Folge: **jede** RDP-Verbindung erschien als `10.10.10.1` — auch die Angriffe aus Ungarn (80.94.95.152) +und Moskau (62.205.169.50). **EvlWatcher war blind** und hätte beim Sperren Bär selbst ausgesperrt. +➡️ DNAT auf `-d 173.208.162.26` eingegrenzt. `.43` läuft direkt mit echter Absender-IP, +`.26` bleibt als Rettungsleine. + +**Merksatz:** DNAT-Regeln ohne Ziel-IP-Bindung hebeln VM-Firewalls aus, weil der Traffic +am gefilterten Interface vorbei auf die interne Karte umgeleitet wird. + +## Moonlight/Sunshine — Ursache +**`sunshine_state.json`: 0 gekoppelte Geräte.** Ohne Kopplung kein Stream. +Sunshine läuft als SYSTEM in Sitzung 1 (Konsole), virtueller Display-Adapter (SudoMaker) vorhanden, +Aufnahme funktioniert (1600x1156 @ 66 Hz). Desktop-Duplication funktioniert in RDP-Sitzungen nicht — +deshalb muss Sunshine auf der Konsole laufen. +**Kopplung:** Client in Tailscale → Moonlight „+" → `100.104.5.57` → PIN unter `https://100.104.5.57:47990`. + +## Fazit +7.000 km über ein Tier-1-Backbone sind ~121 ms. **Kein Relay, Tunnel, Mesh oder Broker geht darunter.** +Für 5–10 €/Monat existiert keine Lösung, die das ändert. Einziger echter Hebel: **GPU-Maschine in Europa.** +Praktisch nutzbar: Protokollwahl (Moonlight statt RDP) und **Ergebnisse nach DE pushen statt den Ozean mehrfach queren.**