Проблема с автоматическим подключением xl2tpd при загрузке

Беда такая: установил и настроил xl2tpd, но он никак не хочет подключаться при загрузке сервера (Debian 6). При этом, если после запуска сервера зайти под рутом и вручную дать команду xl2tpd restart - подключение появляется.

Пошарился в daemon.log. Ошибка: xl2tpd: Host name lookup failed for имя_впн_сервера
При этом лог аццки загажен воплями bind9 о том, что 'network unreachable'

Похоже, картина следующая: xl2tpd пытается подключиться к серверу и бросает это гиблое дело до того как поднимается WAN-интерфейс (отчет dhcp-клиента об успешном подключении в самом конце лога, после тонн сообщений об ошибках).

Покопался в интернетах, но грамотного красивого решения, которое бы меня во всем устраивало, мне не попалось.

Пробовал такой ход: в скриптах автозагрузки прописать зависимости ('Required-Start') таким образом, чтобы xl2tpd и bind9 запускались после isc-dhcp-server. Не помогло. Запускается-то он первым, а вот получить IP и прочее не успевает.

Была еще мысль убрать 'autodial = yes' в xl2tpd.conf, а в '/etc/network/if-up.d' поместить скрипт, который будет проверять имя поднятого интерфейса и, если это WAN, устанавливать соединение по требованию через '/var/run/xl2tpd/l2tp-control'... Но такой вариант меня не устраивает: интернет будет подниматься при каждом подключении к WAN, а мне такого не надо. Требуется соединение именно после загрузки сервера. (Т.е. может получиться ситуация, когда мне нужен подключенный WAN и запущенный xl2tpd демон, но отрубленный инет). Да и проблемы с засиранием логов bind'ом это не решает.

Единственное, что приходит в голову - это убрать их вообще из автозагрузки и смастЫрть в автозапуске скрипт, который будет запускать bind9 и xl2tpd (или дозвон делать, что гораздо лучше) либо по таймауту, либо после подъема WAN... Но это какой-то кривой костыльный подход, как мне кажется. По крайней мере, в той реализации, которую я могу себе представить.

Подскажите хорошее решение, пожалуйста.

Спасибо!

Может быть, кто-нибудь посоветует как правильно добавить в автозагрузку скрипт, который будет запускаться последним (Required-Start: $all, как я понимаю) с 10-исекундным таймаутом и при этом не будет на 10 секунд завешивать загрузку?

По идее, его нужно запускать в фоне, а первой командой ставить на паузу на нужное время? То есть это будет не демон даже, а скрипт с отложенным запуском. Но несмотря на это, в нем все равно надо будет описывать секции start, stop, restart?

Еще немного подумал: ведь возможна ситуация, когда WAN будет падать в результате сбоя (у прова бывает такое иногда). И как раз тогда надо устанавливать соединение с L2TP сервером именно после подъема WAN-интерфейса для полного восстановления связи (то есть как описано в первом посте). Вопрос в том как сделать так, чтобы автоподключения не происходило, если я явно отрубаю инет вручную. Написать скрипт соединения/отключения с L2TP сервером, который будет хранить флаг состояния во временном файле? А в скрипте автоподключения /etc/network/if-up.d/script проверять этот флаг?

Все-таки пошел по пути подключения к VPN через скрипт из '/etc/network/if-up.d'. Вот что получилось:

/etc/network/if-up.d/inet-autostart:

#!/bin/bash
if [ "$IFACE" = "eth0" ] && ! [ -f /var/tmp/l2tp-inet-staydown ]; then
        /usr/local/bin/make-log-entry.bash -n inet-autostarter \
                -m "WAN interface ($IFACE) is up. Delayed launching connection daemon..."
        /usr/local/bin/l2tp-inet.bash start &
fi

При подъеме WAN интерфейса, запускаем в фоне скрипт, подключающийся к L2TP...

А вот и он...
/usr/local/bin/l2tp-inet.bash:

#!/bin/bash
DELAY=8
# Functions:
wrong_usage() {
        ERR_MSG="Wrong usage! $1 Use: l2tp-inet start | stop"
        echo "$ERR_MSG" >&2
        /usr/local/bin/make-log-entry.bash -n l2tp-inet -m "$ERR_MSG"
        exit 1
}
/usr/local/bin/make-log-entry.bash -n l2tp-inet -m "Internet connection daemon started..."
# Initialize options:
if [ $# -ne 1 ]; then
        wrong_usage "$# parameters given."
fi
case "$1" in
        start )
                ACTION="START"
                ;;
        stop )
                ACTION="STOP"
                ;;
        * )
                wrong_usage "Unknown parameter: $1."
                ;;
 esac
/usr/local/bin/make-log-entry.bash -n l2tp-inet -m "Daemon action chosen: $ACTION"
# Choosing action:
if [ "$ACTION" = "START" ]; then
        /usr/local/bin/make-log-entry.bash -n l2tp-inet -m "Internet connection scheduled, connecting in $DELAY secodns"
        sleep $DELAY
        /usr/local/bin/make-log-entry.bash -n l2tp-inet -m "Connecting to internet L2TP server..."
        echo "c kmsnet-l2tp" > /var/run/xl2tpd/l2tp-control
elif [ "$ACTION" = "STOP" ]; then
        sleep 1
        /usr/local/bin/make-log-entry.bash -n l2tp-inet -m "Disconnectiong from internet L2TP server..."
        echo "d kmsnet-l2tp" > /var/run/xl2tpd/l2tp-control
fi
exit 0

Тут, вроде, тоже все просто: если передан параметр "START", то подключаемся, если "STOP", то наоборот.

Также для удобства соорудил ламерский костыль, скидывающий отчеты в daemon.log и syslog, ибо в силу нехватки опыта не знаю, как это делают умные дяденьки... (кстати, мож кто чего присоветует?)
/usr/local/bin/make-log-entry.bash:

#!/bin/bash
wrong_usage() {
        echo "Wrong usage! $1" >&2
        exit 1
}
# No parameters given:
if [ $# -eq 0 ]; then wrong_usage "No parameters given"; fi
GETOPT=`getopt -o n:m: --long name:,message: -n 'make-log-entry.bash' -- "$@"`
# Incorrect parameters given:
if [ $? != 0 ]; then wrong_usage "Getopt error"; fi
eval set -- "$GETOPT"
# Initialize options:
while true ; do
        case "$1" in
                -n | --name )
                        NAME="$2"
                        shift 2
                        ;;
                -m | --message )
                        MESSAGE="$2"
                        shift 2
                        ;;
                -- )
                        shift
                        break
                        ;;
                * )
                        wrong_usage "Unexpected parameters: $@"
                        exit 1
                        ;;
        esac
done
# Make log entry:
TIME=$( date +"%a %d %H:%M:%S" )
HOST_NAME=$( hostname )
ENTRY="$TIME $HOST_NAME $NAME: $MESSAGE"
echo "$ENTRY" | tee -a /var/log/daemon.log /var/log/syslog > /dev/null
if [ $? != 0 ]; then
        echo "Could not access log files!"
        exit 1
fi
exit 0

И все забегало. )

В разделе "STOP" пока нет кода, создающего флаговый файл, но это совсем элементарно. Плюс прописать алиасы, и будет совсем удобно.

Спасибо всем отозвавшимся! :D

Теперь осталось решить вопрос с bind9... :(

Зачем делать костыли. Ответ вы написали сами

Пошарился в daemon.log. Ошибка: xl2tpd: Host name lookup failed for имя_впн_сервера

Надо проверять что у вас указанно в днс. Либо за место имени использовать ip.

Kettler написал:

Зачем делать костыли. Ответ вы написали сами

text

Пошарился в daemon.log. Ошибка: xl2tpd: Host name lookup failed for имя_впн_сервера

Надо проверять что у вас указанно в днс. Либо за место имени использовать ip.

100% проблема в том, что кеширующий DNS сервер и xl2tpd запускаются и "начинают действовать" до того, как DHCP-клиент получает все необходимые данные от прова (даже в логах видно, что все ошибки прекращаются после того как происходит подъем интерфейса по DHCP). То есть, к прову по WAN еще не подключились, а уже пытаемся достучаться до его ДНС и ВПН.

Да и заработало все в том виде, что я выше изложил.

Спасибо за ответ!

Liber написал:

[quote=Kettler]Зачем делать костыли. Ответ вы написали сами

text

Пошарился в daemon.log. Ошибка: xl2tpd: Host name lookup failed for имя_впн_сервера

Надо проверять что у вас указанно в днс. Либо за место имени использовать ip.

100% проблема в том, что кеширующий DNS сервер и xl2tpd запускаются и "начинают действовать" до того, как DHCP-клиент получает все необходимые данные от прова (даже в логах видно, что все ошибки прекращаются после того как происходит подъем интерфейса по DHCP). То есть, к прову по WAN еще не подключились, а уже пытаемся достучаться до его ДНС и ВПН.

Да и заработало все в том виде, что я выше изложил.

Спасибо за ответ![/quote]
Ну раз так то надо в конфигах xl2tp указать скок раз пытаться подключиться.

Но вот сейчас ума не приложу, что делать с ДНС-сервером на маршрутизаторе. Отложенный запуск организовать будет всяко сложнее, и мутронее, и костыльнее, чем отложенное подключение к L2TP. А обилие сообщений об ошибках в логах мне совсем не нравится. Не дело это...

> Ну раз так то надо в конфигах xl2tp указать скок раз пытаться подключиться.
Самое странное, что вроде все выставлено в 0 (то есть, стучаться бесконечно). Вечером (по Москве) выложу конфиги подключения, может чего присоветуете.

Liber написал:

Но вот сейчас ума не приложу, что делать с ДНС-сервером на маршрутизаторе. Отложенный запуск организовать будет всяко сложнее, и мутронее, и костыльнее, чем отложенное подключение к L2TP. А обилие сообщений об ошибках в логах мне совсем не нравится. Не дело это...

1) отключить логирование bind.
2) запускать bind после поднятия l2tp

3) Пошариться тут и понять что можно всё запускать после поднятия сетевого интерфейса wan

> Зачем делать костыли. Ответ вы написали сами
> Ну раз так то надо в конфигах xl2tp указать скок раз пытаться подключиться.

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

Kettler написал:

3) Пошариться тут и понять что можно всё запускать после поднятия сетевого интерфейса wan

С xl2tpd вроде так и сделал... Хотя мож криво. Погляжу, спасибо!

Всё ниже ток как пример для понимания.

update-rc.d remove bind9
update-rc.d remove xl2tpd

auto eth0
iface eth0 inet dhcp
post-up /etc/init.d/xl2tpd start
post-up /etc/init.d/bind9 start

"Kettler" написал:

Всё ниже ток как пример для понимания.

Понятно! Спасибо огромное!
Думаю, большой беды не будет, если я все-таки помещу эти скрипты в /etc/network/if-up.d/?

Потому как приходится все-таки по таймауту эти скрипты запускать. Если без него - подключается через раз (xl2tpd ругается на то, что не может найти туннель). А с 5-8секундной задержкой "заводится" стабильно.

И еще вопрос, если я уберу эти демоны из автозагрузки, это "исталяционные" конфиги aptitude не сильно собьет? Т.е., к примеру, стану я эти пакеты деинсталить - на фазе их удаления из автозапуска ведь явно ошибка произойдет. Хотя, похоже, и не смертельная... Или лучше все-таки это дело лучше как-то переконфигурировать?

не чего страшнего.

"Kettler" написал:

Всё ниже ток как пример для понимания.

Feb 19 15:43:23 debsrv inet-autostarter: WAN interface (eth0) is up. Delayed launching L2TP connection manager...
Feb 19 15:43:23 debsrv l2tp-inet: L2TP connection manager started...
Feb 19 15:43:23 debsrv l2tp-inet: Internet connection scheduled, connecting in 10 seconds
Feb 19 15:43:33 debsrv l2tp-inet: Connecting to internet L2TP server...
Feb 19 15:43:35 debsrv xl2tpd[1183]: Connecting to host ***, port 1701
Feb 19 15:43:35 debsrv xl2tpd[1183]: handle_avps:  don't know how to handle atribute 46.
Feb 19 15:43:35 debsrv xl2tpd[1183]: Connection established to ***.  Local: ***, Remote: *** (ref=0/0).
Feb 19 15:43:35 debsrv xl2tpd[1183]: Calling on tunnel 57527
Feb 19 15:43:36 debsrv xl2tpd[1183]: Call established with ***, Local: ***, Remote: ***, Serial: 1 (ref=0/0)
Feb 19 15:43:36 debsrv xl2tpd[1183]: start_pppd: I'm running:
Feb 19 15:43:36 debsrv xl2tpd[1183]: "/usr/sbin/pppd"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "passive"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "nodetach"
Feb 19 15:43:36 debsrv xl2tpd[1183]: ":"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "name"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "***"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "debug"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "file"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "/etc/ppp/***"
Feb 19 15:43:36 debsrv xl2tpd[1183]: "/dev/pts/0"
Feb 19 15:43:39 debsrv xl2tpd[1183]: handle_avps:  don't know how to handle atribute 46.
Feb 19 15:43:39 debsrv xl2tpd[1183]: control_finish: Connection closed to ***, serial 1 (Authentication failure)

Правда на этот раз xl2tpd продолжает "долбиться" и делать дозвоны каждые 5-10 секунд. И где-то в течение как раз минуты VPN-сервер отказывает в авторизации. А потом пущает.

Мне сразу вспомнилась похожая ситуация с десктопом под управлением WinXP. Если некорректно отключиться от сети. Например, отключить ethernet-интерфейс, не отключившись предварительно от L2TP. После этого VPN-сервер несколько минут не пускает, ругаясь на логин/пароль.

Пришла в голову мысль, что по команде reboot xl2tpd не завершает корректно соединение (или не успевает этого сделать). Решил это проверить таким образом: выключил сервак на 5 минут. Потом включил. Смотрю в логах - точно! L2TP завелся с ходу.

Попытался решить проблему так:
в /etc/network/if-down.d/ добавил скрипт, отключающий L2TP подключение и ожидающий 3 секунды перед отключением WAN-интерфейса. Не помогло. Смотрю лог:

# Сперва идет вот эта запись:
Feb 19 15:42:47 debsrv xl2tpd[1206]: death_handler: Fatal signal 15 received
# А уже намного позже отрабатывает скрипт отключения L2TP:
Feb 19 15:42:49 debsrv inet-autostarter: WAN interface (eth0) is going down. Launching L2TP connection manager to interrupt internet connection...
Feb 19 15:42:49 debsrv l2tp-inet: L2TP connection manager started...
Feb 19 15:42:49 debsrv l2tp-inet: Disconnecting from internet L2TP server...

То есть, xl2tpd останавливается ДО того, как отработает отключающий скрипт. Причем останавливается, видимо, не совсем корректно, не разрывая активные соединения.

Сейчас читаю мануалы по xl2tpd (может, можно как-то изменить его поведение в этом плане). Но может быть, кто-нибудь сталкивался с подобным и знает решение? Или просто кому в голову придет что умное... Потому как если xl2tpd корректного завершения по death-handler'у не предусматривает, то я даже и не знаю, как быть.

Конечно, я понимаю, что это в целом не бог весть какой косячок... Но уж если налаживать, так налаживать, верно? :)

"Liber" написал:

Заметил, что L2TP соединение как-то слишком долго устанавливается после перезагрузки сервера (до одной минуты).

Ура! Вопрос решен. Пришлось слегка модифицировать /etc/init.d/xl2tpd - секции 'stop' и 'restart' (добавил вызовы скрипта, корректно завершающего VPN-сессии, перед остановом службы).

Теперь все заводится без глюков и быстро! *YAHOO*

Осталось бинд победить...