Code-Barby 99926aaf69 Doku 2026-07-20: Moonlight/Apollo-Analyse (abgebrochen) + Verbindungs-Wahrheit

- Apollo statt Sunshine: wer die Ports besitzt, bestimmt welche Konfiguration gilt
- PIN-Fehler war haengender Kopplungszustand, kein falscher PIN
- Kein NVENC weil QEMU-VGA statt A40 abgegriffen wird
- Tailscale laeuft != Tailscale wird benutzt
- Eigene Messfehler dokumentiert

2026-07-20 17:48:00 +02:00

2.4 KiB

Raw Blame History

Verbindungs-Wahrheit VM302 — welcher Weg wird wirklich benutzt

Datum: 2026-07-20

Kernbefund

Ein laufendes Tailscale bedeutet nicht, dass der Verkehr durch den Tunnel geht. Tailscale routet nur, was an seine Adressen adressiert ist.

Aus dem RDP-Anmeldeprotokoll von VM302:

16:10:57  Sitzung 4 (matthias)  von 185.229.59.123   <- NordVPN
16:39:44  Sitzung 4 (matthias)  von 9.246.41.123     <- Starlink, direkt
          Sitzung 3 (mcp)       von 100.87.20.94     <- Hub ueber Tailscale

Der Nutzer war ueberzeugt, ueber Tailscale zu gehen — tatsaechlich lief die Verbindung roh ueber Starlink. Ursache: Verbindung auf den oeffentlichen Namen rdp.go-ki.eu -> oeffentliche IP -> Tunnel bleibt ungenutzt. Fuer den Tunnel muesste die Tailscale-Adresse 100.104.5.57 angegeben werden.

Nachweis, welcher Weg benutzt wurde

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' -MaxEvents 60 |
  Where-Object { $_.Id -in 21,25 } | ForEach-Object {
    $x = [xml]$_.ToXml()
    "$($_.TimeCreated) | Sitzung $($x.Event.UserData.EventXML.SessionID) | $($x.Event.UserData.EventXML.Address)"
  }

100.x = Tunnel, alles andere = oeffentlicher Weg.

Was von VM302 aus NICHT messbar ist

Die Latenz des Nutzers laesst sich vom Server aus nicht ermitteln:

ICMP — Starlink filtert Ping, keine Antwort
TCP zurueck zum Client — es lauscht nichts auf dem Quellport; alle Versuche liefen ins Zeitlimit (8x ~2013 ms = exakt das gesetzte Limit, keine Messwerte)
RemoteFX-Netzwerkzaehler — auf dieser Maschine nicht vorhanden

Messung ist nur von der Client-Seite moeglich. Vom Server aus laesst sich lediglich der benutzte Weg nachweisen, nicht die Geschwindigkeit.

Methodischer Fehler, der dabei passierte

Es waren drei Verbindungen auf Port 3389 offen. Gemessen wurde die erstbeste (144 ms, 0,18 ms Jitter) und als "deine Verbindung" praesentiert. Sie gehoerte zu keiner Anmeldung.

Regel: Erst Sitzung <-> IP ueber das Anmeldeprotokoll zuordnen, dann messen. Eine Messung ohne geprueften Endpunkt ist wertlos, egal wie sauber die Zahlen aussehen.

Offener Sicherheitspunkt

91.238.181.141 hatte eine hergestellte Verbindung auf Port 3389, ohne dass je eine Anmeldung protokolliert wurde. Im Kontext der am selben Tag beobachteten Angriffe (Ungarn 80.94.95.152, Moskau 62.205.169.50) pruefen.

2.4 KiB Raw Blame History