Estou configurando uma vpn para uma das redes de nossos clientes. Devido a um requisito em seu final, não podemos ter o nosso tráfego (parece vir) de um endereço IP privado. Consegui obter uma configuração de túnel com nosso cliente, mas estou tendo problemas para fazer com que o NAT funcione conforme necessário. Para fins de teste, simulei o ambiente no AWS usando 2 VPCs e observando o tráfego usando tcpdump ou tshark, para ver qual é o endereço IP. Aqui está uma cópia da configuração com diferentes endereços IP.
(Simulated Customer Side VPC - 172.16.0.0/16)
Customer Test Server - 172.16.0.20
AWS Hardware VPN - 1.1.1.1
|
|
|
(Internet)
|
|
|
(Our VPC - 10.10.10.0/16)
OpenSwan VPN server - 2.2.2.2 and 10.10.10.10
Internal Test Server - 10.10.10.20
O arquivo ipsec.conf para o OpenSwan ....
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=2.2.2.2
right=1.1.1.1
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
auth=esp
keyingtries=%forever
keyexchange=ike
leftsubnet=10.10.10.0/16
rightsubnet=172.16.0.0/16
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
e o arquivo de segredos se parece com ....
2.2.2.2 1.1.1.1: PSK "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Eu também configurei os seguintes valores em /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
Fazendo isso, posso fazer com que o túnel chegue "up" e posso me comunicar entre as instâncias de teste usando os endereços IP privados do outro testador (de ambos os lados). Isso mostra (para ping e ssh) que a comunicação vem do endereço IP privado do outro servidor de teste. Por exemplo, um ping de 10.10.10.20 a 172.16.0.20 mostra (via tshark) o ping vindo de 10.10.10.20.
Para fazer com que o tráfego pareça vir do endereço IP externo do servidor OpenSwan, adicionei uma entrada de tabelas ip à instância do OpenSwan.
iptables -t nat -I POSTROUTING -s 10.10.10.0/16 -d 172.16.0.0/16 -o eth0 -j SNAT --to-source 2.2.2.2
Então, quando eu faço ping de 10.10.10.20 para 172.16.0.20, o ping vem do 2.2.2.2. Este é o comportamento que eu estava esperando, no entanto, quando eu tento ssh de 10.10.10.20 para 172.16.0.20 o tráfego nunca chega lá. Um tshark no Customer Test Server não mostra nenhum tráfego ssh vindo, seja de 10.10.10.20 ou 2.2.2.2, e um tcpdump no servidor OpenSwan mostra o tráfego como não ficando NATado para 2.2.2.2 (ele só mostra pacotes para 10.10. 10.20 - > 172.16.0.20: 22).
Eu tentei muitas configurações diferentes (lutando por vários dias) para configurar a esquerda, leftsubnet, leftsourceip, leftnexthop, bem como usando SNAT e MASQUERADE, e outras entradas diferentes do iptables, sem sorte de fazer o tráfego parecer necessário .
O que é necessário para que o tráfego de entrada na rede de clientes pareça vir de um endereço IP externo ?. Qualquer ajuda é muito apreciada. Obrigado.
Se você precisar de logs tcpdump ou tshark adicionais, também posso fornecê-los.
E FWIW, eu tenho as tabelas de rota da AWS no conjunto Customer Test VPC para que o tráfego 2.2.2.2 e 10.10.10.0/16 vá para o gateway VPN, e as tabelas de rotas em nossa VPC tenham todas as 172.16.0.0/ 16 tráfego indo para o ENI para a instância do OpenSwan.