SSH-Weiterleitung, VPN oder RD Gateway: Welcher Weg für einen RDP-Desktop?
Ein weitergeleiteter Port, ein gerouteter Arbeitsbereich oder ein Desktop-Gateway: Vergleichen Sie die Reichweite, die jedes bietet, und wer es betreiben muss, bevor Sie wählen.
Alle drei Optionen übertragen RDP, das Protokoll ist also nicht der entscheidende Faktor. Die eigentliche Frage ist, wie viel Reichweite ein Nutzer erhalten sollte und wer das betreibt, was sie gewährt. Ein weitergeleiteter TCP-Port, ein geroutetes privates Netzwerk und ein Desktop-Gateway beantworten diese Frage in drei verschiedenen Größen. Wählen Sie zuerst die Größe, dann folgt das Produkt.
Die Frage ist der Umfang, nicht das Protokoll
Notieren Sie, was der Nutzer tatsächlich erreichen muss. Ist die Antwort ein Desktop, ist ein Entwurf, der ein Subnetz gewährt, zu weit gefasst. Ist die Antwort ein Desktop plus Dateifreigaben plus eine Verwaltungskonsole, kommt ein Entwurf, der einen Port weiterleitet, nächsten Monat für zwei weitere Weiterleitungen zurück. Die Liste der Ziele ist die Anforderung; alles andere ist Umsetzung.
Halten Sie die Einstiegsidentität getrennt vom Windows-Konto, das sich am Desktop anmeldet. Jeder Entwurf unten hat beides, und deren Vermischung führt dazu, dass ein Jump-Host-Konto mehr Befugnisse erhält, als jemand beabsichtigt hat.
Ein weitergeleiteter TCP-Dienst
Ein genehmigter SSH-Jump-Host kann einen lokalen Listener an den RDP-Dienst weiterleiten, den er erreichen kann. Binden Sie diesen Listener an Loopback, wenn er nur für den Rechner des Nutzers existiert, was die übliche Absicht einer lokalen Weiterleitung ist. Die Weiterleitung ist eine Bequemlichkeit für eine Person, kein Dienst für ein Team.
Die SSH-Anmeldung authentifiziert den Zugang zum Weiterleitungspfad und nichts weiter. Windows-Authentifizierung und RDP-Autorisierung finden weiterhin am Ziel statt, ein gültiges Jump-Konto ist also keine gültige Desktop-Sitzung. Das sind zwei unabhängige Tore, und beide müssen sich öffnen.
Beschränken Sie die Weiterleitungsziele des Jump-Kontos, statt eine uneingeschränkte Shell zu gewähren. Dieser Entwurf eignet sich für eine kleine, ausdrücklich gelistete Gruppe von Rechnern, und er fügt einen Host, eine Identität und einen Lebenszyklus zum Betreiben hinzu. Dieser zusätzliche Host ist der Teil, den Leute beim Vergleich mit einem Gateway vergessen: Jemand muss ihn patchen, überwachen und seine Schlüssel besitzen.
Ein gerouteter privater Arbeitsbereich
Ein VPN bietet privates DNS und Zugang zu mehreren gemeinsam genutzten Diensten, und das ist sein eigentlicher Wert. Einen Desktop-Port zu verbergen ist ein Nebeneffekt, nicht der Grund, es zu bauen. Diese Unterscheidung zählt, wenn jemand fragt, warum das VPN überhaupt existiert.
Beschränken Sie Routen und Ressourcenberechtigungen auf die vorgesehenen Ziele. Ein verbundener Nutzer verdient nicht automatisch das ganze LAN, und die Zielfirewall plus Windows-Anmelderechte bleiben getrennte Grenzen, die das VPN nicht ersetzt.
Diese Anordnung ist für einen etablierten verwalteten Arbeitsbereich bequem. Der Preis ist, dass Onboarding, Geräteanforderungen, Resolver-Verhalten und Verbindungsrichtlinie Teil der Arbeitsumgebung des Nutzers werden, und jemand muss sie besitzen. Vergleichen Sie diesen Preis mit der Lizenzierung des Gateways, bevor Sie annehmen, das VPN sei die günstigere Option.
Ein RDP-spezifisches Gateway
Remote Desktop Gateway bietet eine RDP-spezifische Grenze statt einer Netzwerkgrenze. Seine Verbindungsautorisierungsrichtlinie entscheidet, wer sich verbinden darf, und seine Ressourcenautorisierungsrichtlinie entscheidet, welche internen Ressourcen sie darüber erreichen dürfen. Beide Richtlinien sind Teil des Produkts, keine optionalen Extras.
Planen Sie Zertifikate, Identitätsintegration und erforderliche Transporte gemeinsam. Das Gateway ist kein anonymer TCP-Relay, und es als einen solchen einzusetzen, überspringt die Richtlinien, die es überhaupt rechtfertigen. Es bringt außerdem Lizenz- und Betriebsanforderungen mit, die ein einzelner weitergeleiteter Port nicht hat. Kalkulieren Sie diese vor der Designprüfung ein, nicht danach.
Wo ein Team bereits zentralen Desktop-Zugang betreibt, sind diese Gemeinkosten bereits bezahlt. Wo eine Person einen Rechner braucht, ist es ein großer Rechner für eine kleine Aufgabe.
Was alle drei weiterhin brauchen
Behalten Sie Host-Identitätsprüfungen in jedem Entwurf bei. Ein lokaler Alias oder ein Tunnel macht ein unerwartetes Zertifikat nicht harmlos, und ein nicht passendes Zertifikat zu akzeptieren, um durch einen Proxy zu kommen, untergräbt den Sinn des Tunnels. Der Name im Client und der Name im Zertifikat müssen bewusst in Einklang gebracht werden.
Wenden Sie MFA am Einstiegspunkt an, wo die Richtlinie es verlangt, und behalten Sie die Kontokontrollen des Ziels bei. Die beiden ergänzen sich: Das erste entscheidet, wer die Tür erreichen darf, das zweite, wer sie öffnen darf. Lässt man eines weg, bleibt ein Entwurf, der vollständig aussieht und es nicht ist.
Wählen Sie die Grenze, die zur Arbeit und zum Betriebsmodell passt, das Sie tatsächlich haben. Übersicht der RDS-Rollen beschreibt den Platz des Gateways unter dem Sitzungshost und anderen Komponenten, und das ist der Kontext, der seine Kosten lesbar macht.