Remotedesktop über ein VPN: In welchem Fehler stecken Sie?

Ihr Tunnel steht, das interne Wiki lädt, und Remotedesktop verweigert weiterhin die Verbindung. Diese Kombination ist normal, denn das VPN liefert eine Route zum Host, während der Desktopdienst lauschen, von seiner eigenen Firewall erlaubt und bereit sein muss, das Konto zu authentifizieren. Zwischen einem funktionierenden Tunnel und einer nutzbaren Sitzung liegen vier Fehlerstufen, und jede scheitert mit einer anderen Meldung. Lesen Sie zuerst die Meldung, denn sie benennt die Stufe.

Vier Fehler, die wie einer aussehen

Die Stufen sind geordnet: Der Name wird zur privaten Adresse aufgelöst, die das Design vorsieht, der Port antwortet auf einen TCP-Handshake, der Host nimmt die Verbindung nach seiner eigenen Richtlinie an, und die Sitzungsanmeldung gelingt. Jede Stufe macht die nächste unprüfbar, weshalb Änderungen an den RDP-Einstellungen, bevor das Netzwerk geklärt ist, nur Rauschen erzeugen. Das Symptom wirkt aus Sicht des Nutzers in allen vier Fällen identisch. Nur die Meldung des Clients trennt sie.

Eine funktionierende interne Website beweist nichts von den vieren. Sie beweist, dass ein Host im selben Netzwerk auf einem anderen Port mit einem anderen Dienst geantwortet hat. Nehmen Sie das als Beleg zum Routing und nichts weiter.

Testen Sie der Reihe nach und schreiben Sie das Ergebnis auf. Zum Anmeldebildschirm zu springen, weil der Port geantwortet hat, ist der Weg, einen Nachmittag mit einem Firewallproblem zu verbringen, das der erste Schritt bereits lokalisiert hat.

Lauscht etwas auf 3389?

Beginnen Sie mit dem Namen, denn ein Name, der zur falschen Adresse aufgelöst wird, entwertet jeden weiteren Test. Fragen Sie den Resolver des Tunnels, was der Name bedeutet, und vergleichen Sie dann die Antwort mit der privaten Adresse, die das Design vorsieht, statt mit einer erfolgreichen Antwort. Ein Name, der zu einer öffentlichen Adresse aufgelöst wird, ist das ganze Problem, und keine RDP-Änderung behebt es:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Testen Sie dann den Port statt des Hosts. Ein abgeschlossener TCP-Handshake auf 3389 trennt die Erreichbarkeit von allem darüber:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Führen Sie diesen Test aus dem LAN und aus dem Tunnel durch, denn ein Unterschied zwischen beiden Ergebnissen lokalisiert den Fehler auf dem VPN-Pfad. Auf dem Pfad liegen zwei Firewalls, und sie lassen sich leicht verwechseln: Das Netzwerk muss der Tunneladresse des Clients erlauben, den Host zu erreichen, und die eigene Firewall des Hosts muss dieselbe Quelle auf dem lauschenden Port erlauben. Eine auf das LAN-Subnetz beschränkte Regel deckt den VPN-Client-Pool nicht ab, und das ist die häufigste Ursache für eine Zeitüberschreitung, die nur entfernte Nutzer melden. Prüfen Sie den Geltungsbereich statt der Existenz der Regel.

Der Rückweg verdient dieselbe Prüfung. Antworten brauchen eine Route zurück in den Client-Pool statt ins LAN, und eine Übersetzung vor dem Host ändert die Quelle, die Ihr Protokoll zeigen wird. Antwortet der Port in die eine Richtung und in die andere nicht, ist die fehlende Hälfte meist der Rückweg.

Lesen Sie die Meldung, bevor Sie die Konfiguration lesen

Die dritte Stufe ist der Host, der die Verbindung nach seiner eigenen Richtlinie ablehnt, was oft wie ein Port aussieht, der sofort aufgeht und wieder schließt. Etwas hat geantwortet, und das ist eine nützliche Information statt Stille. Wurde der Handshake abgeschlossen und starb die Sitzung sofort, ist das Netzwerk in Ordnung und der Host entscheidet. Sehen Sie sich die Berechtigungen für Remotedesktop an, bevor Sie das Netzwerk erneut anfassen.

Das Feature kann für den Rechner aktiviert sein, während der Zugriff auf bestimmte Gruppen beschränkt ist, und der Listener kann so gebunden sein, dass er die Adresse ausschließt, über die Sie gekommen sind. Netzwerkeben-Authentifizierung fügt ein Tor hinzu, das vor dem Laden des Desktops scheitert, und sein Fehlertext unterscheidet sich von einem falschen Kennwort. Vergleichen Sie die Meldung des Clients mit dem Ereignisprotokoll des Hosts, denn die Meldung benennt das Tor und das Protokoll das Konto.

Die Sitzungsanmeldung ist ihre eigene Grenze

Die Authentifizierung gehört zum Desktopdienst, nicht zum VPN. Die Identität des Tunnels und das Desktopkonto sind getrennte Anmeldedaten mit getrennten Sperrrichtlinien, daher beweist ein funktionierender Tunnel nur, dass der Tunnel Sie angenommen hat. Das Sperren des Desktopkontos stört den Tunnel nicht, und umgekehrt gilt dasselbe.

Halten Sie beides intakt. Fehlt die private Route, reparieren Sie die Route, denn den Listener ins Internet zu veröffentlichen tauscht einen Erreichbarkeitsfehler gegen einen exponierten Desktop. Schwächen Sie auch nicht die Identitätsprüfungen der Sitzung, um an einer Zertifikatswarnung vorbeizukommen, die gleichzeitig erschienen ist. Ein selbstsigniertes Zertifikat auf einem RDP-Listener erzeugt konstruktionsbedingt eine Warnung, sodass das Akzeptieren eine Entscheidung und kein Schritt ist.

Zählen Sie die Versuche, bevor Sie es erneut versuchen. Sperrschwellen für den Desktop zählen fehlgeschlagene Anmeldungen getrennt von VPN-Fehlern, und ein Client, der per Timer erneut versucht, kann die Schwelle auslösen, während Sie noch eine Regel bearbeiten. Das ist derselbe parallele Wiederholungsmechanismus, der Konten nach einer Kennwortänderung sperrt.

Was die Sitzung bewegen kann und wo es bleibt

Lernen Sie den genehmigten Abmeldeablauf, bevor Sie ihn brauchen. Das Schließen des Fensters trennt möglicherweise nur die Ansicht, während die Sitzung nach ihrer konfigurierten Richtlinie weiterläuft, was auf einem gemeinsam genutzten oder auditierten Host zählt. Melden Sie sich innerhalb der Sitzung ab, wenn die Richtlinie das erwartet.

Entscheiden Sie dann, was die Sitzung tragen darf, denn Zwischenablage, umgeleitete Laufwerke, Druckerumleitung und Dateiübertragung bewegen Daten zwischen dem lokalen und dem entfernten System, wo die Richtlinie es erlaubt. Eine veröffentlichte Anwendung auf der anderen Seite ist nicht automatisch eine Grenze ohne Download, und eine Sitzung, die schreibgeschützt aussieht, kann dennoch eine Zwischenablage tragen. Testen Sie die echte Aufgabe statt der Verbindung: Öffnen Sie die Datei, nutzen Sie die Anwendung und bestätigen Sie die Umleitung, die Sie brauchen. Die Microsoft-Anleitung zum Zugriff auf einen Remotedesktop von außen beschreibt die unterstützten Expositionsoptionen und ist eine bessere Referenz als ein unter Druck hinzugefügter öffentlicher Listener.