Настройка

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

Мне повезло с удаленным рабочим столом Windows для этой цели, однако передовая практика предлагает не открывать порт 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.'

(более подробное обсуждение Вот).

4. Для каждого устройство с которым пользователь хочет подключиться, я генерирую пару ключей, которая зашифрована паролем, который я им предоставляю. Затем я (а) добавляю открытый ключ к пользователю ~/.ssh/authorized_keys файл и (б) безопасно передать закрытый ключ на устройство пользователя.
5. Я создаю способ простой настройки туннеля SSH с помощью простого скрипта, который просто запускается ssh -L 10000:<USER'S_WINDOWS_DESKTOP_IP>:3389 <OFFICE_EXTERNAL_IP> -p <EXT_SSH_PORT> или с помощью вспомогательного программного обеспечения (например, для Mac OS, для Windows).
6. Я добавляю ярлык для сеанса 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?