Im RDP-Client (Remote Desktop Connection/Remotedesktopverbindung/Tilkobling til eksternt skrivebord) von Microsoft findet sich unter dem Tab Advanced (Erweitert/Avansert) ein Link auf weitergehende Einstellungen, insbesondere Connect from anywhere (Verbindung von überall aus herstellen/Koble til fra hvor som helst) -> Settings… (Einstellungen…/Instillinger…):
Unter Settings… erhält man diesen Dialog:
(Microsoft hat es, wie man an den Screenshots sieht, auch immer noch nicht geschafft, den Bug bei ALT-Druck zu beseitigen: Es wird nach wie vor der überflüssige Rand mit im Screenshot gespeichert…)
Hier gibt es nun die vielversprechende Einstellung Bypass RD Gateway server for local addresses (Remotedesktop-Gatewayserver für lokale Adressen umgehen/Omgå ES-gatewayserver for lokale adresser). Allein, sie tut nicht, was sie soll!
Der Bug, über den ich hier rede, äußert sich darin, daß ich trotz Aktivierung der Bypass-Funktion keinen Zugriff auf meinen Desktop-PC im lokalen Netz erhalte!
Die Lösung: Entweder die Gateway-Server-Funktion auf Automatik stellen oder komplett abschalten!
Einschub: Der Bug tritt unter Windows 7 genauso auf wie unter Windows 10!
Ich arbeite mit Rechnern in meinem Heimnetz, die nur in einer Workgroup angemeldet sind, es gibt aber auch Rechner, die in einer Microsoft-Domäne angemeldet sind. Dort verwenden wir einen Gateway-Server für RDP, weil das als praktisch erschien, zumindest für die technisch weniger versierten Kollegen im Home-Office. Und natürlich teste ich solche Features auf verschiedenen Rechnern und in unterschiedlichen Umgebungen, bevor ich so etwas weitergebe. Vor ein paar Tagen bemerkte ich bei mir zu Hause auf einem ersten Rechner, daß es nicht (mehr) möglich war, eine RDP-Verbindung zu meinem Desktop-PC herzustellen.
Durch meine Versuche mit SSL-Verbindungen, Tunneln und Remote-Zugriffen über das Internet wußte ich aber, daß auf dem Desktop-PC alles in Ordnung war! Warum also kam ich von diesem Notebook aus nicht auf meinen PC?
Ich verdächtigte in der ersten Phase der Fehlersuche die Fritz!Box sowie die sekundären APs und Repeater. Kompliziert wurde es dadurch, daß mein Heimnetz teilweise kabelgestützt ist. Und viele Netzwerkgeräte (Router, Access Points, Firewall-Appliances und ähnliches Geraffel) erlauben die Einrichtung unterschiedlichster Zugriffsprofile innerhalb des Netzwerks…
Heute morgen erinnerte mich, daß ich über mein kleines Notebook, auf dem ich die meisten Konfigurationstests mit Tunneln über Synology-NAS-Geräte durchgeführt hatte, problemlos RDP-Sessions auf den PC herstellen konnte. Zumindest gelang das im Zusammenhang mit Putty-Profile und SSL-Tunneln…
Also, flugs mal RDP gestartet (nackt und ohne irgendein SSL-Profil im Hintergrund) und einen Login versucht. Nix. Ping? Geht. Was ist da los? Somit war ein zweiter Rechner gefunden, über den ich keinen Zugriff per RDP erhielt.
Ich habe im Anschluß zweieinhalb Stunden gebraucht, um den oben genannten Fehler zu finden. Im zweiten Anlauf, nach der Analyse der Netzwerkeinstellungen auf der Fritz!Box und ihren Kollegen, dachte ich nämlich, es hätte etwas mit Microsofts idiotischen Netzdomänen zu tun, also nicht mit den AD-Domänen, sondern den Zuordnungen Heim, Privat, Domäne, Öffentlich und wie der ganze Blödsinn heißt. Den man, nebenbei bemerkt, unter Windows 10 gar nicht einmal mehr einfach editieren kann. So habe ich auf einem dritten Laptop die Situation vorgefunden, daß ich bei der WLAN-Anmeldung auf der Fritz!Box in einem öffentlichen Netz bin (so legt W10 das einfach fest), wenn ich aber über einen AP gehe, der per Draht mit genau dieser Fritz!Box verbunden ist, bin ich in einem privaten Netz. Und irgendwie folgt daraus, daß ich über WLAN auf die Fritz!Box auf diesem Laptop kein Internet habe, über den AP aber schon. Diesem Bug muß ich noch weiter hinterherrecherchieren, das verstehe, wer will.
Wie auch immer, nachdem ich also heute morgen mit vier verschiedenen Rechnern herumhantiert habe, um der RDP-Sache auf den Grund zu gehen, fiel mir nach dem zwanzigsten oder dreißigsten Start des RDP-Clients diese Geschichte mit dem Gateway-Server ein, dessen Einrichtung ist nämlich viele Monate her, und manche Dinge rücken im Gedächtnis immer weiter in die Ferne, je länger sie zurückliegen, ohne zwischendurch einmal aufgefrischt worden zu sein.
Ich würde jetzt gerne über Microsoft meckern, Grund genug hätte ich ja wohl, aber ich verkneife mir das. Ich hoffe jedoch, daß diese Fehlerbeschreibung anderen vielleicht hilft, etwas Zeit zu sparen.
PS: Mittlerweile habe ich auf der Fritz!Box 7362 SL das WLAN abgeschaltet. Seit einigen Tagen funktioniert das WLAN auf der Box nicht mehr richtig, kein Gerät kann mehr eine zuverlässige Verbindung zu ihr aufbauen. An der Fritz!Box hängt per Draht schon längere Zeit ein Zyxel AP, Typ NBG6515, der glücklicherweise (noch) stabil arbeitet. Er war schon relativ früh erforderlich, als die Fritz!Box ins Haus kam, vereinzelte Geräte hatten von Anfang an mit ihr Probleme. Als Repeater werkelt ein Netgear, Hardware Version WN2000RPTv3, den ich absolut empfehlen kann (habe mittlerweile ein halbes Dutzend von ihnen unter verschiedensten Bedingungen installieren und erfolgreich konfigurieren können)! Auch dieses Gerät bekam seit einiger Zeit keine Verbindung mehr zur Fritz!Box. Jetzt habe ich auch ihn mit dem Zyxel-AP verbunden, womit wieder alles funktioniert, wie es soll.
Meine Empfehlung: Fritz!Box-WLAN abschalten!
PPS: Der Netgear hat auch einen Bug: Obwohl er keinen Restart nach Änderung des Default-Gateways verlangt, ist er dennoch erforderlich. Auf Grund der geringen Komplexität der Konfiguration ist das allerdings ein verzeihlicher Bug, denn man findet ihn praktisch stante pede. Aber Bug ist Bug…
Kolloquia 