Estoy trabajando en una VPN de sitio a sitio, donde uno nos termina con un UDM y el otro es Strongswan. El objetivo es proporcionar enrutamiento bidireccional a un entorno de nube. Estoy completamente desconcertado por qué esto no funciona.
La buena noticia es que Strongswan se conecta y pasará el tráfico. Pero tengo algunos problemas de ruta en el lado de Strongswan. Mi host Strongswan tiene dos interfaces, eth0 que tiene la IP pública de Internet en eth0 y una IP interna de 10.132.169.74 en eth1.
- Redes LAN: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
- Red en la nube: 10.132.0.0/16
- 10.87.0.1 = UDM
- 10.132.169.74 = Strongswan eth1 y se conecta a la red interna de la nube 10.132.0.0/16
- 10.87.0.33 = host de prueba en la red LAN
- 10.132.40.82 = host de prueba en la red en la nube
situación actual:
- hacer ping desde 10.87.0.33 (host de prueba Lan) -> 10.132.169.74 (Strongswan) funciona
- hacer ping desde 10.132.169.74 (Strongswan) -> 10.87.0.33 (host de prueba Lan) funciona
- hacer ping desde 10.132.40.82 (host de prueba en la nube) -> 10.87.0.33 (host de prueba Lan) funciona
- hacer ping desde 10.87.0.33 (host de prueba Lan) -> 10.132.40.82 (host de prueba en la nube) No funciona, que es lo más importante de todo esto
Aquí está la tabla de enrutamiento del 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
Aquí está la tabla de enrutamiento en el host de prueba en la nube (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
En el host Strongswan, estoy ejecutando esto:
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
Y finalmente aquí está mi configuración de 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
y mi sysctl en el 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-sasmuestra túneles activos y cuando hago ping puedo ver que los contadores aumentan. Además, un tcpdump que escucha en el host de prueba en la nube muestra que no llega tráfico, pero un tcpdump en el host de Strongswan en el escenario particular SÍ muestra el tráfico, por lo que se descarta allí.
¡Cualquier ayuda se agradece, gracias!
Respuesta1
Entonces, después de muchos golpes en la cabeza (no del tipo que se hace con la música rock) y crujir de dientes, lo descubrí a partir de esta respuesta:https://www.digitalocean.com/community/questions/site-to-site-vpn-support-any-updates
Digital Ocean estaba dejando caer paquetes en interfaces privadas. Así que agregué una regla de firewall para permitir el tráfico desde 10.87.0.0/24 y ¡wahlah! ¡¡¡ES WERX !!!