StrongSwan как пересылать пакеты из подсети клиента 1, в подсеть клиента 2?

Question

[ettaluni]

Доброго дня! Открыл я локальную сеть клиентов vpn, теперь не знаю как пакеты пересылать из локальной сети Клиента1 по туннелю strongSwan в локальную сеть клиента 2.
то есть вот такой маршрут: 192.168.10.1 -> 10.1.1.1 -> StrongSwan Server -> 10.1.1.2 -> 192.168.20.1
Кто нибудь знает как это сделать?
Моя крутая сеть:

Comments

[Valentin Barbolin]

192.168.10.1 не пингует 192.168.20.1 ?
Что показывает tracert -d 192.168.20.1?
StrongSwan на GW находится?
Маршруты в StrongSwan прописаны?

[ettaluni]

Andrey Barbolin,
Локальная сеть 1 со своим роутером и провайдером
Клиент 1 с двумя ip (192.168.10.x и 10.1.1.1)
VPS на амазоне, на котором крутиться StronSwan Server
Клиент 2 с двумя Ип (192.168.20.x и 10.1.1.2)
Локальная сеть клиента 2 со своим роутером и провайдером

[ettaluni]

Andrey Barbolin, Ничего не пингует, я только стронг ван поднял

[Valentin Barbolin]

> VPS на амазоне, на котором крутиться StronSwan Server
Кто поднимает тунель со стороны клиента?

[ettaluni]

Andrey Barbolin, Я не понимаю. Есть сервер StrongSwan, и два клиента собственно я все настроил. ipsec запускается сразу при загрузке машины и вулая туннель готов.

[Valentin Barbolin]

ettaluni Судя по скриншоту, ПК внутри сети сами поднимают туннель. Соответственно, нужны маршруты на клиентах, маршруты на VPS, и разрешить ip_forward на VPS.

[Valentin Barbolin]

ettaluni, При построение VPN есть роли Server и Client.
С сервером понятно - VPS
Кто выступает клиентом? Клиентом может быть роутер, ПК.
Из твоего описания не понятно кто клиент, соответственно не понятно куда надо добавить маршруты.

[ettaluni]

Andrey Barbolin, Ах да, клиенты оба linux debian 10

Answer 1

[Максим Гришин]

По результатам обсуждения - входит довольно большой комплекс изменений. Во-первых, нужно изменить настройки подсетей в обоих туннелях: на сервере 10.0.1.1 для подключения каждого клиента нужно добавлять подсети всех остальных клиентов (сейчас один, но мало ли, может, вам понравится), т.е. дополнительно leftsubnet=192.168.20.0/24 для 10.1.1.1 и 10.0/24 для 10.1.1.2. Такая же настройка должна быть на стороне клиентов, так как они теперь должны в туннель пропихивать пакеты для нелокальных подсетей, т.е. если leftsubnet=192.168.10.0/24, то rightsubnet должен также содержать 192.168.20.0/24, и зеркально для второго клиента.
Во-вторых, на каждом клиенте нужно добавить маршрут до удаленной сети через 10.0.1.1. Сервер, по идее, при поднятии соединений добавит себе маршруты до их rightsubnet'ов самостоятельно. Проверить стоит, ip route show table all должен показать в таблице 220 (по умолчанию именно в неё strongswan складывает VPN-маршруты) корректные маршруты внутрь каждого туннеля.

Comments

[ettaluni]

Я пробовал так , делать tracertout проверял потом улетает в никуда
Как Натить?

[ettaluni]

и мне нужно наоборот, чтобы 10.1.1.1 видел локальную сеть 10.1.1.2(192.168.20.0)

[Максим Гришин]

Так или иначе, сети связаны через центральный сервер. Скорее всего, маршруты до остальных сетей должны быть прописаны и на 10.1.1.1, 10.1.1.2, чтобы их искали за дальней стороной VPN"a - если я правильно понимаю, то 10.1.1.1 имеет прямой выход в интернет и его шлюз по умолчанию не находится внутри VPN. Возможно, удастся обойти конфигурацию клиентов, заставив сервер пушить таблицу маршрутизации вида 192.168.0.0/16 via 10.0.1.1
Вообще, такие проблемы надо отлаживать изнутри сетей 192.168, чтобы в случае недостатка конфигурации на VPN endpoint'ах они всплывали на traceroute.

[Максим Гришин]

update: strongswan не умеет пушить таблицу маршрутизации. Значит, нужно конфигурировать дополнительные маршруты на клиентах.

[ettaluni]

Максим Гришин, Я мало что понял, а по туннелю пустить маршруты никак нельзя? У меня один серый ИП, был бы белый я бы не заморачивался с ВПН

Значит, нужно конфигурировать дополнительные маршруты на клиентах.

Что это значит? Я роуты пытался прописать ничего не работает

[Максим Гришин]

ettaluni, дык, прописывать их надо все как целое, и на каждом узле, куда попадает пакет, проверить, что следующий узел, куда он полетит по таблице маршрутизации, находится в правильной стороне и сам сможет направить пакет дальше. В обратную сторону, кстати, то же самое.
По туннелю как раз всё и должно пускаться - когда ты пишешь, что маршрут через второй конец туннеля, пакет будет пытаться быть запихнутым в туннель. Кстати, параметры IPSec встанут препятствием, если на left/right subnet отсутствует целевая сеть... 10.1.1.1 должен знать, что за второй стороной (10.0.1.1) могут быть адреса 192.168.20.0/24, а 10.1.1.2 должен знать про 192.168.10.0 на стороне 10.0.1.1. Тогда параметры IPsec в туннелях придется тоже поменять - на стороне 10.0.1.1 помимо имеющихся пар сетей должны объявляться 192.168.20.0/24 для туннеля с 10.1.1.1, и 192.168.10.0/24 для туннеля с 10.1.1.2, оба клиента могут ожидать того же или шире (192.168.0.0/16, например, минус своя подсеть) на второй стороне.

[Максим Гришин]

Обновил ответ.

[ettaluni]

Максим Гришин, Спасибо что расписал все по пунктам, последние комментарии я мало понял)

[CityCat4]

Елы-палы, сколько раз уже писал - шваны и вообще IPSec не использует маршрутизацию для доставки пакетов. Ну точнее говоря, он ее использует, но потом. Для определения куда надо отправить пакет и в каком виде его туда упаковать используются политики, которые строятся на основе конфигов швана

[ettaluni]

CityCat4, До меня долго доходит))) Я только сейчас начал понимать про какие политики ты говоришь, наверно ими я и открыл доступ клиентам к свой локальной сети. Раньше вообще все блокировало! Клиент видел только свой ВПН, не из вне, ни изнутри до него было не достучаться.
Может еще сети по изучаю смогу настроить двухстороннюю видимость, я вроде как алгоритм действй составил.

[CityCat4]

ettaluni, Возможно.
ip xfrm policy list что показывает?

[ettaluni]

CityCat4, Вот на одном из клиентов:

[CityCat4]

ettaluni, Блин, тут уже был один чел, у которого была похожая картина - как будто вы по одному гайду делали :)
Что здесь можно сказать.
Первая политика - "все, идущее с 10.1.22.1, запаковать в ESP, поставить src ip 192.168.0.82, dst ip который замазан, зашифровать по spi такому-то и отправить в тырнет"
Вторая и третья - "все, что пришло на 10.1.22.1 с src ip который замазн и dst ip 192.168.0.82..." - почему я поставил точки - потому что тут должен стоять spi, по которому расшифровывается пакет, я вовсе не уверен, что политика рабочая (но для этого мне нужно глянуть рабочее соединение, а у меня в основном микротик-микротик)

[ettaluni]

CityCat4, Спасибо за перевод! Я по ipsec status обычно смотрел.

[CityCat4]

ettaluni, тоже вариант. Что он показывает?

[Максим Гришин]

CityCat4, чтобы пакет долетел через два туннеля, маршрутизация тоже должна быть настроена, особенно если на локальной тачке внезапный докер или ещё какая-то нетривиальная конфигурация. И IPsec в самом деле не учитывает маршрутизацию - потому что ему не надо, его задача определить, шифровать ли пакет и чем, после того, как routing engine определил следующий хоп. А то, что демон, реализующий IPsec, ещё и заботится о заполнении таблицы маршрутизации - приятное следствие, он не обязан это делать. В любом случае, я тут вижу обычную непонятку с терминами с учетом необходимости объяснить "для чайников", куда смотреть, необязательно ТС окажется единственным, кто что-то будет делать по этой инструкции. И если ему понятно - ОК.

[CityCat4]

Максим Гришин,

А то, что демон, реализующий IPsec, ещё и заботится о заполнении таблицы маршрутизации - приятное следствие, он не обязан это делать.

Ничего подобного он не делает.

Чтобы пакет долетел через два туннеля, достаточно чтобы был настроен самый обычный "выход в интернет" на обоих шлюзах. Да, ESP заюзает роутинг - когда ESP-пакет уже будет готов, зашифрован и подписан, он отправится в тырнет по общим правилам маршрутизации - с учетом шлюзов, метрик и балансировки. Но если в таблице маршрутов есть запись направлять "все пакеты туда-то" (а она там непременно есть, default route как минимум), а в SPD - запись, которая предписывает пакеты "оттуда-то туда-то" пускать совершенно другим путем, выполняться будет действие, предписанное SPD.

его задача определить, шифровать ли пакет и чем, после того, как routing engine определил следующий хоп

Че?
То, что мы называем IPSec - это как правило "сладкая парочка" из IKE (ISAKMP) и ESP, которые суть два самостоятельных протокола. IKE занимается тем, что согласовывает сертификаты-пароли, таймауты и параметры шифровальных наборов, заполняет SAD (SPD заполняет либо юзер либо шван) и именно он отдает готовый туннель. И именно его логи мы изучаем, когда понять не можем почему не вяжется. А ESP - транспортный уровень, он доставляет шифрованные пакеты. Нет в IKE никакого routing engine - только SPD, которая должна иметь к этому времени нужную запись (иначе пакеты не будут шифроваться и пойдут как раз в общий routing engine).

И, блин, еще раз - для IPSec не нужна маршрутизация "внутренних" подсетей (в отличие от openvpn) - только знание того, как доставить пакеты IKE и ESP между "внешними" адресами.

[ettaluni]

CityCat4, Максим Гришин, Я смог настроить клиенты таким образом чтобы пакеты по назначению 192.168.10.0/24 или 192.168.20.0/24 улетают на локальный адрес VPS 172.26.13.11. А дальше почему то улетает в интернет а не на Клиент1 \ Клиент2.
Не получается настроить сервер, я пытался прописывать connection. Left\right ставил 192.168.10-20, попеременно 10.1.22.1-2 и 192.168.10-20, безрезультатно. Все равно уходит в интернет.
Попытался прописать политики:

ip xfrm policy add src 0.0.0.0/0 dst 192.168.10.0/24 dir out tmpl src 172.26.13.11 dst <Public IP Клиента 1> proto esp reqid "2" mode tunnel
ip xfrm policy add src 192.168.10.0/24 dst 0.0.0.0/0 dir in tmpl src <Public IP Клиента 1>  dst 172.26.13.11 proto esp reqid "2" mode tunnel
ip xfrm policy add src 192.168.10.0/24 dst 0.0.0.0/0 dir fwd tmpl src <Public IP Клиента 1>  dst 172.26.13.11 proto esp reqid "2" mode tunnel

Или

ip xfrm policy add src 0.0.0.0/0 dst 192.168.10.0/24 dir out tmpl src 172.26.13.11 dst 10.1.22.1 proto esp reqid "2" mode tunnel
ip xfrm policy add src 192.168.10.0/24 dst 0.0.0.0/0 dir in tmpl src 10.1.22.1 dst 172.26.13.11 proto esp reqid "2" mode tunnel
ip xfrm policy add src 192.168.10.0/24 dst 0.0.0.0/0 dir fwd tmpl src 10.1.22.1 dst 172.26.13.11 proto esp reqid "2" mode tunnel

traceroute 192.168.10.1 вообще замолчал, дальше локального ип не уходит 172.26.13.11.
Можете подсказать что прописать на VPS чтобы пакеты с назначения 192.168.10-20 уходили на соответствующие клиенты?