99926aaf69
- 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
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
# 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
|
|
|
|
```powershell
|
|
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.
|