Я работаю над VPN-соединением между сайтами, где один заканчивается UDM, а другой - Strongswan. Цель состоит в том, чтобы обеспечить двунаправленную маршрутизацию в облачную среду. Я совершенно сбит с толку, почему это не работает.
Хорошей новостью является то, что Strongswan подключается и пропускает трафик. Но у меня есть некоторые проблемы с маршрутизацией на стороне Strongswan. Мой хост Strongswan имеет два интерфейса: eth0 с общедоступным IP-адресом в Интернете на eth0 и внутренний IP-адрес 10.132.169.74 на eth1.
- Локальная сеть [ы]: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
- Облачная сеть: 10.132.0.0/16
- 10.87.0.1 = УДМ
- 10.132.169.74 = Strongswan eth1 и подключается к внутренней облачной сети 10.132.0.0/16.
- 10.87.0.33 = тестовый хост в локальной сети
- 10.132.40.82 = тестовый хост в облачной сети
текущая ситуация:
- пинг с 10.87.0.33 (тестовый хост локальной сети) -> 10.132.169.74 (Strongswan) работает
- пинг с 10.132.169.74 (Strongswan) -> 10.87.0.33 (тестовый хост) работает
- пинг с 10.132.40.82 (облачный тестовый хост) -> 10.87.0.33 (сетевой тестовый хост) работает
- пинг с 10.87.0.33 (тестовый хост локальной сети) -> 10.132.40.82 (тестовый облачный хост) Не работает, и это самое главное из всего этого
Вот таблица маршрутизации узла Strongswan 10.132.169.74:
по умолчанию через x.x.x.x dev eth0 proto static
10.17.0.0/16 dev eth0 ссылка на область ядра proto src 10.17.0.21
10.19.49.0/24 dev wg0 прото-область ядра ссылка src 10.19.49.1
10.87.0.0/16 dev ipsec0 ссылка области src 10.132.169.74
10.132.0.0/16 dev eth1 прото-область ядра ссылка src 10.132.169.74
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z
Вот таблица маршрутизации на облачном тестовом хосте (10.132.40.82):
по умолчанию через x.x.x.x dev eth0 proto static
10.17.0.0/16 dev eth0 ссылка на область действия прототипа ядра src 10.17.0.24
10.87.0.0/16 через 10.132.169.74 dev eth1
10.132.0.0/16 dev eth1 прото-область ядра ссылка src 10.132.40.82
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z
На хосте Strongswan я выполняю это:
sudo ip link добавить тип ipsec0 xfrm dev eth0 if_id 4242
sudo ip link установить ipsec0 вверх
sudo ip route добавить 10.87.0.0/16 dev ipsec0 src 10.132.169.74
И, наконец, вот мой конфиг лебедя:
sudo tee /etc/strongswan.d/charon-systemd.conf << "EOF"
charon-systemd {
load=pem pkcs1 x509 ограничения отзыва pubkey openssl random random nonce aes sha1 sha2 hmac pem pkcs1 x509 отзыв curve25519 gmp curl kernel-netlink socket-default updown vici
журнал {
по умолчанию=0
# enc=1
# asn=1
}
}
EOF
sudo tee /etc/swanctl/conf.d/xyz.conf << "EOF"
связи {
vpn-облако-udm-lan {
версия=2
предложения = aes128gcm16-sha256-modp2048, aes128-sha256-modp2048
уникальный = заменить
инкапсуляция = да
местный {
идентификатор = х.х.х.х
авторизация = psk
}
удаленный {
авторизация = psk
}
дети {
сеть {
локальные_тс=10.132.0.0/16
remote_ts=10.87.0.0/16
esp_proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
start_action = ловушка
если_id_in=4242
если_id_out=4242
}
}
}
}
секреты {
ике-1 {
id-vpn-cloud=x.x.x.x
секрет = "некоторый секрет"
}
ике-2 {
id-udm-lan=y.y.y.y
секрет = "некоторый секрет"
}
}
EOF
и мой sysctl на хосте Strongswan:
сеть.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 показывает активные туннели, и когда я пингую, я вижу, что счетчики растут. Кроме того, прослушивание tcpdump на облачном тестовом хосте не показывает входящего трафика, но tcpdump на хосте Strongswan в конкретном сценарии ДЕЙСТВИТЕЛЬНО показывает трафик, поэтому он отбрасывается туда.
Любая помощь приветствуется, спасибо!
