RDP über VPN nach Internet-Trennung und -wiederaufbau nicht mehr möglich

Es gibt 26 Antworten in diesem Thema. Der letzte Beitrag () ist von ATXMega256@32MHz.

    Notiz an mich: RTFM!
    Die Ziel-FritzBox wird über den ersten Hop erreicht:

    Quellcode

    1. Routenverfolgung zu [IP-der-fernen-Fritz!Box]
    2. über maximal 30 Hops:
    4. 1 27 ms 27 ms 45 ms [IP-der-fernen-Fritz!Box]
    6. Ablaufverfolgung beendet.
    Beim Versuch, den Ziel-PC zu tracen:

    Quellcode

    1. Routenverfolgung zu [IP-des-Ziel-PCs] über maximal 30 Hops
    3. 1 35 ms 26 ms 27 ms [IP-des-Ziel-PCs]
    4. 2 * * * Zeitüberschreitung der Anforderung.
    5. 3 * * * Zeitüberschreitung der Anforderung.
    6. 4 * * * Zeitüberschreitung der Anforderung.
    7. 5 * * * Zeitüberschreitung der Anforderung.
    8. 6 * * * Zeitüberschreitung der Anforderung.
    9. …
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Hatte jetzt lange Zeit keine Probleme mehr mit Fritz!Fernzugang, am Vormittag hat es noch geklappt. Dann hab ich
    • mich am Ziel-PC abgemeldet
    • Fritz!Fernzugang-Verbindung getrennt
    • lokalen PC heruntergefahren
    • später lokalen PC wieder angemacht
    • mit Fritz!Fernzugang Verbindung hergestellt
    • RDP funktioniert nicht
    • Fritz!Fernzugang-Verbindung getrennt
    • mit WireGuard Verbindung hergestellt
    • RDP funktioniert, mich also am Ziel-PC angemeldet
    • mich am Ziel-PC abgemeldet
    • WireGuard-Verbindung getrennt
    • mit Fritz!Fernzugang Verbindung hergestellt
    • RDP funktioniert wieder nicht
    Rätsel über Rätsel.
    Leider kann ich WireGuard anscheinend nicht dauerhaft verwenden, weil dann das Risiko besteht, dass eine wichtige, TCP-nutzende App am Ziel-PC zwischendurch mal ihren Geist aufgibt.
    Das passiert bei einer Fritz!Fernzugang-Verbindung nie. Laut RDP läuft beides über UDP, aber als Netzwerklaie weiß ich nicht, ob diese Aussage glaubhaft und relevant ist.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    und erneut beobachtet:
    • nach Ziel-PC-Neustart funktioniert die Verbindung über Fritz!Fernzugang mehrere Tage
    • während einer Session gab es lokal DSL-Probleme, also wurde meine Verbindung zwangsläufig unterbrochen und wieder neu hergestellt
    • RDP hat nicht mehr funktioniert
    • Beenden und Neuverbindung des Fritz!Fernzugangs funktioniert, RDP funktioniert nicht
    • seitdem geht RDP nur noch über WireGuard
    :cursing:
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    VaporiZed schrieb:

    Laut RDP läuft beides über UDP, aber als Netzwerklaie weiß ich nicht, ob diese Aussage glaubhaft und relevant ist.


    Möglichweise relevant. Bei UDP ist im Gegensatz zu TCP nicht sichergestellt das die Daten ankommen.

    PS.
    Man sollte schon darauf vertrauen können, das die Angabe des Protokolls stimmt.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DTF“ ()

    Bei WireGuard läuft die Verbindung auch über UDP, da ist aber die Verbindung problemlos.
    Was ich noch gesehen habe: Wenn die F!FZ-Verbindung steht und RDP nicht nutzbar ist, ist die Kommunikation mit dem Ziel-PC im Gesamten nicht möglich. Stelle ich die Verbindung über WireGuard her, ist die Kommunikation mit dem PC kein Problem. Der Ziel-PC wird also ungewollt abgeschottet, wenn die Verbindung vom Anbieter gekappt und wieder hergestellt wurde, sofern ich F!FZ nutze. Kein RDP, keine direkte Kommunikation mit dem Ziel. Sowas wie ein Cache-Verbindungsdetail gibt es wahrscheinlich nicht, oder? Also, dass sich dort irgendwas gemerkt wurde und nach Zwangstrennung und -wiederherstellung diese nicht mehr gültigen Details verwendet werden.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ich kann mir vorstellen, das es an einem Cache liegt. Ich hatte kürzlich auch ein Netzwerk-Problem, das vermutlich auch mit irgendeinem Cache zusammenhängt. Aber mit RDP kenne ich mich zu wenig aus, kann deshalb auch nur Spekulatius backen.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Hi,
    Dein Thema stinkt mir sehr nach Routeingproblemen wenn mehrere Netzwerkkarten(VPN simuliert ihre eigene) im Einsatz sind. Jedes mal wenn eine Netzwerkverbindung erfolgreich aufgebaut wurde durch eine Netzwerkkarte, wird die lokale Routingtabelle deines Systems temporaer veraendert. Beim Versuch mittels einer bestimmter Applikation (in deinem Fall mstsc.exe) Packete zu versenden, landen sie beim falschen Gateway.

    Das ganze kann unter Umstaenden nervig werden wenn es 24/7 funktionieren muss und mehrere Netzwerkkarten verbaut sind die mit verschiedenen Netzwerken quasseln sollen..

    Probier mal im nicht funktionierenden Zustand im schwarzen Fenster den Befehl 'Route print -4' abzufeuern und notieren Dir die "Kosten" (Metrik) ueber welchen NIC das System versucht sich zu verbinden. Ggf. kannst Du hier eine kleine Aenderung durchfuehren und die Packete kommen an der richtigen NIC an.

Facebook
Telefonspende