Чем мониторить StrongSwan?

Когда-то искал для openvpn и тоже ничего готового не нашел. Хотел навайбкодить свой экспортер, но руки не дошли. Пока остановился на мониторинге самих портов в Uptime Kuma.

Когда-то искал для openvpn и тоже ничего готового не нашел

А я заморочился пару дней и нашёл решение. Выглядит у меня сейчас это -> вот так <-. Правда пришлось компилить сам экспортёр, потому как сейчас это распространяется в докере, а у меня нищебродская VPS’ка, которая не потянет контейнеры.

Загугли openvpn-exporter, там в статьях и пару дашбордов даже для графаны найдёшь

Да есть же их на гитхабе! Гугли vici exporter.

Ну strongswan понятие относительное, можно его и как туннель сделать а потом на каждое соединение свой гре. Ну а гре собирай как хотишь, тем же smtp можно …

Спасибо. Сразу нарылся ;)

github.com/torilabs/ipsec-prometheus-exporter/releases/tag/v1.9.1

а потом на каждое соединение свой гре

Нахрена лишние накладные расходы? Реализация route‑based с xfrm интерфейсами (современная альтернатива VTI), а для динамической маршрутизации OSPF.

А как с route-based делать trap для автоматического поднятия туннеля?

А как с route-based делать trap для автоматического поднятия туннеля?

Где-то в рекомендациях я встречал параметр start_action = trap указанный в children, но мне достаточно start_action = start в том же месте.
Смоделировал падение сперва одного узла, потом другого. Туннель отлично поднимается как только хост становится доступным.

Нахрена лишние накладные расходы? Реализация route‑based с xfrm интерфейсами (современная альтернатива VTI),

Т.е. gre это типа накладные расходы а vti/xfrm нет. Ага :(

P.S. Лучше расскажите а зачем в принципе юзать route-based? Чем родной режим strongswan не катит?

Давай ты сходишь в библиотеку, почитаешь про разницу между vti/xfrm и GRE, а так же про route-based и policy-based, а потом вернёшься с вопросами

Давай ты сходишь в библиотеку,

Я держал ipsec еще со времен openswan, libreswan и т.д. так что могли просто написать что не в курсе делов то, это нормально. Современные пользователи компов даже ИИ выхлоп не могут нормально распарсить.

Чем родной режим strongswan не катит?

Например тем, что иногда принимать решение о необходимости заворачивания пакета в туннель необходимо по большему количеству признаков, нежели ip адрес источника и назначения. Типичная ситуация: один и тот же адрес доступен по разным интерфейсам, но заворачивать в туннель надо только пакеты, пришедшие с одного из них, и соответственно пакеты, вышедшие из туннеля надо отправлять через тот же интерфейс.

забавно, что вместо одного запроса в гугл/LLM strongswan exporter (первые 3 релеватных результата кстати) ТС решил создать увлекательную тему на форуме с интересными рассуждениями про policy based routing, видимо истинный сетевик

Я ТС это писал не для того чтобы он мне что то объяснил а просто решил уточнить для себя, так ли оно реально нужно.

Типичная ситуация: один и тот же адрес доступен по разным интерфейсам, но заворачивать в туннель надо только пакеты, пришедшие с одного из них,

Ну в туннель то они идут не правилам фирвевалла а по раутингу. Т.е. в любом случае будут и входящие интерфейсы (в случае форварда) ну и как минимум адрес назначения. Так что думаю фиревалл тут справится.

и соответственно пакеты, вышедшие из туннеля надо отправлять через тот же интерфейс.

Ну так мы все таки про форвардинг что ли? Ну тут тоже есть тот же фиревалл …

P.S. Да я по всякому думал, крутил и так и так, не особо он нужен то route-based, причем динамически можно даже в 220 таблицу маршруты руками напихать (ну если не разрывать соединение а сетку подкинуть нужно)

Ну в туннель то они идут не правилам фирвевалла а по раутингу.

Только если у тебя route-based лол. Иначе policy работает так: ищется совпадение адреса назначения и источника, если они соответствуют политике, пакет шифруется (расшифровывается). Ни firewall, ни маршрутизатор в этом не участвуют.

Только если у тебя route-based лол.

Да ладно. Поднимите соединение и удалите маршрут в 220 таблице увидите что все.

Ну может я не понятно пишу, это тоже самое как эта сеть вываливается из rightsubnet.

Иначе policy работает так: ищется совпадение адреса назначения и источника, если они соответствуют политике, пакет шифруется (расшифровывается).

Шифруется но это не значит что этим задается направление движения.

P.S. Я не наезжаю, просто хочу сам убедиться, для себя, что мыслю верно.

Представь ситуацию: у тебя 3 туннеля, и у каждого rightsubnet 10.0.0.0/8, но при этом они ведут в разные места. У них только адресное пространство пересекается, физически там разные сети. Одной таблицей 220 тут не обойдещься.

у тебя 3 туннеля, и у каждого rightsubnet 10.0.0.0/8

в смысле 3 туннеля? Это конфа с одного центрального ящика у которого 3 туннеля с rightsubnet 10.0.0.0/8? Да ладно. Может подрезать это дело?

P.S. У меня в одном месте есть: 192.168.1.0/24,192.168.2.0/23,192.168.4.0/22,192.168.8.0/21 чтобы накрыть 1-15.

А нельзя порезать, ты не отвечаешь за инфраструктуру на том конце, только на своем. Оно так, потому что так исторически сложилось, вполне реальная ситуация.

А нельзя порезать, ты не отвечаешь за инфраструктуру на том конце, только на своем. Оно так, потому что так исторически сложилось, вполне реальная ситуация.

Так тут нужно мне разъяснить.

rightsubnet 10.0.0.0/8 это же твоя сторона, т.е. что там наковырял в iptables знаешь какой именно 10.х туда то. Т.е. эту сетку(сети) и прописывай. Главное чтобы твой диапазон был внутри того, а не зная того ты на нужный интерфейс не завернешь (обычным раутингом, не подрежешь фиреваллом и т.д.).

(х.з. но вроде понятно пишу)

rightsubnet 10.0.0.0/8 это же твоя сторона

Ну я не пользуюсь вашим ipsec.conf, с ущербным наркоманским синтаксисом, потому не помню как там правильно. В swanctl.conf используются нормальные, человекочитаемые local/remote

Что-то не понял зачем такие сложности.. https://github.com/natrontech/openvpn-exporter - хочешь докер, а хочешь скачай готовый бинарник.

Ну я не пользуюсь вашим ipsec.conf, с ущербным наркоманским синтаксисом, потому не помню как там правильно. В swanctl.conf используются нормальные, человекочитаемые local/remote

Ну это ответ не совсем по сути. (просто полно еще ящиков с rhel6х)

P.S. rightsubnet == remote_ts

Ну смотри, у есть три разных удаленных сети, которые используют адреса 10.0.0.0/8. Ты с этим ничего не можешь сделать. Но тебе надо держать до них туннели и что-то делать, чтобы трафик от машин в твоей локальной сети попадал куда надо (и соответственно, чтобы обратный трафик тоже доходил куда надо). Не очень понимаю, как такое сделать без виртуальных интерфейсов и правил маршрутизации для них.

Не очень понимаю, как такое сделать без виртуальных интерфейсов и правил маршрутизации для них.

К примеру что Вы записываете в : правил маршрутизации для них? (вы же знаете что там к примеру 10.0.1.0/24)

Это то же самое нужно записать в remote_ts, для каждого туннеля свой. Тогда этот маршрут будет сам подниматься …

Так не получится, там есть реальные пересечения с одинаковыми адресами. Приходится уже на своей стороне делать NAT/подменять DNS, чтобы это обойти.

реальные пересечения с одинаковыми адресами.

:( Мда уж. Жесть какая то. 10 и берут те кому мало 192.168 … вроде на ЖД была 10-ка, но там было жесткое разделение подсетей по дорогам.

Подскажите, кто-нить настраивал подобное на мониторинг?

Своими скриптами.