strongswan и все с ним связанное.
к нему есть api бинарное, на xml, и еще на каком-то гавне.
плюс он умеет делать ipsec вообще без ОС, полностью в userspace.

книги --- либо расширенный пересказ rfc, либо мануал по конкретной имплементации.

начните с википедии, тогда появятся более конкретные вопросы.

Попробую ответить.

Посоветуйте годные статьи/книги чтобы достаточно быстро вкатиться в IPSec с нуля.

Для linux это strongswan/openswan/libreswan (три разные реализации). Как правило, используют первое. Чтобы понять что к чему на своём десктопе/ноуте поднимите сервер, а на мобильнике (пусть будет андроид) клиента. По сути, это не одна технология, а их набор.

Т.е., разок настроите транспорт и поднимите сервер, уже многое станет понятно.

Основная идея в IPSec проста. Вам нужно построить туннель от (предположим) удалённого офиса до центрального поверх публичных сетей. Причём, таким образом, чтобы в построенной сети была внутренняя адресация (из набора адресов, указанных в RFC 1918, см. параграф 3, Private address space). Это если по-просту.

Но тут надо отметить что в IPSec нет как такового понятия «туннеля» в понятии «сетевого интерфейса». Тут есть «туннель» в понятии Security Assotiations (SA). SA это не сетевой интерфейс в его классическом понимании, здесь классическая маршрутизация не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Т.е., мы явно создаём и прописываем что-то типа ACL для пропуска трафика через определенную SA в определённом направлении. См. фреймворк ISAKMP для подробностей, там будут даны все необходимые определения.

Т.е., туннели могут быть как статическими так и динамическими, как угодно.

Например, у удалённого офиса будет «белый IP» типа 12.13.14.15, у центрального офиса «белый IP» будет 13.14.15.16, но внутри их сети будет, например, 192.168.1.х. И для клиентов их удалённого офиса доступ к внутренним ресурсам сети центрального офиса будет открыт точно так же, как если бы они сидели в центральном, за стенкой. Но вся работа строится для них прозрачным образом, через организованный админами туннель.

Если нужно по временам обращаться напрямую из сети другого удалённого офиса, например, мобильного, то можно получить на время динамический туннель, который будет существовать только во время обращения и потом уничтожаться и пересоздаваться заново. Конечно, если всё прописано грамотно.

Так же желательно получить какие-либо наводки на годные C/C++ библиотеки чтобы не пилить свой велосипед.

А их скорее всего нет. Не такого «единого API для IPSec». Это набор технологий, которые прозрачны для клиентского софта. Т.е., например, в центральном офисе есть веб-сервер (интернет-сервер) компании. Он достижим по https://some_domain.com, либо по IP (см. выше) 13.14.15.16. В то же время в центральном офисе есть интранет-сервер, к которому можно достучаться по 192.168.1.1, например. Физически это может быть один сервер, но ресурсы это разные, доступ к ним так же организован по-разному.

И клиентскому софту (тому же браузеру или cURL или некой самописной софтине) совершенно пофиг как именно. Главное, что в «таблице маршрутизации» пути прописаны, сервак достижим по адресам из внутренней сети, а уж как там пакеты шифруются, туннели строятся, приложению не важно. Если шифруются полностью, вместе с заголовком, то это туннельный режим, если только payload, без учёта заголовка IP то это транспортный режим, это не важно для конкретного приложения. Вся шифрация/дешифрация происходит прозрачно для приложения.

Именно поэтому нет так называемого «единого API для IPSec», следовательно и либ для его реализации тоже нет.

спасибо что разжевали! буду дальше копаться

Спрашивайте, если чего.

Помогу чем смогу.

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

Расскажите пожалуйста как бороться с NAT. Допустим, у нас есть мобильный клиент, мы ему организуем L2TP/IPSEC. Но я слышал что могут быть проблемы если из этой же сети понадобится еще одно подключение.

Два момента.

1 Борьба с NAT осуществляется при помощи NAT-T (NAT Traversal). ЕМНИП, где-то на хабре видел статью.

2

Но я слышал что могут быть проблемы если из этой же сети понадобится еще одно подключение.

Могут быть проблемы и да, понадобится второе подключение, если это два клиента из одной сети, но независимые друг от друга. Например, два мобильника. Они могут иметь один IP (одну точку выхода от ОпСоСа), но подключений будет два.

Если взять те же мобильники, включить их в единую (свою сеточку) по wi-fi, а потом уже эту сеточку зацепить с сетью центрального офиса, то одно.

UPD. Это... я не админ. Админские вопросы в чистом виде не очень. Извините. =)

============

Для ТС. Пока не забыл.

Я сказал что не существует «единого API» для IPSec. Как такового API да, нет. Но вот при необходимости есть возможность создавать свои пакеты посредством libnet. Либа старенькая, не без того, но там в структуры пакетов и механизмы их генерации и разбора мало что можно добавить. Тогда, если использовать libnet или решения на её основе, конечно можно поиграть с пакетами напрямую, но тогда весь трах с шифрацией/дешифрацией ляжет на Ваши плечи. libnet позволяет создавать пакеты определённой структуры, например, вот для IPSec:

#define LIBNET_IPSEC_ESP_HDR_H  0x0c    /**< IPSEC ESP header:    12 bytes */
#define LIBNET_IPSEC_ESP_FTR_H  0x02    /**< IPSEC ESP footer:     2 bytes */
#define LIBNET_IPSEC_AH_H 0x10 /**< IPSEC AH header:     16 bytes */

Взято из https://github.com/korczis/libnet/blob/master/include/libnet/libnet-headers.h

Но весь остальной трах... Как человек, заниавшийся этим вплотную, сразу скажу — да ну его на фиг, если в одиночку. Там сразу возникает масса вопросов и проект может ну очень долгим оказаться.

Как-то вот так, в общем.

Благодарствую на добром слове.

.

ещё раз спасибо! если вдруг появится конкретика - обязательно отпишусь :)

Лады.

Бог в помощь. =)

Писал недавно вот такую статью: https://habr.com/ru/post/518116/

Для linux это strongswan/openswan/libreswan (три разные реализации)

ipsec-tools && racoon ?

Устаревшее мертвое гавно, не умеющее в IKEv2 и AEAD. Как вообще может прийти в голову совет использовать ПО для безопасности, последний релиз которого был в 2008?

Даже сами авторы крупными буквами пишут что все сдохло и есть дыры: http://ipsec-tools.sourceforge.net/

Вот где-то в то время я с ним и работал. RH даже фиксы делали по запросу от нашей компании. Не знал, что уже всё.