MFA para VPN no UserGate é uma funcionalidade valiosa: dispensa RADIUS, não exige licenças adicionais, e tudo está disponível out-of-the-box. Um problema: o cliente oficial existe apenas para Linux. No entanto, nem todas as empresas brasileiras migraram completamente para sistemas operacionais nacionais.
Claro, você pode esperar que o fornecedor lance um cliente para todas as plataformas. Ou você pode usar L2TP/IPsec, os clientes VPN nativos do sistema operacional, alguns scripts, explorar um pouco o registro do Windows e montar uma solução funcional agora mesmo. É isso que faremos hoje.
Arquitetura do Ambiente de Teste
Para começar, vamos montar um esquema típico que frequentemente encontramos em empresas: UserGate na versão estável mais recente (no momento da escrita, 7.4.2.390439R) atuando como dispositivo de borda. Atrás dele, há um servidor interno ao qual precisamos organizar o acesso remoto. O usuário se conecta externamente através de um canal que simula a internet.
O endereçamento IP é o seguinte:
192.168.1.10— interface externa do UserGate. Em um ambiente real, este seria um endereço IP público ou um endereço cinza atrás do NAT de um roteador de provedor.172.30.252.0/24— sub-rede virtual da qual os clientes VPN recebem endereços ao se conectar.172.168.100.0/24— sub-rede interna de destino com o servidor protegido. Rotearemos para ela o cliente autorizado.
Na demonstração, estou usando usuários locais, e não AD ou LDAP, mas isso não afeta a mecânica da VPN. Ao usar contas de domínio, duas etapas adicionais serão adicionadas: integração com LDAP e configuração da autorização de domínio no portal corporativo. No entanto, a configuração das políticas de domínio é um tópico separado. Nesta demonstração, vamos deixar os usuários locais e nos concentrar em como funciona a combinação de L2TP/IPsec e MFA.
Configuração da Parte Servidora do NGFW
A VPN de Acesso Remoto com segundo fator no UserGate funciona através da interação de várias entidades que precisam ser corretamente vinculadas.
Passo 1. Interfaces de Rede e Roteamento
Primeiro, determinamos através de qual interface as conexões remotas chegarão e para onde exatamente permitiremos que os usuários vão após a autenticação. Para isso, na interface externa (no nosso caso, 192.168.1.10), precisamos permitir dois serviços no nível da zona: VPN e Portal Web.
Sem VPN, o túnel simplesmente não se levantará, e sem o Portal Web, o usuário não poderá acessar o portal web e obter um código QR para vincular o segundo fator.
Em seguida, criamos um perfil de rede VPN. Nele, definimos um pool de endereços para os clientes, por exemplo, 172.30.250.2-172.30.250.254, e uma máscara 255.255.255.0.
Na aba ao lado, definimos a rota para a sub-rede interna de destino 172.168.100.0/24.
Depois disso, levantamos a interface de túnel (digamos, tunnel1), a habilitamos, a colocamos no modo estático e atribuímos um endereço da sub-rede VPN, por exemplo, 172.30.250.1/255.255.255.0. Este será o gateway do cliente dentro do túnel.
Passo 2. Parâmetros IKE e IPsec
Agora, definimos os parâmetros criptográficos. Essencialmente, determinamos como a rede privada virtual será tecnicamente implementada. Para isso, criamos um perfil de segurança do servidor.
Nas propriedades principais, especificamos:
- Protocolo: IPsec/L2TP.
- Modo IKE: Principal (Main mode).
- Tipo de identificação: Nenhum.
- Chave Compartilhada (Preshared Key / PSK): uma senha forte (por exemplo, TestRMVPN123!), que será necessária para inserir nos dispositivos dos usuários durante a configuração inicial.
Nesta etapa, não usamos certificados. Para um ambiente de teste, a autenticação do servidor por chave compartilhada é suficiente.
Em seguida, definimos separadamente os parâmetros para IKE Fase 1 e Fase 2.
A primeira fase é responsável por criar um canal seguro para troca de informações de serviço (autenticação, negociação de algoritmos). A segunda — por criar chaves para criptografar o próprio tráfego.
Na primeira fase, definimos o tempo de vida da chave para 24 horas, desativamos o Dead Peer Detection no âmbito da demonstração e adicionamos conjuntos de criptografia. Do mínimo razoável, vale a pena deixar SHA256/AES256 e SHA1/AES256. A combinação SHA1/3DES só faz sentido usar para compatibilidade com dispositivos cliente antigos. Se puder evitar o 3DES, é melhor fazê-lo.
O tempo de vida das chaves na Fase 2 geralmente é menor, para garantir uma rotação mais frequente. Portanto, para IPsec SA, definimos 12 horas e, da mesma forma, escolhemos algoritmos de autenticação e criptografia.
Passo 3. Perfil MFA
Agora, habilitamos o que motivou tudo isso. Na interface do UserGate, não há um botão separado no formato "habilitar 2FA para VPN". A configuração é feita através de um perfil MFA. Criamos um perfil e definimos nele a lógica do segundo fator:
- MFA através de: TOTP.
- Inicialização TOTP: escolhemos "Mostrar chave na página do captive-portal". Esta configuração fará com que o gateway gere um código QR quando o usuário fizer login pela primeira vez através do navegador.
- Mostrar QR-code: a marcação é obrigatória.
- Conteúdo: você pode deixar o texto padrão, explicando ao usuário o propósito do código único.
Agora, ao entrar no portal web pela primeira vez, o gateway mostrará ao usuário um código QR para o aplicativo autenticador. No UserGate, existem outras formas de entregar o segundo fator. Por exemplo, enviar o código por e-mail ou SMS. Mas TOTP é o mais confiável: uma vez escaneado, os códigos são gerados diretamente no smartphone, sem atrasos na entrega.
Passo 4. Juntando Tudo
Agora temos um túnel, criptografia e um perfil MFA. Resta reuni-los em um esquema de trabalho.
Primeiro, criamos um perfil de autenticação. Nele, escolhemos o perfil MFA criado e, na aba de métodos de autenticação, adicionamos "Usuário Local" ou um método de domínio, se você estiver configurando um ambiente de produção. Em seguida, criamos um usuário, por exemplo, user1, definimos um login, senha e o adicionamos ao grupo VPN users.
Vamos para a criação de usuários. Na seção "Usuários", criamos user1. Definimos um login, uma senha complexa e o colocamos no grupo VPN users.
Depois disso, criamos uma regra de servidor VPN. Nela, indicamos:
- perfil de segurança VPN;
- rede VPN com pool de endereços;
- perfil de autenticação com TOTP vinculado;
- interface tunnel1.
Nas abas "Origem" e "Destino", você pode permitir conexões de qualquer endereço e restringir o acesso ao grupo VPN users ou a um usuário específico.
Tudo pronto, a parte do servidor está pronta. Agora, o gateway sabe: onde aceitar conexões, como criptografar o tráfego e para quem emitir endereços.
Configuração do Cliente: Windows, Registro e um Pouco de Dor
Nesta etapa, nos aguardam gambiarras não óbvias. O cliente Windows integrado para L2TP/IPsec lida mal com cenários de conexão envolvendo NAT, e os dispositivos domésticos dos funcionários, como regra, estão localizados atrás do NAT. Por padrão, o Windows considera essa conexão insegura e descarta a tentativa de construir um túnel com um erro vago. Isso é corrigido editando o registro.
Edição do Registro para NAT Traversal
Abra o regedit.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
— nesta seção, crie um parâmetro DWORD (32 bits) com o nome AssumeUDPEncapsulationContextOnSendRule e o valor 2.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters
— nesta seção, altere o valor do parâmetro AllowL2TPWeakCrypto para 1.
Reinicie o computador.
O valor "2" significa que o servidor está atrás do NAT e é necessário usar o encapsulamento UDP para pacotes ESP.
Para referência: ao trabalhar com L2TP/IPsec através de NAT, as portas padrão IKE (500) e ESP (50) podem ser bloqueadas. O mecanismo NAT Traversal (NAT-T) encapsula pacotes ESP em UDP na porta 4500, o que permite contornar essas restrições. A edição do registro apenas habilita este mecanismo no lado do Windows.
Configuração da Conexão no Windows
Parâmetros → Rede e Internet → VPN → Adicionar conexão VPN.
No campo do provedor de serviços VPN, escolha Windows (integrado).
Defina um nome de conexão, por exemplo, UserGateVPN.
Especifique o endereço do servidor 192.168.1.10.
Escolha o tipo de VPN L2TP/IPsec com chave compartilhada.
Especifique o PSK do perfil do servidor, por exemplo, TestRMVPN123!.
Como tipo de dados para login, escolha Nome de usuário e senha.
Remova imediatamente a marca de seleção "Lembrar minhas informações de login". Neste caso, só prejudica. O fato é que, em nossa configuração, o código TOTP único é inserido diretamente no campo de senha através de dois pontos no formato "senha:código único".
Após criar a conexão, abra as propriedades do adaptador UserGateVPN. Na aba "Segurança", habilite "Senha não criptografada (PAP)". Sem isso, a autenticação não passará.
Na aba "Rede para IPv4", abra os parâmetros adicionais e desmarque "Usar o gateway principal na rede remota". Caso contrário, você enviará todo o tráfego doméstico do usuário para o túnel corporativo, embora você precise apenas da rota para 172.168.100.0/24.
E agora a mesma coisa através de scripts
Todo este processo pode ser automatizado. Para isso, serão necessários dois scripts.
O primeiro script é responsável por editar o registro e criar aquele parâmetro que faz com que o Windows use o encapsulamento UDP para pacotes ESP ao se conectar através de NAT.
Script-editor de registro:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]
"AllowL2TPWeakCrypto"=dword:00000001
O segundo script cria uma conexão VPN pronta. Ele forma um atalho na área de trabalho, no qual já estão escritas todas as configurações: endereço do servidor; tipo de VPN (L2TP/IPsec com chave compartilhada); chave compartilhada (PSK); marca de seleção desativada "Lembrar minhas informações"; protocolo PAP habilitado; "Gateway principal na rede remota" desativado.
Script completo de configuração da conexão (testado no Windows 11):
powershell$adapterName = "UserGateVPN" $serverAddress = "192.168.1.10" $vpnType = "L2tp" $sharedKey = "TestRMVPN123!" # Сборка параметров подключения $vpnParams = @{ Name = $adapterName ServerAddress = $serverAddress TunnelType = $vpnType L2tpPsk = $sharedKey AuthenticationMethod = "Pap" SplitTunneling = $true RememberCredential = $false Force = $true } # 1. Создание VPN соединения Add-VpnConnection @vpnParams # 2. Создание ярлыка на рабочем столе $shell = New-Object -ComObject WScript.Shell $desktop = [System.Environment]::GetFolderPath("Desktop") $shortcut = $shell.CreateShortcut("$desktop\$adapterName.lnk") $shortcut.TargetPath = "rasphone.exe" $shortcut.Arguments = "-d $adapterName" $shortcut.IconLocation = "shell32.dll,135" $shortcut.Save() Write-Host "VPN '$adapterName' успешно настроен с SplitTunneling и PAP." -ForegroundColor Cyan
Passo 0. Verificamos a versão do SO
Se o Windows 11 estiver instalado no computador, antes de executar os scripts, você precisa realizar uma ação adicional — abrir o PowerShell como administrador e executar:
powershellSet-ExecutionPolicy Bypass
Este comando permite a execução de scripts não assinados na sessão atual. Sem ele, o sistema operacional não permitirá a execução de scripts, referindo-se à política de segurança.
Passo 1. Editamos o registro
Executamos o primeiro script como administrador. Em todas as janelas pop-up, confirmamos a execução da operação. Após a conclusão do script, reinicie o computador para que as alterações no registro entrem em vigor.
Passo 2. Criamos a conexão VPN
Após a reinicialização, executamos o segundo script usando o PowerShell e confirmamos a execução.
Após a execução bem-sucedida, um atalho com o nome UsergateVPN aparecerá na área de trabalho. Todas as configurações de conexão já estão escritas dentro — nada adicional precisa ser configurado.
Onboarding do Usuário
Tecnicamente, tudo já está pronto, mas configurar a infraestrutura é apenas metade do trabalho. Resta o mais interessante: explicar ao usuário como usar tudo isso.
Inicialização do Segundo Fator
Antes da primeira conexão, o usuário deve abrir o Captive-portal, por exemplo:
https://192.168.1.10:4443/.
Em seguida, o usuário insere seu login e senha (aqueles que você criou no gateway ou no AD) e recebe um código QR e um segredo de texto TOTP.
Como aplicativo autenticador, Google Authenticator, Microsoft Authenticator, FreeOTP, extensões de navegador como 2FA Authenticator são adequados. Se você se concentrar nas realidades brasileiras, é melhor usar o "Yandex.Key". Não há diferença para o próprio gateway — o algoritmo TOTP é padronizado, mas levando em consideração a política de substituição de importações e as potenciais restrições de serviços estrangeiros, uma solução nacional parece preferível.
A vinculação do segundo fator é armazenada dentro do UserGate. Assim, se o usuário perder o telefone, o administrador poderá redefinir a vinculação através do console web, o que é bastante conveniente.
Conexão à VPN
Para conexão no Windows, é conveniente usar rasphone. Na janela de entrada de credenciais, o usuário indica o login e, no campo de senha, insere não a senha comum, mas uma string neste formato:
SenhaDaConta:CódigoDoAplicativo
Por exemplo:
MySuperSecretPass:123608
Deve-se notar que aqui os usuários frequentemente cometem erros: inserem apenas a senha, esquecendo os dois pontos e o código; omitem os dois pontos; não conseguem inserir o código antes de sua atualização (os códigos mudam a cada 30 segundos). Portanto, se você quiser implementar tal esquema de autorização na prática, você definitivamente precisará escrever uma instrução clara e compreensível.
Se as credenciais forem inseridas corretamente, a conexão é estabelecida. Você pode verificar a rota com o comando route print — na tabela de roteamento, deve aparecer o caminho para a sub-rede 172.168.100.0 através do túnel.
Experiência de Uso
Assim, você pode obter uma VPN de Acesso Remoto completa com segundo fator com base em ferramentas padrão do SO e funcionalidade integrada do UserGate, mas a experiência de uso deste esquema de autorização difere em diferentes plataformas.
No macOS, não é necessário editar o registro, e o L2TP é estabelecido mais facilmente, mas não se torna mais conveniente com isso. O código dinâmico ainda precisa ser adicionado à senha. Além disso, o macOS gosta de salvar as credenciais no Keychain, por causa do qual, após o sono ou reconexão, o sistema substitui a senha antiga, e o usuário é forçado a entrar nas configurações para corrigir a string composta. Formalmente, tudo funciona, mas usar tal autorização de forma contínua é muito inconveniente.
No Android e iOS, a combinação de L2TP/IPsec com tal mecânica de segundo fator não se parece com um cenário de usuário normal.
No Linux, a conexão através do Network Manager também é estabelecida se você instalar os pacotes necessários, mas a estabilidade depende muito da montagem específica e do conjunto de plugins. Nos ambientes de teste, funciona bem, mas na operação real podem ocorrer interrupções espontâneas.
Se falarmos sobre problemas técnicos comuns ao configurar tal conexão, em 90% dos casos, uma das três coisas é a culpada:
- Os perfis estão montados incorretamente. O perfil MFA não está vinculado ao perfil de autenticação, o usuário não entrou no grupo certo ou a regra VPN não aponta para os objetos certos.
- Na zona externa, eles esqueceram de habilitar VPN e Portal Web. Sem isso, o túnel simplesmente não se levantará e o usuário não receberá um código QR.
- Falhas na fase IKE ou na seção com NAT Traversal. Para o usuário, isso se parece com "simplesmente não se conecta", embora o problema real seja mais profundo.
Felizmente, nas versões atuais do UserGate, o diagnóstico de sessões VPN tornou-se visivelmente mais conveniente: os logs agora mostram em qual fase ocorreu a interrupção e por qual motivo. Lidar com erros tornou-se muito mais fácil.
Conclusões
Se avaliarmos este esquema pelo equilíbrio de segurança e conveniência, eu daria a ele 6 de 10. Por que tão pouco? Porque L2TP/IPsec neste papel é uma implementação abertamente comprometida com um UX bastante torto.
Por que não mais baixo? Porque o MFA integrado no UserGate é realmente útil. Ele não requer um servidor RADIUS separado, não pede licenças adicionais e, na versão básica, cobre a necessidade de uma conexão segura.
Para quem isso é adequado? Para aqueles que já têm UserGate, não têm orçamento ou espaço para um gateway VPN separado e a necessidade de um segundo fator surgiu agora.
O que realmente falta aqui é um cliente bem ajustado para todas as plataformas populares. Quando o fornecedor fechar essa necessidade, todo o esquema se tornará imediatamente visivelmente mais conveniente e útil.
E, por último. A parte mais frágil desta construção não é a criptografia e nem as rotas, mas o usuário. Se você estiver implementando tal acesso remoto, não economize nas instruções. Mostre em capturas de tela onde obter o código QR, onde escaneá-lo, por que a senha agora é inserida através de dois pontos e por que não pode ser salva como antes. Este é exatamente o caso em que uma boa instrução economiza nervos tanto para os usuários quanto para o suporte técnico.
Implantação bem-sucedida e que o uptime esteja com você!
PURP — Canal do Telegram, onde a segurança cibernética é revelada de ambos os lados da barricada t.me/purp_sec — insights e insights do mundo do hacking ético e proteção orientada aos negócios de especialistas da Bastion