Configurando VPN Point to Site para o Azure Manualmente

Recentemente tive problemas com o cliente de VPN que a rede virtual do Microsoft Azure oferece para instalação. A instalação ocorreu conforme planejado em 8 de 10 estações de trabalho. Nas duas restantes, por mais que a instalação fosse refeita diversas vezes, o cliente apresentava problemas geralmente relacionados ao certificado, que obviamente fiz questão de conferir dezenas de vezes se estava correto. Neste artigo vou demonstrar como fazer para configurar manualmente a VPN com o gateway do Azure nestes cenários onde o cliente não funciona como deveria.

Pre-requisitos

Estou assumindo que alguns pre-requisitos já foram executados antes de chegar neste ponto:

  • A rede virtual foi criada e configurada
  • O gateway dinâmico da VPN e a configuração do Point-to-site já foi realizada
  • O gateway está ativado
  • O cliente precisa estar instalado mesmo que não esteja funcionando – não necessariamente na mesma máquina

Gerando os certificados

Primeira tarefa que precisamos fazer é criar os certificados raiz e cliente, pois é através de certificados que o gateway do Azure efetua autenticação. Para isso, vamos utilizar a ferramenta makecert.exe que pode ser encontrada em diversos softwares da Microsoft. Um deles é o Visual Studio ou o SDK do Windows, que pode ser baixado aqui [5].

Para gerar o certificado raiz, executamos o seguinte comando:

makecert -sky exchange -r -n "CN=RootCertificateName" -pe -a sha1 -len 2048 -ss My "RootCertificateName.cer"

Substitua o RootCertificateName pelo nome que quiser identificar este certificado. Este comando vai gerar um arquivo .cer no diretório que você está trabalhando e este é o arquivo do certificado exportado que vamos precisar enviar para o Azure.

No portal do Azure, navegue para Rede Virtual -> Selecione a rede -> Aba certificados e faça upload do arquivo gerado (RootCertificateName.cer).

Vpn-Certs

Agora que temos o certificado raiz, precisamos criar o certificado cliente. Para isso, utilize o comando abaixo:

makecert.exe -n "CN=ClientCertificateName" -pe -sky exchange -m 96 -ss My -in "RootCertificateName" -is my -a sha1

Repare que estamos criando um certificado cliente a partir do emissor, logo, isso precisa ser feito na mesma máquina que foi criado o certificado raiz no passo anterior (RootCertificateName), caso contrário, o certificado raiz precisará ser exportado para o novo computador.

Extraindo informações do cliente de VPN

Agora que resolvemos o problema da autenticação, vamos para a configuração do cliente da VPN no Windows. Antes de continuar, precisamos obter o endereço do gateway de VPN e é aí que está o problema. O GUID é composto pelo Id da rede virtual e mais um sufixo que não conseguimos obter, exceto pelo client instalado em alguma máquina. O formato do endereço é:

azuregateway-[Guid].cloudapp.net

Para obter este GUID, utilize um computador que tenha o cliente instalado e navegue para:

C:\Users\<usuario>\AppData\Roaming\Microsoft\Network\Connections\Cm\<VNetID>

Onde <usuário> é o seu usuário do Windows e VNetID é o Virtual Network ID que pode ser obtido pelo portal. Provavelmente, você terá apenas uma pasta neste caminho, então não será problema. Procure pelo arquivo .pbk e execute-o.

Captura de tela 2015-07-31 16.34.41

Clique em propriedades e copie o endereço de conexão do gateway.

Captura de tela 2015-07-31 16.34.50

Configurando a VPN do Windows

Agora com o certificado e dados da conexão em mãos, podemos configurar a VPN do Windows. Configure uma nova conexão de rede do Windows

Captura de tela 2015-07-30 19.01.51

Captura de tela 2015-07-30 19.02.01

Aqui colocamos o endereço do gateway que anotamos do arquivo .pbk.

Captura de tela 2015-07-30 19.03.15

Com a nova conexão criada, vamos agora configurar os detalhes. Entre nas propriedades dessa conexão e efetue as configurações conforme imagens abaixo:

Captura de tela 2015-07-30 19.03.25

Captura de tela 2015-07-30 19.03.34

Captura de tela 2015-07-30 19.03.51

Se você instalou o cliente na mesma máquina, o certificado raiz do gateway estará disponível na lista para seleção, caso contrário, exporte este certificado de algum computador que tenha o cliente instalado e importe-o na máquina (no mesmo path) que está configurando a conexão manualmente.

Captura de tela 2015-08-02 20.37.40

Clique em Advanced e escolha o certificado raiz criado no passo anterior.

Captura de tela 2015-07-30 19.09.11

O último passo é desligar a opção de utilizar o gateway remoto na conexão por padrão. Por algum motivo, no Windows 10 eu não estou conseguindo abrir as propriedades do TCP/IPv4 por isso vou demonstrar como fazer isso via powershell através do cmdlet Set-VpnConnection [4]. Execute o comando abaixo para desligar essa opção:

Set-VpnConnection -Name "Azure VPN" -SplitTunneling $True

É opcional que você desative esta opção, mas se você não o fizer, a internet vai parar de funcionar depois que você conectar já que ao invés de utilizar o seu gateway padrão da rede local, o Windows vai utilizar o gateway do VPN e neste caso, o tráfego de internet não é roteado.

Pronto! Agora é só conectar! Mas veja, apesar da conexão bem sucedida, não consigo pingar nem me conectar em nenhuma das VMs da minha rede no Azure.

C:\Users\Bruno>ping 10.0.1.4
Pinging 10.0.1.4 with 32 bytes of data:
Request timed out.
Request timed out.

Isso acontece porque as rotas não são criadas automaticamente como acontece utilizando o cliente oficial. Sendo assim precisaremos criar essas rotas na mão. Em seu post [1], Doug Rathbone desenvolveu um script bastante interessante que vamos utilizar para a criação dessas rotas. Copie o script de powershell abaixo e salve-o em algum lugar no seu computador com a extensão .ps1. Faça as modificações conforme o seu cenário, basicamente você precisa inserir as subnets e o range PPTP configurados no Azure que podem ser obtidos na configuração da rede virtual pelo portal.


#############################################################
# Adds IP routes to Azure VPN through the Point-To-Site VPN
#############################################################

# Define your Azure Subnets
$ips = @("10.0.1.0", "10.0.2.0","10.0.3.0")

# Point-To-Site IP address range
# should be the first 4 octets of the ip address '172.16.0.14' == '172.16.0.

$azurePptpRange = "172.16.0."

# Find the current new DHCP assigned IP address from Azure
$azureIpAddress = ipconfig | findstr $azurePptpRange

# If Azure hasn't given us one yet, exit and let u know
if (!$azureIpAddress){
    "You do not currently have an IP address in your Azure subnet."
    exit 1
}

$azureIpAddress = $azureIpAddress.Split(": ")
$azureIpAddress = $azureIpAddress[$azureIpAddress.Length-1]
$azureIpAddress = $azureIpAddress.Trim()

# Delete any previous configured routes for these ip ranges
foreach($ip in $ips) {
    $routeExists = route print | findstr $ip
    if($routeExists) {
        "Deleting route to Azure: " + $ip
        route delete $ip
    }
}

# Add our new routes to Azure Virtual Network
foreach($subnet in $ips) {
    "Adding route to Azure: " + $subnet
    echo "route add $ip MASK 255.255.255.0 $azureIpAddress"
    route add $subnet MASK 255.255.255.0 $azureIpAddress
}

A primeira coisa que precisa fazer para executar este script é modificar a política de execução [2] padrão do powershell, caso contrário ele será bloqueado. No powershell, execute o seguinte comando:

PS C:\Users\Bruno\Desktop> Set-ExecutionPolicy Unrestricted
Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): y
PS C:\Users\Bruno\Desktop>

Agora podemos executar o script e testar a conexão:

PS C:\Users\Bruno\Desktop> .\routes.ps1
 Adding route to Azure: 10.0.0.0
 route add 10.0.2.0 MASK 255.255.255.0 172.16.0.4
  OK!
 Adding route to Azure: 10.0.1.0
 route add 10.0.2.0 MASK 255.255.255.0 172.16.0.4
  OK!
 Adding route to Azure: 10.0.2.0
 route add 10.0.2.0 MASK 255.255.255.0 172.16.0.4
  OK!
 PS C:\Users\Bruno\Desktop> ping 10.0.1.4
 Pinging 10.0.1.4 with 32 bytes of data:
  Reply from 10.0.1.4: bytes=32 time=135ms TTL=127
  Reply from 10.0.1.4: bytes=32 time=136ms TTL=127
  Reply from 10.0.1.4: bytes=32 time=136ms TTL=127
  Reply from 10.0.1.4: bytes=32 time=136ms TTL=127
 Ping statistics for 10.0.1.4:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
 Approximate round trip times in milli-seconds:
  Minimum = 135ms, Maximum = 136ms, Average = 135ms
 PS C:\Users\Bruno\Desktop>

Perfeito! Exceto que ainda temos um porém, será muito chato ser obrigado a criar essas rotas manualmente todas as vezes que reiniciarmos a conexão com a VPN. Há uma maneira de automatizar a execução desse script. Para isso, vamos criar uma tarefa agendada [3] no Windows. Execute no prompt ou powershell (lembre-se de ajustar o path e nome da VPN conforme suas configurações):

schtasks /create /F /TN "VPN Connection Update" /TR "Powershell.exe -NonInteractive -command C:\Users\Bruno\Desktop\routes.ps1" /SC ONEVENT /EC Application /MO "*[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data='Azure VPN']] " /RL HIGHEST

É isso, pessoal! Agora sempre que a conexão da VPN for fechada o script das rotas executará automaticamente.

Qualquer dúvida não deixem de perguntar!

Referências:

[1] Deconstructing the Azure Point-to-Site VPN for Command Line usage. http://www.diaryofaninja.com/blog/2013/11/27/deconstructing-the-azure-point-to-site-vpn-for-command-line-usage

[2] about_Execution_Policies. https://technet.microsoft.com/pt-BR/library/hh847748.aspx

[3] Schtasks.exe. https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx

[4] Set-VpnConnection. https://technet.microsoft.com/en-us/library/jj554823(v=wps.630).aspx

[5] Software Development Kit do Windows (SDK do Windows) para Windows 8.1. https://msdn.microsoft.com/pt-br/windows/desktop/bg162891.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *