VPN с использованием OSPF поверх

надо на каждого клиента делать по процессу openvpn

Звучит как надуманый минус. Вы хотите какой-то старнный vpn-клиент, у которого один процесс, но куча интерфейсов точка-точка. Маршрутизации у него нет, но от как-то знает какой из своих интерфейсов с каким внешним связан.

Один процесс, один транспорный порт, всё хорошо можно отлаживать. Можно tcpdump'ом проверять, что пришёл пакет — появился шифрованый пакет на внешнем интерфейсе.

Может быть подойдет какой-нибудь peer-to-peer vpn?

Я когда то использовал PeerVPN (https://peervpn.net/) - получался виртуальный коммутатор поверх узлов, разбросанных по разным IP сетям. Т.е. на каждом узле имеешь всего один процесс и всего один виртуальный Ethernet-интерфейс. А самое главное - отсутствие центральной точки отказа.

Звучит как надуманый минус. Вы хотите какой-то старнный vpn-клиент, у которого один процесс, но куча интерфейсов точка-точка. Маршрутизации у него нет, но от как-то знает какой из своих интерфейсов с каким внешним связан.

Согласен, минус надуманный, и, наверно, не минус, просто хочется удобства в том виде который мне кажется удобным :).

Если интерфейс point-to-point то маппинг между теми адресам что в туннеле и теми что снаружи транспортные как таковой не нужен совсем ибо всё что попадает в туннель с одной стороны однозначно отправляется в адрес «tunnel destination» :)

Один процесс, один транспорный порт, всё хорошо можно отлаживать. Можно tcpdump’ом проверять, что пришёл пакет — появился шифрованый пакет на внешнем интерфейсе.

Согласен что это удобно. Маленький минус в том что если операции по шифрованию/дешифрованию и т.п. проводятся в userspace то это хороший такой минус к производительности. При этом в том же wireguard можно различные интерфейсы вешать на разные порты, при том демона вообще нет - всё в ядре.

В общем, пока обкатываю wireguard в конфигурации для одного интерфеса только один peer, это позволяет писать AllowedIP (они же по сути traffice selector - 0/0), в общем то что и хотел ). А вопросы маршуртизации - какой трафик отправлять через какой туннель отправлять - не вопросы туннельного процесса, или статика или IGP прекрасно с этим справляются.

Вообще то что я сделал в wireguard один в один похоже на IPSec с трафик селекоторами 0/0 с обеих сторон и xfrm интерфейсами с той лишь разницей что в wireguard нормально всё восстанавливается если какие-то проблемы в транспортной сети между пирами.

Посмотрю. Раньше не слышал про такой, похоже на tinc. Спасибо.

при том демона вообще нет - всё в ядре.

Звучит странно. Когда-то давно был cipe. Тоже по udp, тоже в ядре, но демон был, просто чтобы занимать сокет. Чтобы не было проблем у остального софта, что udp-трафик есть, а в выводе netstat пусто.

А про маршрутизацию я писал без привязки к адресу. А в том плане, что если один процесс терминирует кучу тунелей и создаёт в системе кучу tun-интерфейсов, то он должен знать из какого tun в какой тунель шифровать пакет...

то это хороший такой минус к производительности.

Ну, если производительность так важна, стоило бы написать в стартовом посте. Просто обычно шифрованный тунель работает через интернет. Провайдер не даст такой поток тарфика, что нормальный сервер не осилит. Тем более если провайдер ОПСоС.

У вас wireguard во всех местах есть? А то потом окажется где-нибудь микротик со старой прошивкой...

Звучит странно. Когда-то давно был cipe. Тоже по udp, тоже в ядре, но демон был, просто чтобы занимать сокет. Чтобы не было проблем у остального софта, что udp-трафик есть, а в выводе netstat пусто.

51871 -это как раз wireguard, ntpd - для сравнения:

srv.home ~ # netstat -nupl | grep 51871
udp        0      0 0.0.0.0:51871           0.0.0.0:*                           -                   
udp6       0      0 :::51871                :::*                                -                   

srv.home ~ # netstat -nupl | grep ntp
udp        0      0 10.0.0.1:123            0.0.0.0:*                           3886/ntpd           
udp        0      0 192.168.5.1:123         0.0.0.0:*                           3886/ntpd 

может быть я не правильно смотрю конечно.

Ну, если производительность так важна, стоило бы написать в стартовом посте

Да нет, скорее перфекционизм :), ну и коробочки некоторые стоят под openwrt на недорогих роутерах (на гараже, на даче и т.п.). Это всё чистое частное велосипедостроение, но точек связанных около 7 штук :). Три центральных на ipsec в треугольник, остальные к двум из трёх центральных подключаются(сразу к обоим). Трафик - видео от камер (15Мбит/с), данные датчиков и события от них же (0.1 кбит/минуту). Раз подключение конечных узлов двумя линками - запустил OSPF.

У вас wireguard во всех местах есть? А то потом окажется где-нибудь микротик со старой прошивкой…

Если понравится - будет везде :).

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

Для меня странно, не то, что так сделано, понятно, что ядро может всё. И для nfs будет аналогичный вывод netstat.

Странно, зачем так сделано, когда уже 20 лет назад было простое решение с cipe — есть тунель, есть сокет, есть процесс. Вывод netstat связывает сокет с процессом, в командной строке процесса указан конфиг-файл с именем интерфейса. Убил процесс — тунель закрылся.

Удивился сегодня когда увидел что процесс charon у меня слушает и 500 и 4500 UDP порты, при этом ipsec обрабатывается в ядре без выхода в userspace благодаря чему нагрузка меньше, судя по схеме движения пакетов трафик до пользовательского процесса видимо и не доходит…

Если не загоняться по поводу оверхеда, то можно использовать openvpn в L2 режиме, как виртуальный коммутатор

спасибо, думал про это, пока остановился на чистом L3, спс за идею.

Глянь на https://ocserv.gitlab.io/www/index.html