Ситуация в моем окружении следующая:
Есть сеть (213.213.213.128/26) с VPN-шлюзом (213.213.213.155).
На AWS есть удаленная сеть (10.42.0.16/28), которая связана с 213.213.213.128/26 через AWS VPC VPN, на которой есть сервер RADIUS на 10.42.0.30.
Я хочу, чтобы внешние клиенты подключались к 213.213.213.128/26, используя шлюз VPN 213.213.213.155 с аутентификацией через 10.42.0.30.
Моя проблема в том, что 213.213.213.155 не достигает 10.42.0.30, поскольку он отправляет через неправильный интерфейс. Когда я добавляю
iptables -t nat -A POSTROUTING -s <address of the tunnel interface> -d 10.42.0.16/28 -j SNAT --to-source 213.213.213.155
Я могу пинговать 10.42.0.30, но пакеты RADIUS не передаются через туннель.
Как мне изменить конфигурацию сети, чтобы разрешить шлюзу (213.213.213.155) подключаться к хостам в 10.42.0.16/28?
Я использую Strongswan в качестве VPN-сервера. Пинг с -I 213.213.213.155 успешно без правила iptables.
РЕДАКТИРОВАТЬ
Таблица маршрутизации выглядит следующим образом:
10.0.0.0/8 dev Tunnel1 scope link metric 100
10.0.0.0/8 dev Tunnel2 scope link metric 200
213.213.213.128/26 dev eno1 proto kernel scope link src 213.213.213.155
169.254.21.173 dev Tunnel1 proto kernel scope link src 169.254.21.174
169.254.21.233 dev Tunnel2 proto kernel scope link src 169.254.21.234
Изменение таблицы маршрутизации на:
10.0.0.0/8 dev Tunnel1 scope link metric 100 src 213.213.213.155
10.0.0.0/8 dev Tunnel2 scope link metric 200 src 213.213.213.155
213.213.213.128/26 dev eno1 proto kernel scope link src 213.213.213.155
169.254.21.173 dev Tunnel1 proto kernel scope link src 169.254.21.174
169.254.21.233 dev Tunnel2 proto kernel scope link src 169.254.21.234
позволяет пингу проходить без -I, но traceroute не находит маршрута к хосту. tracepath не получает ответов.
Предпочтительным решением таких проблем является установка правильных записей маршрутизации. Использование iptables может работать, если у вас нет доступа к записям таблицы маршрутизации в одной из систем.
Таким образом, в идеале у вас должен быть маршрут к 10.42.0.16/28 через 213.213.213.155 и на 10.42.0.30 к 213.213.213.128/26 через локальный шлюз VPN.
Если вы не можете изменить таблицу маршрутизации на сервере RADIUS и для этого вам нужны iptables, убедитесь, что правило применяется к отправляемым пакетам RADIUS. Использовать tcpdump следить за пакетами RADIUS на интерфейсе any и отметьте адреса отправителя и получателя.
Какова цель ограничения iptables правило -s <address of the tunnel interface>? Простого удаления этой опции может быть достаточно, чтобы она заработала.
Как вы можете использовать iptables, вы должны иметь возможность настраивать записи маршрутизации. Пытаться
ip route add 10.42.0.16/28 src 213.213.213.155
Этого должно быть достаточно, чтобы назначить правильный адрес источника без использования -I возможность ping, и он должен использовать исходный адрес для каждого другого соединения, включая RADIUS. Обычно программное обеспечение VPN должно быть достаточно умным, чтобы настроить что-то в этом направлении без дополнительной настройки. Если это не сработает, вам может понадобиться
ip route add 10.42.0.16/28 dev tun0 src 213.213.213.155
где tun0 это ваш интерфейс VPN.