Como configurar rotas para o IPSec VPN onde o ponto de extremidade VPN deve poder contatar a rede remota

Question

Eu tenho uma situação idêntica à pergunta em VPN IPSec: o tráfego não está sendo roteado corretamente (no entanto, parece que não consigo entrar em contato com esse usuário diretamente, nem posso fazer um comentário sobre essa questão - e ninguém nunca respondeu).

Eu também tenho um servidor Windows 2008 R2, com uma VPN IPSec que termina diretamente no servidor.

O servidor tem uma única interface de rede, que tem um endereço IP público (vamos chamá-lo de 203.10.10.10, por exemplo).

Eu gostaria que os computadores em uma rede privada e remota (10.16.0.0/255.254.0.0) conseguissem se conectar a esse servidor Windows em um endereço IP privado no final de um túnel IPSec que termina em esse servidor (não em um roteador na frente do servidor).

Igualmente importante (e esse pode ser o ponto de discórdia) eu preciso que o servidor seja capaz de iniciar uma conexão TCP com dispositivos na rede remota (10.16.0.0) (por exemplo, para baixar uma imagem via HTTP).

Veja como fica:

OIPprivadoqueeuescolhiparaoservidoré192.168.70.1/255.255.255.0eosfiltrosIPSecqueestabelecemotúnelparaaredeprivadaremotasãoparaorigem/destinos192.168.70.0/24e10.16.0.0/15.

SeeupingarumendereçonarederemotadoservidorWindows,comoargumentodeorigemdefinido,possoestabelecerotúneleospingsfuncionarão(porexemplo,ping-S192.168.70.110.16.0.1).

Noentanto,qualquertráfego"normal" enviado para um endereço 10.16.xx (incluindo pings sem o endereço de origem forçado para 192.168.70.1) é enviado alegremente para a Internet através da rota padrão e não inicia ou entra no túnel .

PERGUNTA

Uma configuração como essa é possível? Ou não é possível que o próprio endpoint VPN envie dados pelo túnel, originados de um de seus endereços privados? (É sempre necessário que o ponto de extremidade da VPN esteja em um roteador separado para o (s) dispositivo (s) que envia dados pelo túnel?)

Como posso configurar o Windows Server para garantir que todas as comunicações com a rede 10.16.0.0 sejam originadas de seu endereço IP privado.

O endereço privado não tem para ser 192.168.70.1 - outra sub-rede poderia ser escolhida se necessário (digo isto porque eu li isso, todas as outras coisas sendo iguais, Windows vista e up usará o IP de origem que mais se aproxima do destino - então talvez usar um 10.XXX ip para o endereço privado do servidor ajudaria?)

Eu não posso testar isso facilmente no entanto, já que a outra extremidade deste túnel VPN não está sob meu controle - e eu preciso ter os engenheiros de rede do outro lado fazendo mudanças de configuração se eu escolher mudar o 192.168 .70.1 endereço.

INFO EXTRA: O QUE TENHO ATÉ ATÉ

Eu tentei dois métodos para configurar esse endereço IP privado (no servidor Windows) em uma tentativa de obter pacotes para rotear corretamente e satisfazer as regras IPSec que estabelecem o túnel.

Endereço privado na interface principal

Com o endereço 192.168.70.1 adicionado à interface de rede principal (além do IP público), não parece possível definir nenhuma rota para 10.16.0.0 que faça com que o windows use 192.168.70.1 como um endereço de origem . Qualquer tráfego destinado ao gateway padrão terminará com o IP público como fonte.

Se houver alguma mágica disponível no Windows, não sei sobre o que eu gostaria de saber sobre isso! No entanto, o comando:

route add 10.16.0.0 mask 255.254.0.0 192.168.70.1

resultará em rotas sendo adicionadas da seguinte maneira (ele pega o IP público na mesma interface para usar como gateway de origem / no link).

10.16.0.0 255.254.0.0 On-link 203.10.10.10 11 10.17.255.255 255.255.255.255 On-link 203.10.10.10 266

Endereço privado em um segundo adaptador virtual

Eu tentei adicionar um adaptador de rede virtual ao servidor - primeiro com o dispositivo Microsoft Loopback Adapter. O dispositivo Loopback apareceu na lista de conexões de rede como tendo "mídia desconectada". Vendo que a placa de rede virtual não tinha conectividade, o Windows simplesmente voltou a enviar o tráfego através da rota padrão (com o endereço de fonte pública).

Eu então tentei com um driver de dispositivo virtual diferente - o drive adaptador TAP Virtual que vem com o OpenVPN. Esse driver permite forçá-lo a um estado "sempre conectado". No entanto, parece que após o primeiro ping, o Windows novamente descobre que não há conectividade nesse adaptador e volta a enviar o tráfego por meio do gateway padrão na interface principal (pública).

Então, é isso ... alguma idéia?

    

Answer 1

Você está lutando contra as tendências naturais de como a seleção do endereço IP de origem funciona ao tentar fazer isso. Então, por que não apenas mudar seu design um pouco para que ele flua mais naturalmente?

O problema é que a seleção do endereço IP de origem é feita antes da decisão de empurrar o tráfego pelo túnel. Isso significa que ele escolherá usar o endereço IP "público" como o IP de origem para qualquer tráfego originado pelo túnel.

Em alguns sistemas operacionais, você pode fazer coisas divertidas com o roteamento, especificando endereços de origem em uma rota para o tráfego originado no host. Não consigo encontrar nada parecido no Windows.

No entanto, dado seu projeto de rede, eu acho que a maneira mais simples de resolver este problema é parar de lutar com endereços RFC1918 no lado do servidor, e ir em frente e configurar um túnel com SAs entre seu ip público 203.10.10.10 e os endereços IP privados 10.16.0.0/15.

Os clientes então endereçariam o servidor como 203.10.10.10 em vez de 192.168.70.1, e tudo o mais esperaria que apenas se encaixasse magicamente. Dessa forma, a seleção de IP de origem já selecionará um endereço apropriado que funcionará.

Você pode manter a antiga diretiva ipsec em vigor durante um período de transição, para que seus clientes possam abordar o servidor com o endereço RFC1918 antigo ou com o novo endereço público, enquanto seu cache DNS expira (supondo que você esteja usando DNS para isso - se não, é uma boa ideia). Após um período de transição, o endereço 192.168.70.1 não tem mais nenhuma função.

A outra opção é escolher explicitamente o endereço IP de origem ao iniciar as conexões do seu servidor - o que pode ser possível se o software personalizado que você escreveu for, mas isso é meio complicado.

Finalmente, essa ideia de adaptador de loopback é promissora, mas é estranho que apareça como "mídia desconectada". Isso soa como um problema com o próprio adaptador de loopback, e não com a ideia.