Einstellung

Einstellung

Einstellung

Ein kleines Unternehmen (zu klein, um ein Terminal Services Gateway zu rechtfertigen) möchte, dass bestimmte Benutzer von zu Hause aus auf ihre Windows 10-Desktops zugreifen können.

Ich habe zu diesem Zweck gute Erfahrungen mit Windows Remote Desktop gemacht, aber die beste Vorgehensweise empfiehlt, den RDP-Port nicht direkt freizugeben. Es istempfohlen, RDP über ein VPN zu sichern, allerdings habe ich zu diesem Zweck in der Vergangenheit normalerweise einen SSH-Tunnel eingerichtet, da ich damit besser vertraut war.

Ich gehe davon aus, dass der Client über einen Computer verfügt, auf dem ein SSH-Server laufen kann, und bezeichne ihn als SSH_SERVER. In meinem Fall ist normalerweise bereits ein Linux- oder BSD-Computer vor Ort, entweder als Dateiserver oder als Firewall (z. B. FreeNAS, pfSense). Wenn nicht, nutze ich normalerweise einen speziell für diese Aufgabe umgebauten PC.

SSH-Portweiterleitungsversion

In diesem Abschnitt erläutere ich im Detail, wie ich die SSH-Portweiterleitung für einen Client einrichte, der Windows-Remotedesktopzugriff benötigt.

  1. Richten Sie die Key-Only-Authentifizierung für SSH ein SSH_SERVERund öffnen Sie die Firewall, um dies auf einem nicht standardmäßigen Port verfügbar zu machen <EXT_SSH_PORT>. Hinweis: Dies ist dienurexterner Port, den ich jemals öffne,alleDie Kommunikation mit dem Netzwerk erfolgt per Portweiterleitung über SSH.
  2. Für jeden Client, der eine Remoteverbindung herstellen möchte, erstelle ich einen Benutzer SSH_SERVERmit der auf eingestellten Shell /bin/false.
  3. Fügen Sie SSH-Einschränkungen hinzu, die es dem Benutzer ermöglichen, nur für den Port und das Gerät, mit dem er eine Verbindung herstellen möchte, Portweiterleitungen vorzunehmen. Ich füge der /etc/sshd_confDatei beispielsweise Folgendes hinzu:
Match User <USERNAME>
  AllowAgentForwarding no
  PermitOpen <USER'S_WINDOWS_DESKTOP_IP>:3389
  ForceCommand echo 'This account is restricted.'

(ausführlichere DiskussionHier).

  1. Für jedeGerätmit dem der Benutzer eine Verbindung herstellen möchte, erzeuge ich ein Schlüsselpaar, das mit einem Passwort verschlüsselt ist, das ich ihm mitteile. Dann (a) füge ich den öffentlichen Schlüssel zur ~/.ssh/authorized_keysDatei des Benutzers hinzu und (b) übertrage ich den privaten Schlüssel sicher auf das Gerät des Benutzers.
  2. Ich habe eine Möglichkeit geschaffen, den SSH-Tunnel einfach einzurichten, entweder mit einem einfachen Skript, das einfach ausgeführt wird, ssh -L 10000:<USER'S_WINDOWS_DESKTOP_IP>:3389 <OFFICE_EXTERNAL_IP> -p <EXT_SSH_PORT>oder mit einer Hilfssoftware (z. B. fürMac OS, fürWindows).
  3. Ich füge eine Verknüpfung für eine RDP-Sitzung hinzu localhost:10000.

Diese Methode hat recht gut funktioniert, aber ich hatte immer das Gefühl, dass sie nicht „professionell“ genug war und dass ich diese SSH-Tunnel eines Tages in VPNs umwandeln sollte.

VPN-Einschränkungen

Ich habe dies mit L2TP/IPSEC ausprobiert (auf einer UniFi Dream Machine, obwohl ich glaube, dass die Einschränkungen hier nicht spezifisch auf den Router bezogen sind) und bin sofort auf einige Einschränkungen gestoßen:

  1. Das Büronetzwerk muss ein anderes IP-Subnetz als das Client-Subnetz haben.Das wäre zwar ein kleines Ärgernis, aber ich nehme an, ich könnte das tun. Andererseits finde ich es ziemlich unbefriedigend, dass man im Grunde nur hofft, dass man ein Subnetz auswählt, das der Clientniemalsonline sind - was passiert, wenn sie ein anderes Unternehmen besuchen und deren WLAN verwenden und Sie zufällig dasselbe Subnetz ausgewählt haben wie der dortige IT-Anbieter?
  2. Es ist nicht klar, wie die Kommunikation pro Benutzer auf einen einzigen Port für einen einzigen PC beschränkt werden kann.Ich weiß, dass ich es so einrichten kann, dass VPN-Benutzer in einem separaten VLAN platziert werden und dann Firewall-Regeln hinzufügen kann, die Verbindungen von diesem VLAN auf Port 3389 auf bestimmten RDP-Desktops beschränken, aber das hindert USER_A nicht daran, eine Verbindung zum Desktop von USER_B herzustellen. Wenn ich aus irgendeinem Grund auch andere Ports als RDP öffne, haben alle VPN-Benutzer auch Zugriff auf diese Ports, es sei denn, ich setzejeder Benutzerin ihrereigenVLAN, was wie zusätzlicher Verwaltungsaufwand für eine Funktion erscheint, die ich mit SSH im Grunde bereits „kostenlos“ habe.
  3. Keine klare Sicherheit pro Gerät.Mit dem oben erwähnten SSH-Ansatz besteht kein wirklicher Grund zur Sorge, wenn USER_A sein Laptop gestohlen wird. Erstens ist der private Schlüssel verschlüsselt, sodass der Benutzer, sofern der Laptop nicht gestohlen wurde, während er aktiv verbunden war, nicht auf das Büronetzwerk zugreifen kann. Darüber hinaus kann ich zur zusätzlichen Sicherheit einfach den mit dem gestohlenen Laptop verknüpften Schlüssel entfernen ~/.ssh/authorized_keys, und alle anderen Geräte des Kunden (z. B. ein persönlicher Desktop) funktionieren weiterhin ohne zusätzliche Konfiguration.

TL;DR: Warum sollte jemand ein VPN der SSH-Portweiterleitung vorziehen?

Es scheint, dass der einzige Fall, in dem ein VPN vorzuziehen ist, ist, wenn Sie wollenalleDie Kommunikation läuft über das Büronetzwerk und Sie haben ein gewisses Maß an Einblick/Kontrolle über das Remotenetzwerk. (Site-to-Site-VPNs fallen in diese Kategorie.)

Übersehe ich hier etwas? Bieten VPNs mehr Leistung und/oder Sicherheit als die SSH-Portweiterleitung?

Antwort1

Ihre vorgeschlagene SSH-Lösung erscheint mir für das vorliegende Problem zu komplex.

Zwei Vorschläge:

  1. Verwenden Sie ein VPN in Verbindung mit einer 2FA/MFA-Lösung wie Duo.

  2. Wenn ein VPN problematisch ist, verwenden Sie eine andere Remote-Zugriffslösung wie Teamviewer, AnyDesk usw. in Verbindung mit einem 2FA/MFA-Anbieter wie Duo.

Sie können ein kostenloses Duo-Konto für die Verwendung mit bis zu 10 Benutzern erstellen.

verwandte Informationen