Как маршрутизировать трафик от VPN-шлюза к удаленной сети?

Question

Как маршрутизировать трафик от VPN-шлюза к удаленной сети?

Ситуация в моей среде выглядит следующим образом:

Существует сеть (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

позволяет пинг проходить без-я, но traceroute не находит маршрут к хосту. tracepath не получает ответов.

0

vpn routing strongswan

Источник

Daniel 08 ноя '18 в 18:04

1 ответ

Другие вопросы по тегам vpn routing strongswan

RalfFriedl 08 ноя '18 в 18:54 2018-11-08 18:54 · Answer 1 · 2018-11-08 18:54

Предпочтительным решением для таких проблем является установка правильных записей маршрутизации. Использование iptables может работать, если у вас нет доступа к записям таблицы маршрутизации в одной из систем.

Таким образом, в идеале вы должны иметь 213.213.213.155 маршрут до 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 интерфейс