Netzwerk-Thema abgeschlossen: Cloudflare-Messfehler korrigiert, Sunshine-WebUI-Luecke, DNAT-Verschleierung, Endstand aller Varianten
This commit is contained in:
Code-Barby
parent
8edc27b030
commit
07c1c0f31d
|
|
@ -96,3 +96,74 @@ Gemessen von nas2 (Standort Bär, ohne WARP-Verfälschung):
|
||||||
| VM302 (nach Tuning) | 132,3 | | | |
|
| 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.**
|
**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.**
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue