☰

Contexto

tag-icon • tag-icon ssh vpn rdp ssh-tunnel
Contexto

Contexto

Uma pequena empresa (muito pequena para justificar um Gateway de Serviços de Terminal) deseja que determinados usuários possam acessar seus desktops do Windows 10 em casa.

Tive sorte com a Área de Trabalho Remota do Windows para essa finalidade, mas as práticas recomendadas sugerem não expor a porta RDP diretamente. Isso érecomendado para proteger o RDP através de uma VPN, no entanto, no passado eu normalmente configurava um túnel SSH para essa finalidade, já que estava mais familiarizado com isso.

Presumirei que o cliente tenha algum computador que possa executar um servidor SSH e me referirei a ele como SSH_SERVER. No meu caso, geralmente já existe um computador Linux ou BSD no local, seja como servidor de arquivos ou atuando como firewall (por exemplo, FreeNAS, pfSense), caso contrário, normalmente coloco um PC reconstruído especificamente para lidar com esse trabalho.

Versão de encaminhamento de porta SSH

Nesta seção, incluo os detalhes de como configuro o encaminhamento de porta SSH para um cliente que precisa de acesso à Área de Trabalho Remota do Windows.

  1. Configure a autenticação somente de chave para SSH SSH_SERVERe abra o firewall para expor isso em alguma porta não padrão, <EXT_SSH_PORT>. Nota: este é oapenasporta externa que eu já abri,todosa comunicação com a rede é feita via encaminhamento de porta via SSH.
  2. Para cada cliente que deseja se conectar remotamente, eu gero um usuário SSH_SERVERcom shell definido como /bin/false.
  3. Adicione restrições SSH, permitindo que o usuário encaminhe apenas a porta e o dispositivo ao qual deseja se conectar. Por exemplo, adiciono o seguinte ao /etc/sshd_confarquivo:
Match User <USERNAME>
  AllowAgentForwarding no
  PermitOpen <USER'S_WINDOWS_DESKTOP_IP>:3389
  ForceCommand echo 'This account is restricted.'

(discussão mais aprofundadaaqui).

  1. Para cadadispositivocom o qual o usuário deseja se conectar, eu gero um par de chaves criptografado com uma senha que forneço a ele. Em seguida, (a) adiciono a chave pública ao ~/.ssh/authorized_keysarquivo do usuário e (b) transfiro com segurança a chave privada para o dispositivo do usuário.
  2. Eu crio uma maneira de configurar facilmente o túnel SSH, seja com um script simples que apenas roda ssh -L 10000:<USER'S_WINDOWS_DESKTOP_IP>:3389 <OFFICE_EXTERNAL_IP> -p <EXT_SSH_PORT>ou usando software auxiliar (por exemplo, paraMac OS, parajanelas).
  3. Eu adiciono um atalho para uma sessão RDP no arquivo localhost:10000.

Esse método funcionou bem, mas sempre achei que não era "profissional" o suficiente e que algum dia deveria converter esses túneis SSH em VPNs.

Limitações da VPN

Eu estava explorando isso com L2TP/IPSEC (em uma UniFi Dream Machine, embora eu ache que as limitações aqui não são específicas do roteador) e imediatamente me deparei com algumas limitações:

  1. A rede do escritório deve ter uma sub-rede IP diferente da sub-rede do cliente.Isso seria um pequeno aborrecimento, mas suponha que eu pudesse fazer isso. Por outro lado, acho bastante insatisfatório que você esteja essencialmente apenas esperando escolher uma sub-rede que o cliente iránuncaacontecer de estar ativado - e se eles estiverem visitando alguma outra empresa e usando seu wifi, e você escolher a mesma sub-rede que o fornecedor de TI de lá?
  2. Não está claro como restringir a comunicação a uma única porta para um único PC, por usuário.Eu sei que posso configurá-lo para que os usuários VPN sejam colocados em uma VLAN separada e, em seguida, adicionem regras de firewall que limitam as conexões dessa VLAN à porta 3389 em desktops RDP específicos, mas isso não impede que USER_A tente se conectar à área de trabalho de USER_B . Se eu também abrir portas diferentes do RDP por algum motivo, todos os usuários VPN também terão acesso a essas portas, a menos que eu coloquecada usuárioem seuterVLAN, o que parece uma sobrecarga administrativa adicional para um recurso que basicamente já tenho "de graça" com SSH.
  3. Nenhuma segurança clara por dispositivo.Com a abordagem SSH mencionada acima, se USER_A tiver seu laptop roubado, não há preocupação real. Por um lado, a chave privada é criptografada, portanto, a menos que o laptop tenha sido roubado enquanto o usuário estava ativamente conectado, ele não conseguiria acessar a rede do escritório. Além disso, para maior segurança, posso simplesmente remover a chave associada ao laptop roubado ~/.ssh/authorized_keyse todos os outros dispositivos que o cliente possui (por exemplo, um desktop pessoal) continuarão a funcionar sem configuração adicional.

TL;DR: Por que alguém preferiria usar uma VPN em vez de encaminhamento de porta SSH?

Parece que o único caso em que uma VPN é preferível é quando você desejatodoscomunicação passando pela rede do escritório e você tem algum nível de conhecimento/controle sobre a rede remota. (VPNs site a site se enquadram nesta categoria.)

Estou faltando alguma coisa aqui? As VPNs oferecem mais desempenho e/ou segurança do que o encaminhamento de porta SSH?

Responder1

Sua solução SSH proposta me parece excessivamente complexa para o problema em questão.

Duas sugestões:

  1. Use uma VPN em conjunto com uma solução 2FA/MFA como o Duo.

  2. Se uma VPN for problemática, use uma solução de acesso remoto diferente, como Teamviewer, AnyDesk, etc. em conjunto com um provedor 2FA/MFA como o Duo.

Você pode criar uma conta Duo gratuita para usar com até 10 usuários.

informação relacionada