Como configurar o NAT no Windows Server 2008 r2 para uso de encapsulamento IPSec

Question

Estou tendo problemas para configurar toda a coisa do túnel IPSec.

O que eu tenho:
1. Roteador que possui apenas uma funcionalidade de passagem VPN / IPsec (IP 192.168.0.1)
2. Windows Server 2008 R2 que possui políticas de grupo configuradas para o túnel IPSec. (Servidores IP 192.168.0.2; gw 192.168.0.1)
3. A máquina Linux possui uma aplicação (IP 192.168.0.3; gw 192.168.0.2)

A outra extremidade do túnel IPSec está em outro local pela Internet.

A empresa do outro lado do túnel me disse, eu devo ter o IP 10.100.101.102 como um ip de origem para todos os meus pacotes que entram no túnel IPSec da máquina Linux.

Então a ideia é:
1. Linux forma um pacote e envia para o PC de destino (111.222.333.444) em uma porta específica. Então src = 192.168.0.3; dst = 111.222.333.444
2. O pacote viaja para o servidor Windows.
3. O servidor pega o pacote e altera o src para src = 10.100.101.102, deixando o dst igual.
4. O servidor criptografa o pacote usando as opções IPSec e as envia para o ponto de extremidade remoto através do roteador. 5. [ações no ponto final remoto]
6. O servidor Windows recebe a resposta e a descriptografa.
7. Altera o dst (10.100.101.102) para o local dst = 192.168.0.3.
8. Envie o pacote para o Linux e o aplicativo.

Como faço para conseguir tudo isso? Eu não consigo entender como o NAT está trabalhando no servidor Windows. Eu configurei-o em 'roteamento e acesso remoto', mas eu não vi nenhuma opção de especificar qual fonte IP e porta com pacotes devem ser alterados para ter o 10.100.101.102 como src.

    

Answer 1

você precisaria de respostas definitivas para as seguintes perguntas antes de prosseguir:

1. você pode fazer o ping do roteador a partir da caixa linux?

2. se você puder, você pode traceroute da caixa linux para o roteador? das perguntas acima, quero ter certeza de que uma. seu tráfego vai para a caixa do Windows de fato e, em seguida, o roteador, não diretamente para o roteador. o tracert lhe dirá isso com certeza. b. sua infra-estrutura de roteamento interno está funcionando corretamente.

3. qual é o endereço IP do dispositivo IPsec da outra empresa? Os túneis IPsec são bastante estáticos e você não pode configurá-los usando nomes DNS, portanto, é necessário conhecer o endereço do ponto final remoto do IPsec.

4. o outro ponto de extremidade suporta o IPsec Nat-Traverse (NAT-T)? se eles não puderem dizer isso com certeza, pergunte a eles a marca e o modelo do dispositivo de ponto de extremidade e, se possível, a versão do software / firmware e procure por essas informações.

do que você está nos dizendo acima, parece que primeiro você tem que ter o seu roteamento interno correto, já que o roteador enviará o tráfego diretamente para o Linux e o obterá dele também, sem nem mesmo deixar as janelas entrarem o jogo, a menos que você ou mexa manualmente com as tabelas de roteamento em todas as 3 caixas, todas as 3 (bem, talvez não as janelas se você tiver configurado o RRAS, mas mesmo que precisa verificar), ou usar diferentes sub-redes para diferentes seagments; por exemplo, 192.168.0.1 para roteador, 192.168.0.2 para janelas, outro IP como 192.168.1.1 para windows e 192.168.1.3 para linux. A propósito, se você seguir essa segunda abordagem, certifique-se de que o roteador também conheça a segunda sub-rede colocando uma rota para a rede 192.168.1.x através do 192.168.0.2 (o IP do Windows no mesmo intervalo que o da rede). IP do roteador).

depois que você tiver todos os c..p acima, agora você pode começar a trabalhar com a coisa real! é isso que acontece:

nomeamos o IP no linux linip

nomeamos o IP das janelas no Linux Seagment WinIPL

nomeamos o IP das janelas no Win XPR (caso você tenha escolhido a abordagem de manipulação manual da tabela de roteamento acima, os dois WinIPs serão os mesmos)

nós nomeamos o IP do roteador no seu lado interno RoutIPint

nomeamos o IP do seu roteador no lado voltado para o público (o IP que o ISP fornece a você) RoutIPext.

nomeamos o IP do ponto de extremidade IPsec remoto, RemTunIP.

nomeamos o IP do recurso que você está tentando acessar na outra empresa por trás do RemResIP do túnel.

quando o seu linux gera um pacote, ele coloca o LinIP como fonte e o RemResIP como o destino; dá isso para a Caixa do Windows através do IP WinIPL.

Windows Box, se configurado corretamente, colocará esse pacote (incluindo o cabeçalho IP mencionado acima) em outro pacote, colocará WinIPR como a fonte, RemTunIP como o destino, DIGITALY SIGNS WinIPR e RemTunIP e o entregará ao roteador

os NATs do roteador que assinaram o pacote para RoutIPext e RemTunIP. aqui é um dos muitos lugares onde essa cadeia pode ficar confusa, já que a ASSINATURA é violada aqui e o pacote é invalidado A MENOS que sua caixa do Windows e o ponto final da IPsec da outra empresa sejam compatíveis com NAT; aka tem NAT-T ativado neles. use este artigo kb da microsoft para ativar o Nat-T na sua caixa do Windows (pode parecer que é para VPN à primeira vista, mas é uma configuração geral do IPsec, por isso faça o trabalho): link se o dispositivo IPsec da sua empresa remota estiver atrás do NAT, coloque 2; se não, ou se a outra empresa não suportar o Nat-T (o que implica que eles não estão ligando o tráfego IPsec), coloque 1.

quando a borda remota do dispositivo Ipsec recebeu o seu pacote (FINALMENTE!), seria na forma de RoutIPext e RemTunIP. usando o Nat-T, ele extrairá o pacote com o WinIPR e o RemTunIP, usando o Decsption do IPsec, extrairá o pacote com o LinIP e o RemResIP, encaminhará de acordo e o entregará ao recurso que o seu linux estava tentando acessar.

então você precisa ter:

a. escritório remoto ciente da sua sub-rede Linux local

b. defina a política do IPsec em suas janelas para formar o túnel com WinIPR e RemTunIP e nada mais.

c. ter a política de correspondência da configuração do RemTunIP e WinIPR no site remoto.

d. ter o repasse ativado no seu roteador.

e. ter passado os pré-requisitos como eu disse antes da parte do IPsec acima (tracert e subnetting e outras coisas)

!!! POR ISSO NÃO É TRIVIAL !!!