Estou trabalhando em uma VPN site-to-site, onde uma termina com UDM e a outra com Strongswan. O objetivo é fornecer roteamento bidirecional em um ambiente de nuvem. Estou completamente perplexo por que isso não está funcionando.
A boa notícia é que Strongswan se conecta e passará o tráfego. Mas tenho alguns problemas de roteamento no lado de Strongswan. Meu host Strongswan tem duas interfaces, eth0 que possui o IP público da Internet na eth0 e um ip interno de 10.132.169.74 na eth1
- Rede[s] Lan: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
- Rede em nuvem: 10.132.0.0/16
- 10.87.0.1 = UDM
- 10.132.169.74 = Strongswan eth1 e se conecta à rede interna da nuvem 10.132.0.0/16
- 10.87.0.33 = host de teste na rede LAN
- 10.132.40.82 = host de teste na rede em nuvem
situação atual:
- ping de 10.87.0.33 (host de teste Lan) -> 10.132.169.74 (Strongswan) funciona
- ping de 10.132.169.74 (Strongswan) -> 10.87.0.33 (host de teste Lan) funciona
- ping de 10.132.40.82 (host de teste de nuvem) -> 10.87.0.33 (host de teste de Lan) funciona
- ping de 10.87.0.33 (host de teste Lan) -> 10.132.40.82 (host de teste em nuvem) Não funciona, o que é a coisa mais importante de tudo isso
Aqui está a tabela de roteamento do host Strongswan 10.132.169.74:
default via x.x.x.x dev eth0 proto static
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.21
10.19.49.0/24 dev wg0 proto kernel scope link src 10.19.49.1
10.87.0.0/16 dev ipsec0 scope link src 10.132.169.74
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.169.74
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z
Aqui está a tabela de roteamento no host de teste em nuvem (10.132.40.82):
default via x.x.x.x dev eth0 proto static
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.24
10.87.0.0/16 via 10.132.169.74 dev eth1
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.40.82
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z
No host Strongswan, estou executando isto:
sudo ip link add ipsec0 type xfrm dev eth0 if_id 4242
sudo ip link set ipsec0 up
sudo ip route add 10.87.0.0/16 dev ipsec0 src 10.132.169.74
E finalmente aqui está minha configuração do cisne:
sudo tee /etc/strongswan.d/charon-systemd.conf << "EOF"
charon-systemd {
load=pem pkcs1 x509 revocation constraints pubkey openssl random random nonce aes sha1 sha2 hmac pem pkcs1 x509 revocation curve25519 gmp curl kernel-netlink socket-default updown vici
journal {
default=0
# enc=1
# asn=1
}
}
EOF
sudo tee /etc/swanctl/conf.d/xyz.conf << "EOF"
connections {
vpn-cloud-udm-lan {
version=2
proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
unique=replace
encap=yes
local {
id=x.x.x.x
auth=psk
}
remote {
auth=psk
}
children {
net {
local_ts=10.132.0.0/16
remote_ts=10.87.0.0/16
esp_proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
start_action=trap
if_id_in=4242
if_id_out=4242
}
}
}
}
secrets {
ike-1 {
id-vpn-cloud=x.x.x.x
secret="somesecret"
}
ike-2 {
id-udm-lan=y.y.y.y
secret="somesecret"
}
}
EOF
e meu sysctl no host Strongswan:
net.ipv4.ip_forward=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
sudo swanctl --list-sasmostra túneis ativos e quando faço ping, posso ver os contadores subirem. Além disso, um tcpdump escutando no host de teste da nuvem não mostra nenhum tráfego chegando, mas um tcpdump no host Strongswan no cenário específico mostra o tráfego, então ele será descartado lá.
Qualquer ajuda é apreciada, obrigado!
Responder1
Então, depois de muito bater cabeça (não do tipo que você faz com rock) e ranger de dentes, descobri esta resposta:https://www.digitalocean.com/community/questions/site-to-site-vpn-support-any-updates
A Digital Ocean estava descartando pacotes em interfaces privadas. Então adicionei uma regra de firewall para permitir o tráfego de 10.87.0.0/24 e wahlah! É WERX!!!