Eu tenho uma situação idêntica à pergunta emVPN IPSec: O tráfego não é roteado corretamente(no entanto, não consigo entrar em contato diretamente com esse usuário, nem posso comentar essa pergunta - e ninguém jamais respondeu).
Eu também tenho um servidor Windows 2008 R2, com uma VPN IPSec terminando diretamente no servidor.
O servidor possui uma única interface de rede, que possui um endereço IP público (vamos chamá-lo de 203.10.10.10, por exemplo).
Gostaria que os computadores em uma rede privada remota (10.16.0.0/255.254.0.0) pudessem se conectar a esse servidor Windows em um endereço IP privado no final de um túnel IPSec que terminanonesse servidor (não em um roteador na frente do servidor).
Tão importante quanto (e esse pode ser o ponto crítico) é que 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 por HTTP).
Aqui está o que parece:
O IP privado que escolhi para o servidor é 192.168.70.1/255.255.255.0 e os filtros IPSec que estabelecem o túnel para a rede privada remota são para origem/destino 192.168.70.0/24 e 10.16.0.0/15.
Se eu executar ping em um endereço na rede remota a partir do servidor Windows, com o argumento de origem definido, poderei estabelecer o túnel e os pings funcionarão (ou seja, ping -S 192.168.70.1 10.16.0.1).
No entanto, qualquer trá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 nem entra no túnel.
PERGUNTA
Uma configuração como essa é possível? Ou não é possível que o próprio endpoint da VPN envie dados pelo túnel, originados de um de seus endereços privados? (É sempre necessário que o endpoint da VPN esteja em um roteador separado do(s) dispositivo(s) que envia(m) dados através do túnel?)
Como posso configurar o Windows Server para garantir que todas as comunicações com a rede 10.16.0.0 serão originadas de seu endereço IP privado.
O endereço privado nãoterpara ser 192.168.70.1 - outra sub-rede pode ser escolhida se necessário (digo isso porque li que, todas as outras coisas sendo iguais, o Windows Vista e superior usarão o IP de origem que mais se aproxima do destino - então, talvez usando um 10.XXX ip para o endereço privado do servidor ajudaria?)
No entanto, não posso testar isso facilmente, já que a outra extremidade deste túnel VPN não está sob meu controle - e eu precisaria que os engenheiros de rede na outra extremidade fizessem alterações na configuração se eu decidir alterar o endereço 192.168.70.1 .
INFORMAÇÕES EXTRA: O QUE TENTEI ATÉ AGORA
Eu tentei dois métodos para configurar esse endereço IP privado (no servidor Windows) na tentativa de fazer com que os pacotes fossem roteados corretamenteesatisfazer 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 faria com que o Windows usasse 192.168.70.1 como endereço de origem. Qualquer tráfego destinado ao gateway padrão terá o IP público como origem.
Se houver alguma mágica disponível em termos de rota no Windows que eu não conheça, adoraria ouvir sobre ela! No entanto, o comando:
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
resultará na adição de rotas da seguinte forma (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
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 sua "mídia desconectada". Vendo que a NIC virtual não tinha conectividade, o Windows simplesmente voltou a enviar o tráfego pela rota padrão (com o endereço de origem público).
Em seguida, tentei com um driver de dispositivo virtual diferente - o driver do adaptador virtual TAP 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 descobre novamente que não há conectividade nesse adaptador e volta a enviar o tráfego através do gateway padrão na interface principal (pública).
Então é isso... alguma ideia?
Responder1
Você está lutando contra as tendências naturais de como funciona a seleção do endereço IP de origem ao tentar fazer isso. Então, por que não mudar um pouco o seu design para que ele flua mais naturalmente?
O problema é que a seleção do endereço IP de origem é feita antes da decisão de enviar o tráfego pelo túnel. Isso significa que ele escolherá usar o endereço IP “público” como IP de origem para qualquer tráfego originado pelo túnel.
Em alguns sistemas operacionais, você pode fazer coisas divertidas com roteamento, especificando endereços de origem em uma rota para tráfego originado pelo host. Não consigo encontrar nada parecido no Windows.
No entanto, dado o design da sua rede, acho que a maneira mais simples de resolver esse problema é parar de brigar com os endereços RFC1918 no lado do servidor e seguir em frente e configurar um túnel com SAs entre o seu IP público 203.10.10.10 e o IP privado. endereços 10.16.0.0/15.
Os clientes então abordariam o servidor como 203.10.10.10 em vez de 192.168.70.1, e todo o resto, esperançosamente, se encaixaria magicamente. Dessa forma, a seleção do IP de origem já escolherá um endereço apropriado que funcionará.
Você pode manter a antiga política ipsec em vigor durante um período de transição, para que seus clientes possam endereçar o servidor com o antigo endereço RFC1918 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 função.
A outra opção é escolher explicitamente o endereço IP de origem ao iniciar conexões do seu servidor - o que pode ser possível se for um software personalizado que você mesmo escreveu, mas isso é um pouco complicado.
Finalmente, a ideia do adaptador de loopback é promissora, mas é estranho que apareça como "mídia desconectada". Isso parece um problema com o próprio adaptador de loopback, e não com a ideia.