DESAFIO INSTALANDO VPN SERVER NO WINDOWS SERVER ATRÁS DE NAT

Boa tarde meus caros consagrados! Hoje surgiu um pedido de um cliente um pouco ambicioso, mas aceitamos o desafio e implantamos uma VPN no Window Server 2022 com uso de Certificado, Chave Privada, Criptografia e controle de Integridade!

Vamos ao desafio!

VPN NATIVA DO WINDOWS SERVER COM RRAS

O maior de todos os desafios em usar o Windows Server como Servidor de VPN é que este está atrás de uma infraestrutura com NAT. E nativamente o Windows não funciona atrás de NAT. Alguns ajustes precisam ser feitos, como uso de NAT-Traversal. Isso porque o VPN trabalha com NAT e ele precisa negociar NAT no NAT, logo o NAT-T contorna esse problema negociando a VPN com a origem e destino atrás de NAT encapsulando de novo o pacote ESP dentro da porta UDP 4500. É um ajustão.

Segundo, o cliente Windows 11 e 10 não consegue se conectar em um Windows Server atŕas de um NAT mesmo com a porta 4500 negociando e encapsulando o ESP. Um ajuste no Registro do Windows precisa ser feito.

Resumo da ópera, tentei usar o L2TP com IPSec pela segurança exigida e para não usar protocolos antigos e inseguros. Não funcionou.

O Wireshark até detectou os pacotes de negociação com a porta UDP 500 e UDP 4500, mas não fecha o túnel.

Muito ajuste pra usar a forma nativa.

ESTUDANDO ALTERNATIVAS

WireGuard

Eu gostei muito dele por ser uma solução mais focada em Linux. A documentação é incrível com vídeos explicativos e com passo a passo. Apesar de difundido e mais fácil de configurar, achei pouco suporte para Windows. Ah! Ele também usa NAT e Firewall Traversal Persistence. Não escolhi esse.

SoftEther VPN

Esse seria uma solução segura quanto à criptografia, pois usa o HTTPS que faz uso do TLS/SSL. E ele se passa tudo pela porta 443. Seria fácil redirecionar a 443 no modem da Vivo. Mas eu fui atrás de documentação (Eu amo documentação de solução!) e esse este tem boa documentação, bastante texto e poucas imagens, mas elucida, porém a comunidade da Internet se mostra mais ativa sobre o OpenVPN.

O SoftEther VPN Manual fala uma parte importante quando trabalhando com infraestrutura atrás de NAT, basicamente ele fala que apenas fazendo o Port Forwarding da 443 resolve. Achei legal:

11.2.6 Installing VPN Server Behind a NAT Enabled Router

If you are installing VPN Server behind a consumer or small business targeted generic broadband router or a router with a built-in firewall that contains NAT functionality, you will have to configure it properly for VPN Server to work. You can enable static NAT or port mapping on the router so that traffic from the Internet will be forwarded to a port on the VPN Server, allowing it to be accessed from the Internet. Please refer to your broadband router’s instruction manual for more information on how to achieve this.

OpenVPN

Eu achei esse aqui demais! É meio dia para configurar esse cara, mas tudo que é bom exige determinação. A instalação dele é simples de tudo, o que pega mesmo é o arquivo de configuração e a Shell de criação do Ambiente PKI (o CA e os Certificados com Chave Privada).

Firewall de Borda / Roteador de Borda / Proxy Gateway

Um firewall seria interessante para prover tudo que eles não têm de gestão de rede local e segurança geral, mas inclui custos.

Escolhido OpenVPN vamos fazer!

Baixado o OpenVPN

OpenVPN-2.6.14-I001-amd64.msi

Instalado

OpenVPN Service

Serviço principal do OpenVPN.

OpenVPN GUI

OpenVPN TAP Virtual Ethernet Adapter

A NIC virtual necessária.

OpenSSL Utilities

Linha de comando OpenSSL.

Easy-RSA

Gerenciar os certificados.

Gerado arquivo de configuração

Essa parte é um critério que só!

Preparado o Ambiente PKI

POLÍTICA DE BYOD

Estamos falando de um notebook de um usuário que usa ele em casa sem nossa supervisão.

E SE O NOTEBOOK DO USUÁRIO FOR COMPROMETIDO? Se o invasor tiver acesso onde a Chave Privada SEM SENHA (usuario.crt e usuario.key) está, ele poderá copiar ela e usar para se autenticar como o cliente sem precisar saber de nenhuma senha. Usando um cliente OpenVPN configurado com esses arquivos, o invasor poderá tentar estabelecer uma conexão VPN com o servidor se passando pelo usuário legítimo. #POLÍTICADEBYOD

CA

Common Name: SERVIDORWIN01

Notice

CA creation complete. Your new CA certificate is at:
* C:/Program Files/OpenVPN/easy-rsa/pki/ca.crt


Build-ca completed successfully.

Chave TLS-AUTH

Aqui deu ruim

O tls-crypt é uma alternativa mais recente e geralmente recomendada porque oferece maior proteção contra metadados. Mas esse processo de configurar eles é muito complexo no Windows. Mesmo assim tentei e erros…

O script Bash Shell Linux no Prompt de Comando do Windows. As configurações simples de geração de CA e Certificados funcionam bem nesse script, porḿ quando solicitado binários da pasta anterior, o Prompt de Comando gerado não os encontra. Ele vai insistir no erro “Cannot find an OpenVPN binary” quando tentar executar gen-tls-auth server pois ele deveria usar apenas o openssl, mas o script parece ter uma verificação interna que falha. Mesmo tentando manipular o PATH e definir OPENSSL dentro do shell falham, e considerando que o script é um script shell Unix, talvez a melhor abordagem seja tentar executá-lo usando um ambiente mais nativo para ele. No meu caso tentei Shell do Git e mesmo assim outros erros de temp file.

Certificado e Chave para o Servidor

Notice
Private-Key and Public-Certificate-Request files created.

Your files are:
* req: C:/Program Files/OpenVPN/easy-rsa/pki/reqs/server.req
* key: C:/Program Files/OpenVPN/easy-rsa/pki/private/server.key

You are about to sign the following certificate:
  Requested CN:     'server'
  Requested type:   'server'
  Valid for:        '825' days

Notice
Inline file created:
* C:/Program Files/OpenVPN/easy-rsa/pki/inline/private/server.inline

Notice
Certificate created at:
* C:/Program Files/OpenVPN/easy-rsa/pki/issued/server.crt

E os parâmetros Diffie-Hellman (o tal do dh)

UM POUCO DE WIKIPDIA

A troca de chaves de Diffie-Hellman é um método de criptografia para trocas de chaves de maneira segura em canal público. Desenvolvido por Whitfield Diffie e Martin Hellman, foi um dos primeiros exemplos práticos de métodos de troca de chaves implementado dentro do campo da criptografia, tendo sido publicado em 1976. Fonte: https://pt.wikipedia.org/wiki/Troca_de_chaves_de_Diffie–Hellman acessado em 05-04-2025 20:07

Generating DH parameters, 2048 bit long safe prime
.......................................................
DH parameters appear to be ok.

Notice
DH parameters of size 2048 created at:
* C:/Program Files/OpenVPN/easy-rsa/pki/dh.pem

Certificado e a Chave do Usuário

Achei a validade dos certificados padrão de 865 dias muito alta.

Achei 825 dias muito. Alterado e recomecei…

Limpa o ambiente PKI !

Gerar a CA de novo…

Agora sim…

Criar dos usuários

Notice
Private-Key and Public-Certificate-Request files created.

Your files are:
* req: C:/Program Files/OpenVPN/easy-rsa/pki/reqs/usuario.req
* key: C:/Program Files/OpenVPN/easy-rsa/pki/private/usuario.key

You are about to sign the following certificate:
  Requested CN:     'usuario'
  Requested type:   'client'
  Valid for:        '183' days

Notice
Inline file created:
* C:/Program Files/OpenVPN/easy-rsa/pki/inline/private/usuario.inline

Notice
Certificate created at:
* C:/Program Files/OpenVPN/easy-rsa/pki/issued/usuario.crt

Copiado tudo pro Servidor

MANTIDO O server.key EM SEGREDO

Configurado OpenVPN de novo

server.ovpn

Firewall liberado

Iniciado serviço de OpenVPN

Port forward no modem

AGORA O LADO DO USUÁRIO

Gerado o arquivo do client

client
dev tun
proto udp
remote IP_DE_INTERNET 1194 # 5090 no meu caso pois faço Port NAT
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert usuario.crt #USUARIO
key usuario.key #USUARIO
remote-cert-tls server
data-ciphers AES-256-GCM:AES-128-GCM:?CHACHA20-POLY1305:AES-256-CBC
verb 3

<ca>
# CONTEÚDO DO ca
-----BEGIN CERTIFICATE-----...........................
-----END CERTIFICATE-----)
</ca>

<cert>
# CONTEÚDO DO cert
-----BEGIN CERTIFICATE-----...........................
-----END CERTIFICATE-----
</cert>

<key>
# CONTEÚDO DA key
-----BEGIN ENCRYPTED PRIVATE KEY-----
....................................
-----END ENCRYPTED PRIVATE KEY-----
</key>

OpenVPN Client

Instalado o OpenVPN Client.

Copiado os arquivos do Usuário.

Posicionado os arquivos no OpenVPN Connect:

Configurado o OpenVPN Connect

Teste revelou senha errada. Revogar.

WARNING
This process is destructive!

These files will be MOVED to the 'revoked' sub-directory:
* C:/Program Files/OpenVPN/easy-rsa/pki/issued/usuario.crt

These files will be DELETED:
All PKCS files for commonName: usuario

The inline credentials files:
* C:/Program Files/OpenVPN/easy-rsa/pki/inline/usuario.inline
* C:/Program Files/OpenVPN/easy-rsa/pki/inline/private/usuario.inline

A Blacklist de revogados (CRL)

Using configuration from C:/Program Files/OpenVPN/easy-rsa/openssl-easyrsa.cnf

Notice
An updated CRL DER copy has been created:
* C:/Program Files/OpenVPN/easy-rsa/pki/crl.der

An updated CRL has been created:
* C:/Program Files/OpenVPN/easy-rsa/pki/crl.pem

IMPORTANT: When the CRL expires, an OpenVPN Server which uses a
CRL will reject ALL new connections, until the CRL is replaced.

Bora criar de novo o usuário com senha certa

Notice
Private-Key and Public-Certificate-Request files created.
Your files are:
* req: C:/Program Files/OpenVPN/easy-rsa/pki/reqs/usuario.req
* key: C:/Program Files/OpenVPN/easy-rsa/pki/private/usuario.key

You are about to sign the following certificate:

  Requested CN:     'usuario'
  Requested type:   'client'
  Valid for:        '183' days

Notice
Inline file created:
* C:/Program Files/OpenVPN/easy-rsa/pki/inline/private/usuario.inline

Notice
Certificate created at:
* C:/Program Files/OpenVPN/easy-rsa/pki/issued/usuario.crt

FASE FINAL

ROTEAMENTO VPN <> LAN

Questionamentos

O Servidor VPN é um Windows Server e está atrás de uma rede NAT e não é o servidor DHCP da rede?

Se a resposta for sim, um grande problema pode existir. O RRAS para VPN nativo do Windows server tem muita dificuldadee limitação para uso de protocolos e cifras de autenticação, criptografia e integride dos dados. Resumindo, ou adere uma solução de baixa segurança ou recorre para aplicativos de terceiros que tenham boa documentação e compatibilidade. É o meu caso aqui.

O Servidor VPN é o roteador da rede?

Se a resposta for não, saiba que os clientes VPN não vão conhecer as rotas para a rede interna, mas uma rota default deve ser configurada para enviar para o servidor. E sendo assim, se é um Windows server, precisaremos ativar o RRAS para informar a esse servidor que existe uma nova LAN VPN acontecendo dentro dele e ele vai passar a encaminhar trafegao entre as redes. E mesmo assim, o modem ou roteador da rede Local remota, no meu caso Modem da Vivo, não vai conhecer a rede VPN isolada dentro do servidor Windows, a menos que configuramos uma Rota Estática dentro dele informando que o caminho para a nova rede VPN é no Windws Server.

Em fim, vários desafios quando o servidor VPN não é o roteador principal da rede local. Não significa que não funciona, mas vai exigir algumas customizações.

Se o servidor VPN for o firewall, o gateway ou o roteador principal, seria ser bem simples!

DESAFIO

O cliente no meu caso é também um cliente da Operadora Vivo! Já sabemos no que isso leva!

CASA DO USUÁRIO 192.168.15.1 <> 172.16.15.2 TUNEL VPN 172.16.15.1 <> 192.168.15.1 EMPRESA

O usuário da Vivo usa um modem da Vivo com rede 192.168.15.0/24.

Ele vai fechar uma VPN que recebe o endereço 172.16.15.1/24 para acessar os servidores da empresa.

Que por suas vezes estão na rede 192.168.15.0/24.

É isso!

SOLUÇÃO APLICADA NOS SERVIDORES

Servidor Windows configurado RRAS para trabalhar com roteamento estático.

No Servidor Windows criado rota estática para a NIC TAP com a rede 172.16.15.0/24

No Servidor Windows criado rota estática para a NIC LAN com a rede 192.168.15.0/24

No Servidor Windows 2 criado rota estática no Prompt de Comando para ele saber chegar na rede 172.16.15.0/24.

SOLUÇÃO APLICADA NO LADO DO CLIENTE

Alterado arquivo hosts para configurar DNS Fixo para o SERVIDOR1 e SERVIDOR2.

Calculado e criado a rota para uma subnet que contenha os dois números 212 e 213. 192.168.15.212/30.

Agora sim quando o usuário requisita o ServidorX ele manda para a placa de rede certa.

Arquivos Mapeados com Sucesso!

RESOLVIDO!