ppp0 не использовать

[J.Korvin]

Настроил связ PPTPD + abills + freeradius + mysql. Интернет беру с ppp0 интерфейса пользователи которые подключаются к моему VPN серверу получают IP адрес и соответственно на сервере появляется интерфейс ppp1 потм оppp2 и так дальше, ну бывают случаи когда мой ppp0 (интерфейс инету)падает и в тоже время пользователь подключится и занимает ppp0 соответственно инет подымается на на там интерфейсе что нужно. Вопрос возможно как то запретить серверу выдавать интерфейс ppp0 для пользователей VPN. Сервера pptp и pppoe система debian.

[tvremtoh]

Странно конечно , абилс работает только с пптп вроде как , наверное надо подкопнуть впн сервер

[tvremtoh]

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

[J.Korvin]

не в abills дело а в VPN он выдает интерфейсы все подряд а нужно чтобы с ppp1-10

[tvremtoh]

Так я не понял клиенты используют pptp или ppoe ? У меня клиенты используют пптп без шифрования до 200 тунелей прокатывает , ппое полегче но мне с пптп удобней и такого трабла никогда не происходит ппое у меня поднимает сам микротик для внешнего адсл подключения .

[skor]

tvremtoh, прочитай внимательно первое сообщение в топике.

[tvremtoh]

Может это поможет http://www.lissyara.su/?id=1258 а вообще какой демон пптп для впн пользуем ?

[tvremtoh]

http://www.bgp4.ru/wrapper.php?p=51

[skor]

J.Korvin, как вариант можно для плагина radius указать опцию map-to-ifname и если в RADIUS-сервер пршел NAS-Port = 0 то посылать нафиг. Соответсвенно ppp0 не будет занят абонентом.
Еще может попробовать для интернет соединения указать persist и пусть ppp никогда не падает...

Может это поможет http://www.lissyara.su/?id=1258 а вообще какой демон пптп для впн пользуем ?

Сервера pptp и pppoe система debian.

[sash-kan]

как вариант можно для плагина radius указать опцию map-to-ifname и если в RADIUS-сервер пршел NAS-Port = 0 то посылать нафиг. Соответсвенно ppp0 не будет занят абонентом.

ммм. а если интерфейс ppp0 так и не будет занят? клиенты не смогут подключиться. если только толпой одновременно не ломанутся. ядро-то ведь будет подсовывать первое свободное имя. т.е., ppp0.

возможно, имеет смысл как-то дифференцировать исходящее ppp-соединение и средствами udev просто давать другое имя, взамен pppN. pptpN или что угодно другое.
посмотрите вывод
$ udevinfo -a -p /sys/class/net/<интерфейс>/
для ppp0 и других pppN. если найдется какое-то устойчивое отличие между первым и остальными, на нем можно построить правило udev.

[skor]

ммм. а если интерфейс ppp0 так и не будет занят? клиенты не смогут подключиться. если только толпой одновременно не ломанутся. ядро-то ведь будет подсовывать первое свободное имя. т.е., ppp0.

А толку что они подключаться? Нет ppp0 - нет интернета - все в сад!
С другой стороны можно не привязываться к ppp0 а немного поизвращаться с ip-up/down скриптами.
К примеру у нас подымается интерфейс "в интернет" в опциях этого подключения указываем linkname inet. В скриптах смотрим переменную окружения LINKNAME и соответсвенно реагируем и пишем правила iptables (или чего там надо). А имя интерфейса заносим в файл (к примеру /var/run/ppp-inet), на будущее если надо будет сослаться на этот интерфейс.

[sash-kan]

Нет ppp0 - нет интернета - все в сад!

а кто сказал, что интернета нет? может быть, есть резервный канал? и кто сказал, что клиенты используют pptp-туннель лишь для интернет-трафика?

А имя интерфейса заносим в файл (к примеру /var/run/ppp-inet), на будущее если надо будет сослаться на этот интерфейс.

угу. и при каждом подъёме этого интерфейса будем перезаливать правила netfilter-а и tc.

[sash-kan]

J.Korvin
поэкспериментируйте еще с опцией unit (man pppd). задав для исходящего соединения заведомо большое число.
я сам такой вариант не опробовал. но подводных камней умозрительно не наблюдаю.
по крайней мере получите стабильность имени интерфейса.

[skor]

угу. и при каждом подъёме этого интерфейса будем перезаливать правила netfilter-а и tc.

А что плохого в том чтоб добавлять/удалять правила для данного интерфейса? Или вы собрались все правила перезаливать?
А с unit ничего не получится, если требуемый номер интерфейса занят оно пытается искать номер с самого начала (судя по коду).

[sash-kan]

А с unit ничего не получится, если требуемый номер интерфейса занят оно пытается искать номер с самого начала (судя по коду).

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

[skor]

Хммм... Про счет с "обратной" стороны я не подумал...