☰

Параметр

tag-icon • tag-icon ssh vpn rdp ssh-tunnel
Параметр

Параметр

Малое предприятие (слишком маленькое, чтобы оправдать установку шлюза служб терминалов) хочет, чтобы определенные пользователи могли получать доступ к своим рабочим столам Windows 10 из дома.

Мне повезло с Windows Remote Desktop для этой цели, однако лучшая практика подсказывает не открывать порт RDP напрямую. Эторекомендуется защищать RDP через VPN, однако раньше я обычно настраивал для этой цели SSH-туннель, поскольку он был мне более знаком.

Я предположу, что у клиента есть компьютер, на котором может работать SSH-сервер, и буду называть его SSH_SERVER. В моем случае обычно локально уже есть компьютер Linux или BSD, который либо используется в качестве файлового сервера, либо выполняет функции брандмауэра (например, FreeNAS, pfSense), если нет, я обычно подключаю перестроенный ПК специально для выполнения этой задачи.

Версия переадресации портов SSH

В этом разделе я подробно расскажу, как настроить переадресацию портов SSH для клиента, которому необходим доступ к удаленному рабочему столу Windows.

  1. Настройте аутентификацию только по ключу для SSH SSH_SERVERи откройте брандмауэр, чтобы раскрыть его на каком-то нестандартном порту <EXT_SSH_PORT>. Примечание: этотольковнешний порт я когда-либо открывал,всеСвязь с сетью осуществляется посредством переадресации портов по протоколу SSH.
  2. Для каждого клиента, который хочет подключиться удаленно, я создаю пользователя SSH_SERVERс оболочкой, установленной на /bin/false.
  3. Добавьте ограничения SSH, позволяющие пользователю перенаправлять порты только для порта и устройства, к которым он хочет подключиться. Например, я добавляю в файл следующее /etc/sshd_conf:
Match User <USERNAME>
  AllowAgentForwarding no
  PermitOpen <USER'S_WINDOWS_DESKTOP_IP>:3389
  ForceCommand echo 'This account is restricted.'

(более подробное обсуждениездесь).

  1. Для каждогоустройствок которому пользователь хочет подключиться, я генерирую пару ключей, которая зашифрована паролем, который я им предоставляю. Затем я (a) добавляю открытый ключ в ~/.ssh/authorized_keysфайл пользователя и (b) безопасно передаю закрытый ключ на устройство пользователя.
  2. Я создаю способ простой настройки SSH-туннеля, либо с помощью простого скрипта, который просто запускается, ssh -L 10000:<USER'S_WINDOWS_DESKTOP_IP>:3389 <OFFICE_EXTERNAL_IP> -p <EXT_SSH_PORT>либо с помощью вспомогательного программного обеспечения (например,ОС Mac, дляОкна).
  3. Я добавляю ярлык для сеанса RDP в localhost:10000.

Этот метод работал достаточно хорошо, но я всегда чувствовал, что он недостаточно «профессиональный», и что когда-нибудь мне придется преобразовать эти SSH-туннели в VPN.

Ограничения VPN-сети

Я исследовал это с помощью L2TP/IPSEC (на UniFi Dream Machine, хотя я думаю, что ограничения здесь не являются специфическими для маршрутизатора) и сразу же столкнулся с некоторыми ограничениями:

  1. Офисная сеть должна иметь IP-подсеть, отличную от клиентской подсети.Это было бы незначительной неприятностью, но предположим, я мог бы это сделать. С другой стороны, я нахожу довольно неудовлетворительным то, что вы по сути просто надеетесь, что выберете подсеть, которую клиентникогдаслучайно находитесь в сети — что, если они посещают какую-то другую компанию и используют ее Wi-Fi, а вы случайно выбрали ту же подсеть, что и поставщик ИТ-услуг оттуда?
  2. Непонятно, как ограничить связь одним портом для одного ПК для каждого пользователя.Я знаю, что могу настроить его так, чтобы пользователи VPN были помещены в отдельную VLAN, а затем добавить правила брандмауэра, которые ограничивают соединения из этой VLAN портом 3389 на определенных рабочих столах RDP, но это не остановит USER_A от попыток подключения к рабочему столу USER_B. Если я также открываю порты, отличные от RDP, по какой-то причине, то все пользователи VPN также будут иметь доступ к этим портам, если только я не добавлюкаждый пользовательв ихсобственныйVLAN, что, похоже, влечет за собой дополнительные административные издержки для функции, которая у меня по сути и так «бесплатно» есть благодаря SSH.
  3. Нет четкой защиты для каждого устройства.При подходе SSH, о котором я упоминал выше, если у USER_A украли ноутбук, то нет никаких реальных проблем. Во-первых, закрытый ключ зашифрован, поэтому, если ноутбук не был украден, когда пользователь был активно подключен, он не должен иметь доступа к офисной сети. Более того, для дополнительной безопасности я могу просто удалить ключ, связанный с украденным ноутбуком, из ~/.ssh/authorized_keys, и все остальные устройства, которыми владеет клиент (например, персональный компьютер), продолжат работать без дополнительной настройки.

TL;DR: Почему кто-то предпочитает использовать VPN вместо переадресации портов SSH?

Похоже, единственный случай, когда VPN предпочтительнее, — это когда вы хотитевсесвязь осуществляется через офисную сеть, и у вас есть некоторый уровень осведомленности/контроля над удаленной сетью. (VPN типа «сеть-сеть» попадают в эту категорию.)

Я что-то упустил? VPN предлагают большую производительность и/или безопасность, чем переадресация портов SSH?

решение1

Предложенное вами решение SSH кажется мне слишком сложным для рассматриваемой проблемы.

Два предложения:

  1. Используйте VPN в сочетании с решением 2FA/MFA, например Duo.

  2. Если VPN вызывает проблемы, используйте другое решение для удаленного доступа, например Teamviewer, AnyDesk и т. д., в сочетании с поставщиком 2FA/MFA, например Duo.

Вы можете создать бесплатную учетную запись Duo для использования с 10 пользователями.

Связанный контент