Desejo configurar o Windows Server 2012 e seus clientes VPN do Windows 7 e Windows 8, com uma VPN SSTP que usa encapsulamento dividido e endereçamento fora da sub-rede, mas estou com um problema: o servidor RRAS não envia pacotes para a VPN clientes de qualquer máquina que não seja ela mesma.
Meu servidor VPN está em execução na "Nuvem privada virtual" da Amazon, portanto, possui apenas uma NIC com um endereço IP em uma rede RFC1918 compartilhada com todos os meus outros servidores Amazon VPC e um IP público que encaminha todo o tráfego para esse endereço privado via NAT (a Amazon chama isso de "IP elástico").
Instalei o RRAS e configurei uma VPN. A sub-rede privada na Amazon é 172.16.0.0/17 (é o que estou chamando de "Amazon LAN"), mas quero que todos os clientes VPN usem o intervalo 10.128.0.0/20 (o que estou chamando de " VPN LAN ").
No meu painel de controle da Amazon, fiz o seguinte:
- Desabilitou a verificação de origem / destino do servidor VPN
- Foi adicionada uma entrada nas tabelas de rotas do pool 10.128.0.0/20 que aponta para a interface de rede do servidor VPN.
Dentro do MMC de roteamento e acesso remoto, dentro do menu de propriedades do nome do servidor, eu fiz o seguinte:
- Guia Geral -> Roteador IPv4 (marcado), ativado para LAN e roteamento de discagem por demanda
- Guia Geral -> Servidor de acesso remoto IPv4 (marcado)
- Guia IPv4 -> Ativar encaminhamento IPv4 (marcado)
- Guia IPv4 -> Conjunto de endereços estáticos e especifique 10.128.0.1-10.128.15.154
No meu cliente e em todos os meus servidores, verifiquei se o ICMP é explicitamente permitido no firewall ou se o firewall está totalmente desativado (não é o plano permanente, é claro).
No cliente, para habilitar o tunelamento dividido, fui às propriedades da conexão VPN -> Rede -> IPv4 -> Propriedades -> Avançado -> guia Configurações de IP e desmarquei a opção "Usar gateway padrão na rede remota" e marcado "Desativar adição de rota baseada em classe".
Neste ponto, meus clientes podem se conectar usando o cliente VPN do Windows 7/8. Eles recebem um IP do pool 10.128.0.0/20, mas como não estão definindo nenhuma rota automaticamente, não podem falar com a rede remota. Eu posso definir rotas para a rede remota e para a rede VPN, desta forma (no cliente):
route add 172.16.0.0/17 <VPN IP ADDRESS>
route add 10.128.0.0/20 <VPN IP ADDRESS>
Agora, o cliente pode executar ping no endereço de LAN da VPN do servidor VPN (10.128.0.1) e também no endereço de LAN da Amazon (172.16.1.32). Porém, o problema ocorre ao tentar conversar com outras máquinas na Amazon LAN: os pings não recebem respostas.
Portanto, por exemplo, se o cliente tentar executar ping em um sistema que eu conheço e responder a pings como 172.16.0.113, ele não verá essas respostas (ele diz "Solicitação expirou"). O Wireshark no servidor VPN confirma que vê o ping do cliente e até vê uma resposta enviada a partir de 172.16.0.113, mas aparentemente essa resposta nunca volta ao cliente.
Além disso, se eu efetuar ping no endereço LAN da VPN do cliente a partir de 172.16.0.113, o Wireshark no servidor VPN verá o ping, mas não verá uma resposta.
Então, para recapitular:
- O servidor VPN pode executar ping em outras máquinas na LAN Amazon (172.16.0.0/17) e receber respostas, e outras máquinas nessa rede podem fazer o mesmo.
- Um cliente VPN pode executar ping no endereço de LAN da Amazon do servidor e receber respostas, depois que os clientes adicionam a rota correta, conforme descrito anteriormente.
- Um cliente VPN pode executar ping no endereço LAN da VPN do servidor 10.128.0.1 e o servidor VPN pode executar ping no endereço LAN da VPN do cliente no intervalo 10.128.0.0/20, depois que o cliente adicionar a rota correta da rota, conforme descrito anteriormente.
- Um cliente VPN pode enviar pings para uma máquina na Amazon LAN, mas quando essas máquinas enviam respostas, elas param no servidor VPN - elas não são encaminhadas para o cliente, resultando em mensagens "Pedido expirado" no cliente . Por outro lado, quando uma máquina na Amazon LAN tenta executar ping no endereço da LAN da VPN 10.128.0.0/20 do cliente, o servidor VPN vê o ping, mas o cliente nunca vê e, portanto, não gera uma resposta.
Por que o servidor VPN não está enviando pacotes da LAN Amazon para seus clientes na LAN VPN? Definitivamente, ele pode conversar com os clientes na LAN da VPN, e o roteamento está ativado, e ele deseja encaminhar os pacotes da VPN LAN -> Amazon LAN, mas não o contrário. O que estou perdendo aqui?
Rotas
Aqui estão as tabelas de roteamento de um cliente VPN. O cliente é uma VM do VirtualBox executando o Windows 8. O endereço IP do adaptador vbox é 10.0.2.15 em um / 24. Esse cliente está atrás do NAT (na verdade, está atrás do NAT duplo, porque o adaptador vbox está conectado à NAT na minha rede local, que está conectado à Internet). Esta tabela de rota é de depois de adicionar manualmente as rotas a 10.128.0.0/20 e 172.16.0.0/17.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 10
10.0.2.0 255.255.255.0 On-link 10.0.2.15 266
10.0.2.15 255.255.255.255 On-link 10.0.2.15 266
10.0.2.255 255.255.255.255 On-link 10.0.2.15 266
10.128.0.0 255.255.240.0 On-link 10.128.0.3 15
10.128.0.3 255.255.255.255 On-link 10.128.0.3 266
10.128.15.255 255.255.255.255 On-link 10.128.0.3 266
54.213.67.179 255.255.255.255 10.0.2.2 10.0.2.15 11
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
172.16.0.0 255.255.128.0 On-link 10.128.0.3 15
172.16.127.255 255.255.255.255 On-link 10.128.0.3 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.0.2.15 266
224.0.0.0 240.0.0.0 On-link 10.128.0.3 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.0.2.15 266
255.255.255.255 255.255.255.255 On-link 10.128.0.3 266
===========================================================================
Persistent Routes:
None
Aqui estão as tabelas de roteamento do servidor RRAS, que está executando o Windows Server 2012. Esse servidor também está atrás do NAT, conforme discutido acima. Ele possui apenas uma placa de rede. Seu endereço IP privado é 172.16.1.32, em um / 23 (que faz parte de uma rede / 17 maior; acredito que é justo ignorar as partes do / 17 fora do / 23, pois outras máquinas no / 23 também não pode alcançar ou ser alcançado por clientes VPN).
O adaptador virtual da VPN tem seu próprio endereço, 10.128.0.1, atribuído automaticamente na primeira vez em que um cliente se conecta. As rotas para 10.128.0.1 (para si mesmo) e 10.128.0.2 (para seu único cliente) que você vê também são adicionadas automaticamente nesse momento. Nenhuma rota é adicionada ao servidor VPN manualmente.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.0.1 172.16.1.32 10
10.128.0.1 255.255.255.255 On-link 10.128.0.1 286
10.128.0.2 255.255.255.255 10.128.0.2 10.128.0.1 31
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
169.254.169.250 255.255.255.255 172.16.0.1 172.16.1.32 10
169.254.169.251 255.255.255.255 172.16.0.1 172.16.1.32 10
169.254.169.254 255.255.255.255 172.16.0.1 172.16.1.32 10
172.16.0.0 255.255.254.0 On-link 172.16.1.32 11
172.16.1.32 255.255.255.255 On-link 172.16.1.32 266
172.16.1.255 255.255.255.255 On-link 172.16.1.32 266
172.16.2.0 255.255.254.0 172.168.0.1 172.16.1.32 11
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.16.1.32 266
224.0.0.0 240.0.0.0 On-link 10.128.0.1 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.16.1.32 266
255.255.255.255 255.255.255.255 On-link 10.128.0.1 286
===========================================================================
Persistent Routes:
None
Aqui estão as tabelas de roteamento para outra máquina na rede privada do servidor, também executando o Server 2012. Ela tem uma NIC, que possui um endereço IP privado 172.16.1.177 - o que significa que está no mesmo / 23 que o servidor VPN. (Observe que a rota para 10.128.0.0/20 está definida no gateway, que é controlado pela Amazon, portanto você não a verá aqui. Adicionei a rota correta à Amazon, evidenciada pelo fato de o Wireshark no O servidor VPN vê os pacotes.)
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.0.1 172.16.1.177 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
169.254.169.250 255.255.255.255 172.16.0.1 172.16.1.177 10
169.254.169.251 255.255.255.255 172.16.0.1 172.16.1.177 10
169.254.169.254 255.255.255.255 172.16.0.1 172.16.1.177 10
172.16.0.0 255.255.254.0 On-link 172.16.1.177 266
172.16.1.177 255.255.255.255 On-link 172.16.1.177 266
172.16.1.255 255.255.255.255 On-link 172.16.1.177 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.16.1.177 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.16.1.177 266
===========================================================================
Persistent Routes:
None
Aqui estão as rotas no console da Amazon. Eu acho que eles estão corretos - o tráfego está voltando para o servidor VPN, afinal, apenas para desaparecer dentro dele - mas no caso de alguém querer vê-los, aqui estão eles. (A Amazon faz as coisas um pouco esquisitas. eni-2f3e8244 / i-77e26440
Refere-se à NIC no servidor VPN e igw-d4bc27bc
ao NAT / gateway da Internet controlado pela Amazon que todas as minhas instâncias usam para conversar com a Internet.)
10.128.0.0/20 eni-2f3e8244 / i-77e26440
172.16.0.0/17 local
0.0.0.0/0 igw-d4bc27bc
route print
e a tracert
saída - e fiz uma correção importante em algumas informações adicionadas anteriormente. (Obrigado pela ajuda ya do!)