☰

Configuración

tag-icon • tag-icon ssh vpn rdp ssh-tunnel
Configuración

Configuración

Una pequeña empresa (demasiado pequeña para justificar un Terminal Services Gateway) quiere que ciertos usuarios puedan acceder a sus escritorios con Windows 10 desde casa.

He tenido buena suerte con el Escritorio remoto de Windows para este propósito; sin embargo, las mejores prácticas sugieren no exponer el puerto RDP directamente. Esrecomendado para proteger RDP a través de una VPN, sin embargo, en el pasado normalmente configuré un túnel SSH para este propósito, ya que estaba más familiarizado con eso.

Asumiré que el cliente tiene alguna computadora que puede ejecutar un servidor SSH y me referiré a ella como SSH_SERVER. En mi caso, generalmente ya hay una computadora Linux o BSD en las instalaciones, ya sea como servidor de archivos o que actúa como firewall (por ejemplo, FreeNAS, pfSense); de lo contrario, normalmente coloco una PC reconstruida específicamente para realizar este trabajo.

Versión de reenvío de puertos SSH

En esta sección incluyo los detalles de cómo configuro el reenvío de puertos SSH para un cliente que necesita acceso al Escritorio remoto de Windows.

  1. Configure la autenticación de solo clave para SSH SSH_SERVERy abra el firewall para exponer esto en algún puerto no estándar <EXT_SSH_PORT>. Nota: este es elsolopuerto externo que alguna vez abro,todoLa comunicación con la red se realiza mediante reenvío de puertos a través de SSH.
  2. Para cada cliente que quiera conectarse de forma remota, genero un usuario SSH_SERVERcon el shell configurado en /bin/false.
  3. Agregue restricciones SSH que permitan al usuario reenviar puertos solo para el puerto y dispositivo al que desea conectarse. Por ejemplo, agrego lo siguiente al /etc/sshd_confarchivo:
Match User <USERNAME>
  AllowAgentForwarding no
  PermitOpen <USER'S_WINDOWS_DESKTOP_IP>:3389
  ForceCommand echo 'This account is restricted.'

(discusión más profundaaquí).

  1. Para cadadispositivocon el que el usuario quiere conectarse, genero un par de claves que está encriptado con una contraseña que le proporciono. Luego (a) agrego la clave pública al ~/.ssh/authorized_keysarchivo del usuario y (b) transfiero de forma segura la clave privada al dispositivo del usuario.
  2. Creo alguna forma de configurar fácilmente el túnel SSH, ya sea con un script simple que simplemente se ejecuta ssh -L 10000:<USER'S_WINDOWS_DESKTOP_IP>:3389 <OFFICE_EXTERNAL_IP> -p <EXT_SSH_PORT>o usando un software auxiliar (por ejemplo, paraMac OS, paraventanas).
  3. Agrego un acceso directo para una sesión RDP a localhost:10000.

Este método ha funcionado bastante bien, pero siempre sentí que no era lo suficientemente "profesional" y que algún día debería convertir estos túneles SSH en VPN.

Limitaciones de VPN

Estaba explorando esto con L2TP/IPSEC (en una UniFi Dream Machine, aunque creo que las limitaciones aquí no son específicas del enrutador) e inmediatamente me encontré con algunas limitaciones:

  1. La red de la oficina debe tener una subred IP diferente a la subred del cliente.Esto sería una molestia menor, pero supongamos que pudiera hacerlo. Por otro lado, me parece bastante insatisfactorio que esencialmente solo esté esperando elegir una subred que el clientenuncaestá encendido: ¿qué pasa si están visitando otra empresa y usando su wifi, y por casualidad eliges la misma subred que el proveedor de TI desde allí?
  2. No está claro cómo restringir la comunicación a un solo puerto para una sola PC, por usuario.Sé que puedo configurarlo para que los usuarios de VPN sean ubicados en una VLAN separada y luego agregar reglas de firewall que limiten las conexiones desde esa VLAN al puerto 3389 en escritorios RDP específicos, pero eso no impide que USER_A intente conectarse al escritorio de USER_B. . Si también abro puertos distintos de RDP por algún motivo, entonces todos los usuarios de VPN también tendrían acceso a estos puertos, a menos que pongacada usuarioen supropioVLAN, lo que parece una sobrecarga administrativa adicional para una característica que básicamente ya tengo "gratis" con SSH.
  3. No hay seguridad clara por dispositivo.Con el enfoque SSH que mencioné anteriormente, si a USER_A le roban su computadora portátil, no hay ninguna preocupación real. Por un lado, la clave privada está cifrada, por lo que, a menos que la computadora portátil haya sido robada mientras el usuario estaba conectado activamente, no debería poder acceder a la red de la oficina. Además, para mayor seguridad, puedo simplemente eliminar la clave asociada con la computadora portátil robada ~/.ssh/authorized_keysy todos los demás dispositivos que posee el cliente (por ejemplo, una computadora de escritorio personal) seguirán funcionando sin configuración adicional.

TL;DR: ¿Por qué alguien preferiría usar una VPN en lugar de reenvío de puertos SSH?

Parece que el único caso en el que es preferible una VPN es cuando quierestodocomunicación a través de la red de la oficina y usted tiene cierto nivel de conocimiento/control sobre la red remota. (Las VPN de sitio a sitio entran en esta categoría).

¿Me estoy perdiendo de algo? ¿Las VPN ofrecen más rendimiento y/o seguridad que el reenvío de puertos SSH?

Respuesta1

La solución SSH propuesta me parece demasiado compleja para el problema que nos ocupa.

Dos sugerencias:

  1. Utilice una VPN junto con una solución 2FA/MFA como Duo.

  2. Si una VPN es problemática, utilice una solución de acceso remoto diferente, como Teamviewer, AnyDesk, etc. junto con un proveedor de 2FA/MFA como Duo.

Puede crear una cuenta Duo gratuita para usar con hasta 10 usuarios.

información relacionada