Lucrez la un vpn site-to-site, unde unul finalizează un UDM și celălalt este Strongswan. Scopul este de a oferi rutare bidirecțională într-un mediu cloud. Sunt complet nedumerit de ce acest lucru nu funcționează.
Vestea bună este că Strongswan se conectează și va depăși traficul. Dar am câteva probleme de rutare pe partea Strongswan. Gazda mea Strongswan are două interfețe, eth0 care are IP-ul public de internet pe eth0 și un ip intern de 10.132.169.74 pe eth1
- Rețea[e] LAN: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
- Rețea cloud: 10.132.0.0/16
- 10.87.0.1 = UDM
- 10.132.169.74 = Strongswan eth1 și se conectează la rețeaua cloud internă 10.132.0.0/16
- 10.87.0.33 = gazdă de testare în rețeaua LAN
- 10.132.40.82 = gazdă de testare în rețeaua cloud
situatia actuala:
- ping de la 10.87.0.33 (gazdă de testare Lan) -> 10.132.169.74 (Strongswan) funcționează
- ping de la 10.132.169.74 (Strongswan) -> 10.87.0.33 (gazdă de testare Lan) funcționează
- ping de la 10.132.40.82 (gazdă de testare în cloud) -> 10.87.0.33 (gazdă de testare Lan) funcționează
- ping de la 10.87.0.33 (gazdă de testare Lan) -> 10.132.40.82 (gazdă de testare în cloud) Nu funcționează, care este cel mai important lucru din toate acestea
Iată tabelul de rutare al gazdei Strongswan 10.132.169.74:
implicit prin 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
Iată tabelul de rutare pe gazda de testare cloud (10.132.40.82):
implicit prin 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 prin 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
Pe gazda Strongswan, execut asta:
sudo ip link add ipsec0 tip xfrm dev eth0 if_id 4242
sudo ip link setează ipsec0
sudo ip route add 10.87.0.0/16 dev ipsec0 src 10.132.169.74
Și, în sfârșit, iată configurația mea de lebădă:
sudo tee /etc/strongswan.d/charon-systemd.conf << „EOF”
charon-systemd {
load=pem pkcs1 x509 constrângeri de revocare pubkey openssl aleatoriu nonce aes sha1 sha2 hmac pem pkcs1 x509 curba de revocare25519 gmp curl kernel-netlink socket-default updown vici
jurnal {
implicit=0
# enc=1
# asn=1
}
}
EOF
sudo tee /etc/swanctl/conf.d/xyz.conf << „EOF”
conexiuni {
vpn-cloud-udm-lan {
versiune=2
propuneri=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
unic=inlocuire
encap=da
local {
id=x.x.x.x
auth=psk
}
la distanta {
auth=psk
}
copii {
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=capcană
if_id_in=4242
if_id_out=4242
}
}
}
}
secrete {
ike-1 {
id-vpn-cloud=x.x.x.x
secret="somesecret"
}
ike-2 {
id-udm-lan=y.y.y.y
secret="somesecret"
}
}
EOF
și sysctl-ul meu pe gazda 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-sas arată tuneluri active și când dau ping văd că contoarele cresc. În plus, un tcpdump care ascultă pe gazda de testare în cloud nu arată traficul care sosește, dar un tcpdump pe gazda Strongswan în scenariul particular Afișează traficul, așa că este lăsat acolo.
Orice ajutor este apreciat, multumesc!
