Push route to l2tp-server

через dhcp сервер. я делаю через dnsmasq на сервере.

dhcp-option=121

Хочется сделать так что-бы клиент при соединении с сервером сообщал серверу свою подсеть

Без костылей невозможно. Готовых костылей не встречал, но возможно они существуют.

Но вот это немного смутило

1. Настроить на сервере что при подключении определенного пользователя по L2TP тот добавлял путь до его подсети.

У вас подсеть клиента известна заранее?

я делаю через dnsmasq на сервере.

Это от сервера клиенту, а ТС надо наоборот от клиента серверу

То что без костылей похоже не получится это я уже понял.
Хотелось бы просто обычного человека на костылях, а не гексапод из костылей.

И да подсеть клиента известна заранее, это слегка облегчает задачу.
Но не делает ее элементарной для применения статической маршрутизации.

Здесь два подводных камня, при условии что я не туплю:

1. Это если прописать route ручками на сервере он пропадет если пропадет входящее клиентское соединение. Собственно как не появится если засунуть в крон при загрузки если клиент еще не совершил соединение.

2. Клиент может получать разный IP из пула при подключении в следствии чего и gateway для подсети будет разным. Хотя этот пункт можно обойти, так как в теории я могу сделать так что-бы каждый пользователь получал конкретный IP.

И да подсеть клиента известна заранее, это слегка облегчает задачу.

Это решает задачу.
man pppd
Вас интересует ip-up script

Я был в курсе про ip-up, но меня смущало что я не могу в рамках скрипта определить какой именно пользователь соединяется.

Еще раз перечитав и поискав примеры, я так и не понял могу ли я сделать скрипт аля - Если поднимается входящее соединения от пользователя «забияка» то прокидывай такую-то подсеть через его IP.

Но если закрепить за каждым пользователем свой IP то точно могу.

В сязи с чем не могу не спросить есть ли способ детерминировать от какого пользователя пришло соединение?

В сязи с чем не могу не спросить есть ли способ детерминировать от какого пользователя пришло соединение?

Можно.

Если поднимается входящее соединения от пользователя «забияка»

Переменная ${PEERNAME}

PS
адреса, интерфейс также в переменных: IPLOCAL IPREMOTE IFNAME

man pppd
Вас интересует ip-up script

Хм, а разве ip-up и прочие скрипты и переменные не являются частью именно pppd? В данной теме речь-то об ipsec идет, разве к этому типу туннеля это применимо?

Хм, а разве ip-up и прочие скрипты и переменные не являются частью именно pppd?

Все верно.

В данной теме речь-то об ipsec идет

Несовсем. Речь об ipsec+l2tp т.е. нас интересует только вторая часть, ipsec тут уже «совсем не при делах», его дело «доставка» :)

Речь об ipsec+l2tp т.е. нас интересует только вторая часть, ipsec тут уже «совсем не при делах», его дело «доставка» :)

Тогда я вообще не понимаю, зачем он (ipsec) тут нужен - pppd и напрямую отлично будет работать (pptp)...

В смысли зачем?

Как и любая другая вещь со своим предназначением, для применения по назначению. Для безопасности доставки.

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

pptp

Дыра на дыре и дырой погоняет?

Тогда я вообще не понимаю, зачем он (ipsec) тут нужен

ipsec поднимаем в транспортном режиме, т.е. можем через него гнать «что-то», а вот этот «что-то» уже на наш выбор, хоть nc пользуй.
На пальцах. Первое установить соединение ipsec. Второе установить «то что мы придумали». Это по факту «два разных человека», оно не решается «одной командой» «сделай мне хорошо».
Надеюсь пояснил понятно.

Ну что я могу сказать, спасибо.

Все работает в лучшем виде.

ipsec поднимаем в транспортном режиме, т.е. можем через него гнать «что-то», а вот этот «что-то» уже на наш выбор, хоть nc пользуй.

Идею я понял. Не понял, зачем это нужно. Ведь по сути получается, что мы кидаем туннель (nc, pppd, etc) поверх туннеля (ipsec). Какие задачи «нижний» туннель (ipsec) решает, которые нельзя решить средствами nc или pppd напрямую? Шифрование трафика? Так это можно и в nc реализовать, и в pppd.

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

Дыра на дыре и дырой погоняет?

Вроде все известные дыры закрыты? Или нет?

В смысли зачем?

В прямом смысле. Всю ту же функциональность можно обеспечить без ipsec. А основное преимущество - скорость и низкая ресурсоемкость данного вида туннелей (ipsec) в Вашем случае все равно пропадает зря, т. к. все упирается в производительность туннеля верхнего уровня (pppd).

Всегда считал, что любая создаваемая система должна подчиняться правилу лезвия Оккама

А еще есть принцип KISS
Выше ТС правильно написал

Как и любая другая вещь со своим предназначением, для применения по назначению.

Шифрование трафика? Так это можно и в nc реализовать

Конечно можно, и еще много чего можно написать с нуля. Но вот вопрос: зачем?
Я вот когда был мелким, начал с программирования, и как многие свой архиватор писал... результаты компрессии просто поразили меня, эйфория была ровно до момента написания «разархиватора»... надеюсь аналогия понятна?

Вроде все известные дыры закрыты? Или нет?

«Зарыты» так правильнее будет. Даже «родитель» его уже похоронил со словами «что с мальчиком? что с мальчиком? Да говно с мальчиком, нового делать будем»

Я бы с удовольствием вступил с вами в полемику на тему производительности pptp против l2tp. Но я не могу так как аргументов в этом вопросе у меня нет. Ни бенчмарков ни граффиков.

Но у меня сей выбор был продиктован банально тем что одним из клиентов подключаемых к этому серверу является ненавистный мною iphone 8. И в нем тупо нет ничего кроме l2tp, ikev2, ipsec. Вот как-бы и весь выбор.

А плодить кучу разных туннельных серверов, что-то не хочется.

П.С.
Разве что таки думаю переделать все на ikev2\ipsec, такая связка в современных реалиях тоже достаточно универсальна.

Нет. Читайте мой ответ выше, каждый занимается своей задачей.
ЗЫ Но отчасти вы правы, «ресурсоемкость». Только вот что «ресурсоемкость» по вашему мнению?

А еще есть принцип KISS

Что-то я торможу сегодня, видимо, спать пора ;). Но при чем тут KISS? Неужели Вы считаете один туннель поверх другого более простым решением, чем одиночный туннель?

Конечно можно, и еще много чего можно написать с нуля. Но вот вопрос: зачем?

Ok. Давайте посмотрим на проблему с другой стороны - зачем тут ipsec? Исключительно для шифрования трафика? Или есть еще какая-то функция? Ну и pppd сверху - только ради маршрутизации?

Если сравнить эту систему с одиночными туннелями (можно взять ssh, тот же openvpn, если pptp не нравится) - какие будут плюсы у двойного туннелирования?

ну и по поводу маршртизации - нежели задача не решается более изящно, чем наложение двух туннелей - через правила udev, например (скрипт, активирующийся при появлении ipsec-интерфейса, и устанавливающий нужные маршруты)? Я фантазирую, потому что сам так не игрался с ipsec, но просто конструкция с двумя туннелями, IMHO, неуклюже выглядит...

Только вот что «ресурсоемкость» по вашему мнению?

Нагрузка на железо. Чем ниже нагрузка, тем ниже ресурсоемкость.

Все, спасибо, разобрался. Двух туннелей нет, я забыл, что ipsec может в транспортном режиме работать, без туннелирования :(.

Но у меня сей выбор был продиктован банально тем что одним из клиентов подключаемых к этому серверу является ненавистный мною iphone 8. И в нем тупо нет ничего кроме l2tp, ikev2, ipsec. Вот как-бы и весь выбор.

Эм.. простите, чистый ipsec там робит и без l2tp.

А плодить кучу разных туннельных серверов, что-то не хочется.

Так у вас и так их два ipsec и xl2tp. А вот варианты для разных устройств это только ваше дело, кол-во серверов не меняется.

И
ЗЫ Для iOS предпочитаю ovpn, а то родные «гуево» работают, не пересоединяются автоматом. Был период когда работал onDemand, но потом ябло не нашло общего языка с киской и выпилили.
А ovpn, как бы его не ругали за однопоточноть и т.д., в части автоматического пересоединения работает весьма кошерно (не всегда, но чаще срабатывает).

Все, спасибо, разобрался. Двух туннелей нет, я забыл, что ipsec может в транспортном режиме работать, без туннелирования

Точно разобрались? Потому что ipsec как раз и поднимает туннель. Пример что бы было понятнее. Дано:
Сервер с ip 1.1.1.1, на этом сервере поднят апач на 80-ом порту.
Клиент с ip 2.2.2.2
Если на клиенте выполнить nc 1.1.1.1 80 то данные полетят напрямую в открытом виде.
Теперь поднимаем ipsec тунель(transport) между сервером и клиентом. Выполняем туже команду nc 1.1.1.1 80 и опаньки, данные полетели через тунель.
Вот и с ipsec+l2tp все тоже самое.
Так что вы все правильно написали.

Давайте посмотрим на проблему с другой стороны - зачем тут ipsec? Исключительно для шифрования трафика?

Да. +установка туннеля + авторизация часть первая(для всех, это упрощенно на примере psk)

Ну и pppd сверху - только ради маршрутизации?

Да. + авторизация часть вторая(пользователя)

Вернемся к

«ресурсоемкость»

Насколько больше нагрузка в данном «бутерброде» ? Со стороны камня, большую часть покушает ipsec на шифровании. Памяти покушаем больше. Но если мы запускаем сервер не на «калькуляторе», то соответственно и планируем ресурсы.

Выполняем туже команду nc 1.1.1.1 80 и опаньки, данные полетели через тунель.

Насколько я понимаю, Вы не совсем правы. В описанной Вами ситуации идет шифрование только данных в IP-пакете, заголовок сохраняется неизменным. И соответственно, пакет маршрутизируется точно так же, как и в отсутствие ipsec, о туннеле говорить не приходится. Это так называемый транспортный режим ipsec.

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

Собственно говоря, насколько я понимаю, это и является определяющим признаком туннеля - инкапсуляция пакетов. Пока ее нет, говорить о туннеле бессмысленно.

Применительно к проблеме автора темы собственно туннель (инкапсуляция пакетов и маршрутизация) осуществляется средствами pppd. А ipsec используется для шифрования данных в пакетах. Т. е. нет двойной инкапсуляции, как мне сперва показалось.

Ну если начитать «от печки» то, «туннель» вообще не подразумевает под собой «шифрование». Например MPLS vpn тоже вносит «немного» изменений в пакете. Да собственно о чем это я, тот же тегированный vlan. Но ведь мы не об этом?

В описанной Вами ситуации идет шифрование только данных в IP-пакете, заголовок сохраняется неизменным. И соответственно, пакет маршрутизируется точно так же, как и в отсутствие ipsec, о туннеле говорить не приходится.

Вас смущает инкапсуляция протоколов? Выше я вам дважды намекнул на nc, который «сам по себе»(без оберток) использует только «чистый текст» при «общении».

Ну если начитать «от печки» то, «туннель» вообще не подразумевает под собой «шифрование».

Разумеется.

Выше я вам дважды намекнул на nc, который «сам по себе»(без оберток) использует только «чистый текст» при «общении».

Ну, если использовать nc для организации туннеля, то он сам будет «оберткой» для данных, которые ему будут поставляться.

Просто при такой широкой трактовке само понятие туннеля расплывается - в предельном случае туннелем можно будет назвать любое tcp-соединение (да и udp тоже). Но ведь мы сейчас не об этом говорим?

Ели же говорить о туннеле в узком смысле, то, IMHO, ключевую роль играет изменение заголовка IP-пакета. В этом смысле тот же NAT можно рассматривать как туннель.

Возвращаясь к ipsec, здесь эти две функции (шифрование и туннелирование (в смысле изменения заголовка IP-паветов)) разнесены. Что и позволяет использовать его вместе с другими туннелями исключительно для шифрования, без двойной инкапсуляции пакетов...

Предлагаю на этом и остановиться, все правы. Обсуждать такую интересную тему можно действительно долго. Но такими темпами мы с вами настолько далеко уйдем от темы ТС... :)