Может поподробнее расскажешь, возможно есть и не такое решение?

Подробности:
Есть PPTP VPN соединение, реализуемое связкой pptp + pppd.
При созаднии подключения передаются опции, как драйверу pptp, так и демону pppd.
PPTP реализовывает псевдо канальный уровень, т.е. сам туннель в рамках tcp соединения, pppd в свою очередь реализовывает PPP соединение и всё, что его касается, в частности создаёт ppp{X} интерфейс, через который осуществляется взаимодействие с удалённым хостом.
После удачного подключения pppd вызывает команду /etc/ppp/ip-up, при этом передаёт ей в виде параметров IP адреса и некоторую другую информацию, касающуюся только что установленного соединения, а так же устанавливает переменные окружения для этой программы, в которых так же перечислены различные параметры подключения.

Так вот в качестве опции pppd можно указать linkname, что будет логическим именем соединения, которое так же привязано к номеру интефейса. Linkname можно использовать для дальнейшей идентификации соединения по каким либо признакам, к примеру назвав его vpn_out, в скриптах /etc/ppp/ip-up и /etc/ppp/ip-down (который запускается при разрыве соединения), можно определить, какого именно соединения это касатеся. Т.е. я использовал эту опцию для идентификации функции соединения. Linkname передаётся скрипту, как при подключении, так и при разрыве связи.

Хотелось бы найти соответствие названия соединения имени интерфейса в процессе его работы, к примеру для динамического изменения правил файервола. Как я понял, linkname - это внутренняя переменная pppd, возможности получть от него её значения я не нашел, пока...

Чуть позже обнаружил, что pppd создаёт pid файлы, один из которых называется ppp{X}.pid, а другой ppp-{linkname}.pid. В первом содержится собственно сам pid процесса pppd, а во втором имя ppp интерфейса и pid процесса его реализующего. В общих чертах это прямая возможность получить значение linkname для интересующего соединения, но несколько не устраивает надёжность подобного метода, дело в том, что при падениях (кои случаются) pppd не всегда удаляет свои старые pid-файлы, или даже если удаляет, то не сразу, а с некоторой задержкой (почему не понятно), что критично отражается на достоверности информации, полученной таким способом. Например, если после неожиданного разрыва ppp соединения с падением pppd попытаться поднять новое, то это может повлечь за собой подъём соединения на интерфейсе отличающемся от заданного опцией unit, а так же ложную реакцию на несуществующее соединение. Хм, а в прочем, кажется решение найдено, хотя я ещё над этим подумаю :-)
<span class='smallblacktext'>[ Редактирование 28.02.2007 - 08:29:42 ]</span>

> Linkname можно использовать для дальнейшей идентификации соединения по каким либо признакам..
это называется accounting, для этого надо юзать radius (собственно как и для всего aaa)

Под "идентификацией соединений" можно, конечно, рассматривать акаунтинг, в частном случае, но по моему не в этом.

2frug: не сомниваюсь, можно изобратать велик, можно патчить пппд, а можно использовать вещи по назначению. я думаю AAA не зря добрые сетевики придумали. и уж совсем "по-пацански" будет система, соотв. схеме: NAS (authent) -> RADIUS (account) -> LDAP (authoriz).. :)

А почему тебя не устраивает имя вроде pppX ? раздаются они по порядку, начиная с 0. Или ты планируешь несколько ppp-интерфейсов поднимать?

[b]Vitls[/b], в том то и дело, что на шлюзе поднимается несколько входящих и исходящих VPN соединений и нужно как то различать их хотя бы по направлению.

[b]sl1m[/b], RADIUS - Remote Authentication in [b]Dial-In[/b] User Service. А меня интересует так же и Dial-Up, конечно можно придумать что-нибудь с радиусом, но помоему получится нечто громоздкое и не вполне самодостаточное, в рамках этой задачи.

Нашел решение.
Плюс к тому, что описано выше pppd хранит информацию об активных соединениях в pppd[2].tdb файле в том же каталоге, где и pid файлы.
Название и формат файла pppd.tdb и pppd2.tdb отличается для разных версий pppd, в частности последний используется в pppd-2.4.3.

Для того, что бы получить информацию из этого файла, написал небольшой скрипт:

[blockquote]#!/usr/bin/perl

use TDB_File;

my $pid_path = "/var/run";
my $filename = "$pid_path/pppd2.tdb";
tie my %pppd_tdb, 'TDB_File', $filename, TDB_DEFAULT, O_RD or die "Can't open file $filename: $!\n";

my $param = $ARGV[0];
my $key = $pppd_tdb{$param};
my $value = $pppd_tdb{$key};

foreach $param ( split(/;/, $value) ) { print "$param\n" }

untie %pppd_tdb;
[/blockquote]
Успешно проверено на pppd-2.4.3, поскольку библиотека perl - TDB_File-0.5 отказалась работать с базами TDB версии ниже 6, а следовательно и с pppd < 2.4.3.
В качестве параметра скрипту нужно передать какой-нибудь из критериев, отличающий интересующее соединение, например:
[color=green]PPPD_PID=2234
LINKNAME=some_connection
IPREMOTE=ddd.ddd.ddd.ddd
IFNAME=pppX
DEVICE=/dev/pts/3[/color]
Например, что бы узнать информацию о соединении висящем на интерфейсе ppp0, говорим так:
[color=green]# pppd_info IFNAME=ppp0[/color]
Получаем в ответ нечто вроде:
[blockquote]ORIG_UID=0
PPPD_PID=12575
PPPLOGNAME=root
DEVICE=/dev/pts/1
LINKNAME=vpnout
SPEED=38400
IFNAME=ppp0
IPLOCAL=10.1.0.141
IPREMOTE=10.1.0.1
[/blockquote]
<span class='smallblacktext'>[ Редактирование 07.03.2007 - 11:00:18 ]</span>