Saltar para o conteudo
Avanet

Configurar Clientless SSL VPN na Sophos Firewall para RDP e SSH

Sophos Firewall

Com Clientless SSL VPN, uma Sophos Firewall disponibiliza ligações internas individuais RDP, SSH, VNC ou a servidores de ficheiros diretamente no browser. O utilizador não instala um cliente VPN nem obtém acesso geral a uma rede interna. Em vez disso, inicia sessão no VPN Portal e vê apenas os bookmarks publicados pela respetiva Clientless Policy.

O nome semelhante pode conduzir facilmente à configuração errada: Clientless Users associa internamente um IP fixo a uma identidade. Não publica bookmarks nem faz parte deste procedimento de Remote Access.

O início de sessão no VPN Portal e a autenticação no destino são dois passos distintos. Clientless SSL VPN não suporta Credential Passthrough: a palavra-passe do VPN Portal não é automaticamente transmitida para o início de sessão no Windows ou SSH. Por conseguinte, dois inícios de sessão são normais, desde que não estejam guardadas credenciais do destino no bookmark.

O procedimento principal é curto:

  1. Definir o sistema de destino fixo, a porta e o grupo de utilizadores autorizado.
  2. Em Remote access VPN > Clientless SSL VPN policy > Bookmarks, criar um bookmark RDP ou SSH.
  3. Em Policies, associar o grupo de utilizadores ao bookmark.
  4. Proteger VPN Portal, certificado, autenticação, MFA e Device Access.
  5. Testar o acesso a partir do exterior em VPN > Clientless access connections com um utilizador autorizado e outro não autorizado.

Quando Clientless SSL VPN é adequado — e quando não é

Clientless Access é especialmente adequado para poucos destinos fixos, acessos ocasionais ou técnicos externos quando não se pretende instalar um cliente VPN no dispositivo utilizado. Desta forma, RDP e SSH não precisam de ser publicados diretamente na Internet através de DNAT. Em vez disso, fica acessível publicamente o VPN Portal protegido.

No entanto, não substitui todos os cenários de Remote Access VPN:

  • Clientless SSL VPN é adequado para destinos RDP, SSH, VNC ou servidores de ficheiros individuais e estáticos que possam ser utilizados no browser.
  • Sophos Connect com IPsec ou SSL VPN é mais adequado quando um dispositivo gerido necessita de várias redes, aplicações nativas, DNS ou protocolos diferentes. O guia de decisão para Remote Access enquadra as variantes.
  • ZTNA destina-se a um acesso permanente orientado para aplicações, com identidade, estado do dispositivo e policies centrais. Os princípios básicos encontram-se em O que é Zero Trust Network Access?.
  • RD Gateway, Jump Host ou PAM devem ser considerados quando a administração privilegiada, contas pessoais no destino, gravação de sessões ou fluxos de aprovação são determinantes.

No caso do RDP, também é importante ter em conta que a área de transferência não é suportada em sessões Clientless desde o SFOS 19. Se copy-and-paste ou outras funções RDP nativas forem indispensáveis para o fluxo de trabalho, um caminho de acesso baseado num cliente ou especializado é uma escolha mais adequada.

Clientless SSL VPN não suporta endereços IP de destino dinâmicos. Embora seja permitido utilizar um nome de host como destino, a firewall tem de o resolver de forma estável para o sistema previsto. Um destino que muda frequentemente não deve ser planeado como um cenário Dynamic DNS atualizado de forma fiável.

O browser é apenas a interface: estabelece a ligação HTTPS ao VPN Portal, enquanto a Sophos Firewall estabelece uma segunda ligação ao destino. O bloqueador de pop-ups deve permitir a nova janela para o FQDN do portal. O SFOS 22 não publica aplicações HTTP ou HTTPS internas arbitrárias como bookmarks Clientless; consoante os requisitos, deve utilizar-se WAF ou ZTNA.

Requisitos e valores de exemplo

Antes da configuração, devem estar definidos o destino, a identidade e o acesso ao portal:

  • O sistema de destino é alcançável a partir da firewall através de routing e DNS, e o serviço necessário está em execução.
  • Existe na firewall ou no servidor de autenticação associado um utilizador ou, de preferência, um grupo restrito.
  • O VPN Portal dispõe de um FQDN público ou acessível internamente e de um certificado fidedigno correspondente.
  • Em Authentication > Services, está selecionado um método adequado em VPN portal authentication methods.
  • Estão preparados MFA e um acesso de recuperação independente.
  • Foi decidido se as credenciais do destino podem ser guardadas no bookmark.

O exemplo RDP seguinte utiliza:

  • VPN Portal: https://vpn.example.com
  • servidor de destino: rdp-app01.intern.example
  • IP de destino: 10.20.30.25
  • porta RDP: 3389
  • bookmark: RDP-Fibu-Test
  • grupo: Clientless-RDP-Fibu
  • policy: Clientless-RDP-Fibu
  • segurança RDP para o primeiro teste: TLS
  • Automatic login: desativado
  • Share session: desativado

example.com é um domínio de exemplo reservado e 10.20.30.25 é um endereço privado de exemplo. O FQDN, o IP, o grupo e os nomes têm de ser substituídos pelos valores do próprio ambiente. A porta 3389 só continua correta se o servidor Windows utilizar efetivamente a porta RDP padrão.

Configurar o bookmark RDP

Bookmark com TLS e autenticação pessoal no destino

Em Remote access VPN > Clientless SSL VPN policy > Bookmarks, cria-se um novo bookmark com Add:

  1. Em Name, introduzir RDP-Fibu-Test.
  2. Em Type, selecionar RDP.
  3. Em URL, introduzir rdp-app01.intern.example ou o IP fixo 10.20.30.25.
  4. Utilizar a porta de serviço 3389. Só se introduz uma porta diferente se tiver sido configurada deliberadamente de outra forma no sistema de destino.
  5. Manter Automatic login desativado para o primeiro teste.
  6. Se necessário, introduzir o domínio de rede Windows, por exemplo, CORP ou corp.example.com.
  7. Em Protocol security, selecionar TLS. A terceira opção, RDP, utiliza a segurança própria do protocolo RDP; a Sophos recomenda TLS ou NLA.
  8. Manter Share session desativado.
  9. Guardar com Save.

Sem Automatic login, o utilizador introduz as respetivas credenciais na janela RDP aberta. Desta forma, pode iniciar sessão com uma conta Windows pessoal, desde que o modelo de segurança do servidor de destino permita este modo TLS.

O certificado do VPN Portal e Protocol security: TLS cumprem funções diferentes. O certificado do portal protege o percurso do browser até à firewall. A definição RDP protege a ligação seguinte entre a firewall e o sistema Windows. Por conseguinte, um certificado de portal válido não substitui uma segurança RDP adequada.

Quando o servidor Windows exige NLA

Muitos sistemas Windows exigem Network Level Authentication (NLA). Neste caso, seleciona-se NLA no bookmark. O SFOS ativa assim Automatic login, e o nome de utilizador e a palavra-passe do sistema de destino têm de ser guardados no bookmark.

Não se trata apenas de uma opção de conveniência. Todos os utilizadores autorizados deste bookmark trabalham no sistema de destino com a mesma identidade Windows guardada. Para tal, deve ser utilizada apenas uma conta dedicada, com privilégios mínimos e passível de rotação. Contas Domain Admin, contas pessoais de administração e contas de serviço com privilégios amplos não devem ser guardadas num Clientless Bookmark.

O NLA não deve ser desativado no servidor Windows apenas para permitir o funcionamento do exemplo com TLS. Se não forem aceitáveis credenciais guardadas ou uma identidade de destino comum, Clientless RDP não é adequado para este servidor. Um VPN normal, RD Gateway, PAM ou um Jump Host controlado preservam melhor a rastreabilidade pessoal.

Share session também permanece desativado. A opção destina-se a um caso de colaboração planeado deliberadamente. Numa sessão partilhada, Stop session termina a ligação para todos os participantes, enquanto Suspend session pausa apenas o utilizador atual. Uma sessão de administração privilegiada não deve ser partilhada.

Bookmark VNC para sistemas Linux e UNIX

Um bookmark VNC segue o mesmo princípio básico, mas utiliza Type: VNC. Em URL, introduz-se o endereço IP fixo do sistema de destino ou um hostname com resolução estável. Só se indica outra porta VNC quando o serviço escuta efetivamente numa porta não padrão.

Com Automatic login, o SFOS guarda a palavra-passe do destino no bookmark VNC. Se a opção permanecer desativada, o utilizador introduz a palavra-passe ao abrir a ligação. Num bookmark VNC não se configura um nome de utilizador. Share session permanece desativado para acessos individuais normais e só é utilizado quando uma sessão partilhada é expressamente necessária.

ℹ️ Também no VNC, o login no VPN Portal não é transmitido ao sistema de destino. Por conseguinte, um login bem-sucedido no portal não comprova que a palavra-passe VNC está correta nem que a firewall consegue alcançar o serviço VNC.

Configurar a Clientless Policy e o VPN Portal

Associar utilizadores e bookmark numa policy

Um bookmark existente, por si só, ainda não torna o destino visível para nenhum utilizador. Só a policy associa a identidade ao recurso:

  1. Abrir Remote access VPN > Clientless SSL VPN policy.
  2. Em Policies, clicar em Add.
  3. Em Name, introduzir Clientless-RDP-Fibu.
  4. Em Policy members, selecionar apenas o grupo Clientless-RDP-Fibu.
  5. Em Published bookmarks, selecionar RDP-Fibu-Test.
  6. Guardar com Apply.

Um Bookmark Group só compensa quando os mesmos utilizadores precisam de vários destinos. Para um único destino RDP, apenas cria um nível adicional de gestão.

Proteger o VPN Portal

O utilizador abre as ligações Clientless através do VPN Portal. A porta padrão é 443; a porta e o certificado encontram-se em Administration > Admin and user settings > Admin console and end-user interaction. No exemplo, o certificado tem de conter vpn.example.com como SAN e ser aceite pelo browser sem aviso. Importar e atribuir certificados na Sophos Firewall explica a atribuição geral de certificados.

Em Administration > Device access, VPN portal tem de ser permitido para o acesso efetivamente necessário. Se o portal tiver de estar acessível a partir de todas as origens WAN, ativa-se WAN na matriz. Com redes de origem conhecidas, é preferível a variante mais restrita: manter WAN desativado na matriz e criar em Local service ACL exception rule uma regra com Source zone: WAN, o Source Network / Host concreto, o endereço necessário da firewall como Destination host, Services: VPN portal e Action: Accept. Uma exceção Accept adicional não restringe uma autorização WAN já ativada de forma geral na matriz. Isto não ativa automaticamente WebAdmin, User Portal, SSH ou SSL VPN. As Firewall Rules não controlam estes serviços locais. O planeamento seguro encontra-se em Device Access e Local Service ACL.

⚠️ Um VPN Portal acessível a partir da WAN é uma superfície pública de início de sessão. Não deve ser operado sem MFA, um certificado fidedigno, uma associação restrita à policy e monitorização dos inícios de sessão. Se VPN Portal e SSL VPN utilizarem a mesma porta, os Login security settings não funcionam. Se também utilizarem o mesmo protocolo, permitir SSL VPN a partir de uma zona torna igualmente acessível o VPN Portal, mesmo que esteja desativado para essa zona em Device access. Deve utilizar-se uma combinação única de porta e protocolo para cada serviço local e voltar a verificar o acesso depois de cada alteração da porta.

Para o Sophos OTP local, começa-se por utilizar Specific users and groups em Authentication > Multi-factor authentication. Para o autorregisto através de uma aplicação de autenticação, ativa-se Generate OTP token with next sign-in, seleciona-se VPN portal em Require MFA for e guarda-se com Apply. Este fluxo direto do código QR no VPN Portal aplica-se ao SFOS 22. No SFOS 23, com Generate OTP token with next sign-in ativado, selecionar também Share QR code antes de Apply: Email envia o código QR por e-mail no próximo início de sessão no VPN ou User Portal; Portals apresenta-o no User Portal e VPN Portal após o próximo início de sessão no VPN Portal, User Portal ou WebAdmin. Para o exemplo de leitura no portal, selecionar explicitamente Portals. O SFOS 22 suporta SHA1, SHA256 e SHA512, e a Sophos recomenda SHA256 ou SHA512. A aplicação tem, no entanto, de suportar o algoritmo escolhido: Intercept X for Mobile e Google Authenticator são compatíveis; o Microsoft Authenticator pode ler um código SHA256 ou SHA512, mas o início de sessão seguinte falha. Ao mudar de algoritmo, eliminam-se os tokens existentes em Issued tokens e volta-se a ler o código QR. Antes de os eliminar, confirmar que Generate OTP token with next sign-in está ativado para este fluxo. A entrega do novo código QR segue a mesma distinção de versões: o SFOS 22 apresenta-o no portal; o SFOS 23 utiliza Email ou Portals em Share QR code, mantendo Portals selecionado para este exemplo. A implementação piloto e o acesso de recuperação encontram-se em Ativar MFA na Sophos Firewall. O VPN Portal não suporta MFA RADIUS baseado em challenge; por isso, um método RADIUS existente tem de ser testado especificamente para este início de sessão no portal. Se o portal utilizar Microsoft Entra ID SSO e Conditional Access, Entra ID SSO para Sophos Connect e VPN Portal descreve toda a cadeia de identidade.

Em Authentication > Services, podem selecionar-se no máximo 20 servidores por método de autenticação. As definições globais Maximum session timeout e Simultaneous logins não são exclusivas do VPN Portal. O SFOS verifica a autorização a cada três minutos, e o limite de inícios de sessão simultâneos aplica-se apenas aos utilizadores adicionados depois da definição desse valor. Estes limites não devem, portanto, ser considerados controlos de acesso imediatos e específicos do portal.

Testar o acesso a partir do exterior

O teste deve ser realizado a partir de uma rede externa real, por exemplo, através de um hotspot móvel. Um teste a partir da LAN não demonstra que DNS, certificado, Device Access e um router a montante funcionam corretamente a partir da Internet.

  1. Abrir https://vpn.example.com numa janela privada do browser.
  2. Verificar o nome do certificado, a cadeia de certificados e o estado do browser.
  3. Iniciar sessão como membro de Clientless-RDP-Fibu e concluir o MFA.
  4. Em VPN > Clientless access connections, verificar se aparece RDP-Fibu-Test.
  5. Clicar em Connect. A sessão tem de abrir numa nova janela do browser.
  6. Com Automatic login desativado, introduzir as credenciais pessoais do Windows e verificar o início da sessão RDP.
  7. Terminar corretamente a sessão no sistema Windows e, em seguida, sair do VPN Portal.
  8. Testar com um utilizador que não pertença ao grupo. O bookmark não pode aparecer para esse utilizador.
  9. Remover temporariamente o utilizador de teste do grupo da policy e verificar se o acesso desaparece depois de um novo início de sessão.

O sucesso não significa apenas que aparece um ambiente de trabalho. O utilizador positivo vê exatamente os bookmarks previstos, o utilizador negativo não vê nenhum, o MFA é aplicado, o certificado é fidedigno, a autenticação no destino funciona e a sessão termina de forma rastreável no portal e no sistema de destino.

Utilizar os controlos de sessão e teclado no browser

Nas sessões RDP, VNC, SSH e Telnet, move-se o ponteiro para o limite superior do ecrã remoto para mostrar as opções de sessão. Em Connection estão disponíveis Stop session e Suspend session. Depois de Suspend session, o mesmo utilizador retoma a sessão quando volta a clicar em Connect no VPN Portal. Os restantes participantes de uma sessão partilhada continuam a trabalhar; Stop session, pelo contrário, termina-a para todos.

Nas ligações RDP e VNC, Keyboard permite selecionar atalhos de teclado e alterar o idioma do teclado. Para aplicar um dos idiomas da lista diferente do inglês, o procedimento documentado exige que o idioma do servidor de destino esteja definido como US English. Este requisito diz respeito à seleção do idioma em Keyboard, não à área de transferência.

Opções para SSH, VNC e servidores de ficheiros

Bookmark SSH com Host Key verificado

Para SSH, seleciona-se SSH como Type em Bookmarks > Add. Um exemplo utiliza srv-linux01.intern.example, a porta 22 e o utilizador clientless-test.

O Public host key tem de pertencer ao servidor esperado. Num destino Linux, é possível apresentar a Host Key pública diretamente na consola fidedigna do servidor e documentar o respetivo fingerprint:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Estes comandos são executados no servidor Linux de destino, não na Sophos Firewall. Se o servidor utilizar outro tipo de Host Key, o nome do ficheiro tem de ser adaptado em conformidade. Uma chave proveniente de um aviso não verificado no browser ou de um scan de rede arbitrário não deve ser aceite sem verificação.

O primeiro comando apresenta a Host Key ED25519 pública como exemplo de identificação na consola fidedigna do sistema de destino. Isto não confirma que a build SSH clientless instalada aceite ED25519 ou a representação OpenSSH apresentada em Public host key. Antes de a inserir, confirmar tanto o algoritmo aceite como a representação serializada da chave pública através da documentação oficial de SSH clientless aplicável a essa build ou com Sophos Support. O suporte SSH do Linux, as definições SSH do WebAdmin, SFTP e textos de origem idênticos não demonstram esta compatibilidade do campo. O segundo comando apresenta apenas o fingerprint para a comparação documentada; o fingerprint não é copiado para o campo em vez da chave.

Em seguida, cria-se o bookmark SSH completo:

  1. Em Name, introduzir, por exemplo, SSH-Linux-Test.
  2. Em Type, selecionar SSH.
  3. Em URL, introduzir srv-linux01.intern.example e utilizar a porta 22.
  4. Em Username, definir clientless-test ou o utilizador de destino previsto.
  5. Manter Automatic login desativado se o utilizador tiver de introduzir a palavra-passe do destino.
  6. Inserir em Public host key a Host Key pública verificada diretamente no sistema de destino apenas após confirmar o algoritmo e a representação para a build SSH clientless instalada.
  7. Manter Share session desativado e guardar com Save.
  8. Adicionar o bookmark à Clientless Policy em Published bookmarks e guardar com Apply.
  9. No VPN Portal, clicar em Connect em VPN > Clientless access connections, introduzir a palavra-passe do destino e verificar se aparece o Terminal Prompt esperado. Em seguida, terminar corretamente a sessão SSH.

Sem Automatic login, o utilizador introduz a palavra-passe do destino ao estabelecer a ligação; o nome de utilizador continua a fazer parte do bookmark. Por conseguinte, nomes de utilizador SSH pessoais diferentes exigem bookmarks separados ou outro caminho de acesso. Com Automatic login, o SFOS pode utilizar uma palavra-passe ou Private Key. Private Keys privilegiadas ou amplamente utilizadas não devem ser guardadas num bookmark publicado de forma partilhada.

Servidores de ficheiros com FTP, FTPS, SFTP ou SMB

Os bookmarks de servidores de ficheiros também são criados em Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add. Em Type estão disponíveis FTP, FTPS, SFTP e SMB. URL contém um endereço IP fixo ou um hostname estável; Clientless SSL VPN não suporta endereços de destino dinâmicos. Em Init remote folder, pode definir-se opcionalmente a pasta inicial apresentada ao utilizador após a ligação.

Os métodos diferem sobretudo no transporte e na autenticação no destino:

  • FTP, FTPS e SMB podem ser utilizados com ou sem Automatic login. Sem credenciais guardadas, o utilizador autentica-se no sistema de destino depois de abrir o bookmark. O FTP transmite sem encriptação e não deve ser utilizado em novos workflows externos.
  • Para SMB, também é possível introduzir opcionalmente o domínio de rede Windows a que pertencem a conta e o sistema de destino, por exemplo CORP, corp.example ou corp.example.com. Estes exemplos devem ser substituídos pelo domínio real do próprio ambiente.
  • FTPS protege a ligação FTP com TLS. Em Public host key, guarda-se também o certificado esperado do servidor em formato .pem. O certificado e o nome são verificados diretamente no sistema de destino gerido, e não obtidos de uma ligação não verificada.
  • SFTP utiliza SSH. O bookmark contém o utilizador de destino e, em Authentication method, Password ou Private key com a credencial de destino correspondente. Public host key serve para verificar a identidade do servidor. A chave privada do utilizador e a Host Key pública do servidor têm funções diferentes e não devem ser confundidas.

⚠️ O formato de entrada de Public host key para SFTP continua por esclarecer: as instruções dos servidores de ficheiros para SFOS 22 e 23 indicam um certificado de servidor em formato .pem, enquanto as instruções separadas de SSH exigem uma chave pública do servidor. Isto não confirma um requisito X.509 nem a aceitação de valores OpenSSH ou ED25519 no campo SFTP. Os comandos SSH acima não são, portanto, um guia de formato para SFTP. Antes da utilização em produção, esclarecer com Sophos Support a representação SFTP aceite pela build instalada e verificar a identidade do servidor diretamente no sistema de destino fidedigno; não converter formatos por suposição nem contornar a verificação de identidade.

Também nos bookmarks de servidores de ficheiros se define outra porta de serviço apenas se o serviço correspondente no servidor de destino utilizar efetivamente uma porta diferente da padrão.

Com Automatic login, o nome de utilizador e a palavra-passe do sistema de destino são guardados no bookmark para FTP, FTPS e SMB. Todos os utilizadores autorizados passam a utilizar essa identidade de destino guardada; aplicam-se os mesmos requisitos de privilégios mínimos e rotação do exemplo NLA. Não se trata de Credential Passthrough a partir do VPN Portal.

Neste procedimento SFTP, o SFOS autentica automaticamente com as credenciais do destino guardadas no bookmark. Não é pedido ao utilizador que introduza a palavra-passe do destino; o início de sessão interativo opcional de SSH, FTP, FTPS e SMB não se aplica ao SFTP.

No browser, as sessões FTP, FTPS e SFTP permitem transferir ficheiros, criar pastas e navegar por diretórios. O SFOS inicia os downloads sem nova confirmação e guarda-os na pasta de downloads padrão do endpoint. Por isso, devem ser validados as permissões, a pasta inicial e um teste com ficheiros não sensíveis antes da utilização produtiva. Um bookmark de servidor de ficheiros não cria uma unidade de rede Windows normal nem substitui a verificação das permissões pessoais no servidor de destino.

Os botões no canto superior direito das sessões FTP, FTPS e SFTP permitem parar a sessão, carregar um ficheiro, criar uma pasta e aceder à pasta superior.

Telnet continua disponível como tipo de terminal, mas não encripta o transporte. Não deve ser utilizado para novos acessos. Os bookmarks HTTP e HTTPS não fazem parte dos tipos Clientless atualmente documentados para o SFOS 22. Para aplicações Web internas, a Web Application Firewall ou ZTNA são a arquitetura mais adequada, consoante os requisitos de proteção.

Se um dispositivo antigo exigir Telnet temporariamente, selecione Type: Telnet em Bookmarks > Add, introduza o host fixo em URL e defina a porta apenas se diferir da padrão. Share session é opcional. Restrinja este acesso não encriptado a um grupo reduzido e a um destino de gestão isolado e substitua-o depois por SSH.

Quando os mesmos destinos têm de ser atribuídos a várias policies, cria-se um grupo em Bookmark groups > Add: introduzir o nome do grupo em Name, selecionar os bookmarks existentes com Add new item e guardar com Save. A policy publica depois o grupo em vez de cada destino individualmente. Um Bookmark Group não amplia permissões no sistema de destino; apenas simplifica a atribuição no SFOS.

Ao criar ou modificar um grupo através da XML API, a entidade chama-se SSLBookmarkGroup. A documentação da API para SFOS 23.0 permite caracteres UTF-8 no respetivo Name, proíbe vírgulas e mantém o máximo de 50 caracteres. A documentação do SFOS 22.0 já indica este máximo, mas não as duas regras adicionais sobre caracteres; isto não permite concluir como são aplicadas nas builds anteriores. Um nome de exemplo válido é Clientless-München, como em <Name>Clientless-München</Name>; o nome deve ser adaptado ao próprio ambiente. Após a chamada à API, verificam-se o código de estado e a mensagem da resposta XML e volta-se a consultar o grupo guardado: o nome e os bookmarks incluídos devem corresponder à atribuição pretendida. Esta nota diz respeito ao nome do grupo na API, não estabelece uma regra geral para os nomes de bookmarks individuais; na interface descrita acima, seguem-se os requisitos dos campos da build instalada.

Bookmarks individuais através da XML API: O exemplo Add/Edit para SSLBookmark no SFOS 22.0 e 23.0 é uma referência com ramos dependentes do tipo, não um payload único executável para todos os protocolos. Os valores HTTP e HTTPS nele incluídos não comprovam o suporte atual na interface nem o suporte na build instalada. No exemplo, NLA exige que AutoLogin esteja ativado; para SSH/SFTP, o comentário descreve a palavra-passe ou a Private Key como alternativas quando AutoLogin está ativado. Isto não elimina as limitações relativas à Host Key SSH e ao formato SFTP descritas acima, nem implica um início de sessão SFTP interativo.

No entanto, a tabela de parâmetros identifica Private Key, Public Host Key e UserName como campos obrigatórios sem distinguir o tipo. Restringe URL a caracteres próprios de nomes de host, enquanto a segunda linha Domains, relativa a uma lista de domínios/URLs referenciados, exige que os valores comecem por HTTP:// ou HTTPS://. No exemplo, esta lista encontra-se sob o token literal RefferredDomains; não corresponde ao domínio Windows Domain para RDP/SMB, embora a tabela também contenha uma linha RDP denominada Domains. Não renomear tokens por suposição nem combinar as regras contraditórias da tabela num payload universal. Antes de uma alteração automatizada, esclarecer os campos, as condições e as representações aceites para o tipo e a build instalada através da documentação oficial aplicável ou com Sophos Support; até lá, não executar a alteração não confirmada. Antes da alteração, guardar o bookmark efetivamente existente e as suas associações como estado de referência inicial; depois, verificar o estado e a mensagem XML e voltar a consultar o bookmark guardado, a pertença a grupos e a publicação. Se houver divergências, reverter apenas a própria alteração para esse estado inicial exato e repetir os testes de acesso; não incluir palavras-passe nem Private Keys nas saídas de auditoria ou em ficheiros de payload desprotegidos.

Diagnosticar erros típicos

  • VPN Portal não está acessível: Verificar o registo DNS público, a porta, o NAT a montante, Administration > Device access e um possível efeito de Port Sharing.
  • O início de sessão no portal falha: Em Authentication > Services, verificar a autenticação do VPN Portal, bem como o estado do utilizador, MFA e access_server.log.
  • Clientless access connections não aparece: O utilizador não está atribuído a uma Clientless Policy ou a policy não publica nenhum bookmark.
  • O bookmark aparece para o utilizador errado: Verificar Policy members, associações a grupos e Published bookmarks. Quando existem vários grupos correspondentes, Clientless SSL VPN pode combinar as permissões das respetivas policies. Os bookmarks que um utilizador real vê desta forma têm de fazer parte do teste positivo e negativo.
  • O bookmark abre, mas o destino continua inacessível: Verificar a resolução DNS do ponto de vista da firewall, o endereço estático do destino, routing, a porta de destino, o estado do serviço e a firewall do host.
  • O início de sessão no VPN Portal funciona, mas o do Windows não: A autenticação no portal e no destino são independentes. Verificar o domínio, a conta de destino, a palavra-passe e TLS ou NLA.
  • NLA ativa Automatic login: Este é o comportamento documentado. Não desativar NLA sem planeamento; reavaliar o modelo de conta e de acesso.
  • SSH apresenta uma Host Key diferente: Parar a ligação e verificar a alteração diretamente no sistema de destino ou junto do operador responsável. Uma chave inesperada pode indicar uma reinstalação, um destino incorreto ou um ataque.

Em Diagnostics > Tools > Troubleshooting logs, diferentes ficheiros ajudam em fases distintas:

  • vpnportal.log para o VPN Portal;
  • access_server.log para autenticação e autorização;
  • clientless_access.log para ligações Clientless e o estabelecimento da ligação ao destino;
  • oauth_sso_vpn.log no SFOS 22 para inícios de sessão no VPN Portal com SSO; no SFOS 23, oauth_sso_svc.log para OIDC/Entra SSO no VPN Portal. Verificar também o módulo Authentication no Log viewer para estes inícios de sessão no VPN Portal.

Devem ser documentados em conjunto a hora do teste, o utilizador, o bookmark e o destino. Assim, é possível distinguir nos logs os problemas do portal, de identidade e do destino. A atribuição geral dos logs e o acesso através da Advanced Shell encontram-se em Logs de serviços da Sophos Firewall.

Operação e limitações RDP conhecidas

Antes de uma alteração em produção, registe a atribuição da policy, a matriz Device Access, as exceções ACL, a porta do portal e o certificado. Se o teste positivo falhar ou o utilizador negativo vir um bookmark, remova a nova atribuição ou publicação, restaure estes valores para o estado anterior, inicie sessão novamente e repita o teste negativo. Restaure contas de destino ou Host Keys apenas se tiverem sido realmente alteradas.

As Clientless Policies devem ser verificadas regularmente, tal como outras autorizações de Remote Access. Devem ser removidos utilizadores, bookmarks e contas de destino que já não sejam necessários. As palavras-passe ou Private Keys guardadas devem ter um owner, uma data de validade e um processo de rotação. Automatic login e Share session devem fazer parte de todas as revisões de permissões.

Retirar a publicação não é eliminar: Antes da remoção, esclarecer se se trata de um bookmark individual ou de um Bookmark Group e registar o nome exato, a pertença atual a grupos e a publicação em todas as policies afetadas. Primeiro, retirar apenas a publicação ou a atribuição que já não é pretendida; isto não elimina o objeto. Eliminar o objeto exato apenas quando já não estiver efetivamente em utilização e as suas dependências estiverem esclarecidas. Se existirem relações, parar e não eliminar grupos ou policies de produção em cascata apenas para forçar a remoção.

As referências Delete para SFOS 22.0 e 23.0 exigem, em ambos os casos, Name com um máximo de 50 caracteres e indicam os valores de estado XML 200, 500 e 504. Para 504, remetem para BookMarkDeleteRelationExists no caso dos bookmarks e para BookMarkGroupDeleteRelationExists no caso dos grupos: são identificadores de mensagens na documentação cujo texto não foi resolvido, não textos de mensagens confirmados em tempo de execução nem um estado HTTP. As referências não fornecem um payload de exemplo para Delete nem qualquer garantia sobre eliminações em cascata; não deduzir daí uma sintaxe de eliminação. Após a alteração, voltar efetivamente a consultar os bookmarks e grupos restantes e as publicações pretendidas, e repetir os testes positivos e negativos. Se ocorrer acesso inesperado, reverter as próprias alterações de atribuição para o estado inicial registado; por isso, evitar eliminações desnecessárias de objetos quando se pretende apenas retirar uma publicação.

Para consultar em tempo real os utilizadores remotos com sessão iniciada, abre-se Current activities > Remote users na consola de administração. As ligações podem ser filtradas por data de ligação, nome de utilizador, endereço IP de origem e endereço IP atribuído (leased IP). O administrador pode clicar em Disconnect para desligar o utilizador remoto selecionado. Primeiro deve verificar o utilizador e a ligação, pois esta ação interrompe o acesso. Não substitui a remoção do utilizador da Clientless Policy nem o fim correto da sessão no destino e não garante que todas as sessões subsequentes nos sistemas de destino sejam terminadas.

A documentação da coluna Mode distingue os seguintes casos:

  • SSL VPN (remote access): o utilizador está ligado através de SSL VPN de acesso remoto.
  • User portal (clientless access): segundo esta correspondência, o utilizador tem sessão iniciada no User Portal e é membro de uma Clientless SSL VPN Policy.
  • User portal: segundo esta correspondência, o utilizador tem sessão iniciada no User Portal, mas não é membro de uma Clientless SSL VPN Policy.

Estas etiquetas provêm das instruções Remote users para SFOS 22 e 23. As instruções Clientless indicam, por outro lado, o VPN portal como via de acesso. A terminologia é, portanto, inconsistente; a lista não confirma as etiquetas Mode atuais da build instalada nem uma alteração de SFOS 22 para 23. Na configuração mantém-se o procedimento do VPN Portal descrito acima. Verificar separadamente o início de sessão no portal, a pertença à policy e os bookmarks realmente visíveis, em vez de deduzir a autorização apenas a partir de uma etiqueta Mode.

Antes de alterar o firmware, use o runbook da Avanet para decisões de firmware para identificar as alterações que afetam a build instalada e a versão de destino. Inclua Clientless Access, VPN portal, RDP e o método de autenticação utilizado na verificação. Após a atualização, repita todos os testes positivos e negativos.

No RDP existem duas limitações atuais que não devem ser tratadas como erros de configuração:

  • A área de transferência não é suportada em bookmarks Clientless RDP desde o SFOS 19. Por conseguinte, copy-and-paste entre o dispositivo local e a sessão RDP não é um método de trabalho fiável.
  • O ponteiro do rato pode aparecer na sessão RDP HTML5 como uma cruz ou X em vez da seta normal. Atualmente, a Sophos não indica uma solução alternativa.

Se forem indispensáveis a área de transferência, funções RDP nativas, um acesso de rede mais amplo ou contas pessoais num servidor que exige NLA sem credenciais guardadas, Clientless SSL VPN não é o atalho adequado. Nesse caso, o acesso deve ser transferido deliberadamente para Sophos Connect, RD Gateway, PAM, um Jump Host ou ZTNA.