Надо бы учесть ситуацию, описанную по ссылке: когда после поднятия PPP вследствие изменения маршрута по умолчанию VPN-сервер оказывается сам недостижимым с хоста и соединение разрывается по таймауту.
Поскольку на это напоролся один из наших клиентов -- по умолчанию занимаюсь я, но могут быть полезны другие мнения. Сейчас есть две не очень понятных вещи: как лучше оформить это в UI и куда лучше вписывать этот статический маршрут до vpn gw. UI пока делаю как доп. поле между Server и Login/Password: (document:id need-gw (checkbox "reachable via gateway" widget-name "need-gw")) (document:id vpn-gw (edit "" alterability #f widget-name "vpn-gw")) где значение по умолчанию будет, видимо, равно default gateway на заданный момент в системе (по-хорошему надо бы проверять, не доступен ли vpn gw через какой-либо из активных статических маршрутов, но я такое не готов изобразить -- да и тогда похоже на грамотного локального админа, которому эта кнопка не нужна). Маршрут предполагаю дорисовывать к конфигурации опорного интерфейса как "vpn.gw.ad.dr/32 via def.gw.ad.dr", хоть и не очень хочется лезть в настройки "чужого" интерфейса, настраивая "свой" -- но вроде как в etcnet не было возможности для ppp-интерфейсов условно поднимать свои статики, кроме разве что ip-up.d/ (что было бы орригинально :).
ipv4route в ifaces/pppXXX у меня вполне работало. Правда, маршрут до vpn-сервера я туда никогда не пробовал прописывать :)
Ну если я правильно вижу в examples от etcnet, то pptp server прописывается в файле options интерфейса. Так? Эх, все хотел написать документ Feel the power of etcnet :) Можно же всякое придумать. Например, в ipv4route в pppX: add $PPTP_SERVER via X.X.X.X 1. Будет добавлять при поднятии интерфейса и удаляться при опускании 2. Нужно подумать, что вставлять в X.X.X.X. Это самое сложное :) Нужно не опорный интерфейс выбирать, а адрес. А ядро само разберется, как туда роутить (т.к. в любой момент что-то может измениться) Если бы этот файл отрабатывался до поднятия pptp, то было бы проще, можно было бы грязный хак изобразить по вытаскиванию текущего (до подъема) def gw. Но их может быть много, в разных видах и т.п. Поэтому черт его знает, что туда писать. Можно, конечно, сделать опцию Gateway to VPN server и там просить ввести пользователя адрес, если действительно будет такая ситуация, как описана. Обычно там будет default gw, при его изменении придется и тут пользователю менять, а он забудет, как обычно. Но другого пути и нет, вроде как.
В плюшке "add static route to vpn gateway" можно сделать два варианта: - ручное указание пользователем гейтвея - автоматическое определение Вопрос в том, как должно работать это автоопределение: - прописывать default gw как сказал hiddenman - вычислять маршрут на основании таблицы маршрутизации В сложных конфигурациях роутинга оба варианта могут работать некорректно. С другой стороны, откуда у юзера возьмётся сложная маршрутизация?
(In reply to comment #4) > В плюшке "add static route to vpn gateway" можно сделать два варианта: > - ручное указание пользователем гейтвея > - автоматическое определение Именно это и предлагается. > Вопрос в том, как должно работать это автоопределение: > - прописывать default gw как сказал hiddenman Насчёт изменения -- было бы клёво сделать случай "auto", когда чуточку раньше поднятия pppd сохраняется текущий def gw и применяется здесь. Но это уже в светлом будущем, как понимаю :) > - вычислять маршрут на основании таблицы маршрутизации Собираюсь сделать первое, при возможности -- с оглядкой/доработкой по второму. > В сложных конфигурациях роутинга оба варианта могут работать некорректно. > С другой стороны, откуда у юзера возьмётся сложная маршрутизация? Так отож :)
(In reply to comment #2) > ipv4route в ifaces/pppXXX у меня вполне работало. Правда, маршрут до vpn-сервера > я туда никогда не пробовал прописывать :) А можешь прописать _неправильный_ и посмотреть, когда он подымается? :)
(In reply to comment #2) > ipv4route в ifaces/pppXXX у меня вполне работало. > Правда, маршрут до vpn-сервера я туда никогда не пробовал прописывать :) Докладываю: поднимает, но поздно. Надо поднимать до запуска pppd. Мужики, чо делать будем? Концептуально ровное поднятие статиков до/после интерфейса в etcnet или я какой костыль изобрету? :)
(In reply to comment #7) > (In reply to comment #2) > > ipv4route в ifaces/pppXXX у меня вполне работало. > > Правда, маршрут до vpn-сервера я туда никогда не пробовал прописывать :) > Докладываю: поднимает, но поздно. Надо поднимать до запуска pppd. > > Мужики, чо делать будем? Концептуально ровное поднятие статиков до/после > интерфейса в etcnet или я какой костыль изобрету? :) Ну существуют всякие ifup-pre-local, ifup-pre. Может быть изобрести подобное для всех остальных подсистем?
Проблема, например, в том, что интерфейс может не подняться, а роутинг мы изменили. И все, отваливание сети опять.
(In reply to comment #8) > Ну существуют всякие ifup-pre-local, ifup-pre. Может быть изобрести > подобное для всех остальных подсистем? Ну наверное моя хотелка -- это ipv4route-pre... собственно, /etc/net/ifaces/pppN/ifup-pre и помог -- вот такого вида: #!/bin/sh ip ro ad $MY_VPN_GW via $MY_USUAL_DEF_GW [или хотелка -- даже не файлик, а вообще галочка в options: "делать так, чтоб этот gw оставался доступен через текущий default route", только обзывать лучше без default -- вдруг вышеозвученное насчёт более интеллектуального выбора хоста, через который доберёмся, получится реализовать когда-нибудь?] (In reply to comment #9) > Проблема, например, в том, что интерфейс может не подняться, а роутинг мы > изменили. И все, отваливание сети опять. Так это, мы ж договорились /32 добавлять? Собственно, ровно так сейчас и экспериментирую -- до меня вдруг дошло, что тестовый стенд давно под рукой :)
> > Ну существуют всякие ifup-pre-local, ifup-pre. Может быть изобрести > > подобное для всех остальных подсистем? > Ну наверное моя хотелка -- это ipv4route-pre... собственно, > /etc/net/ifaces/pppN/ifup-pre и помог -- вот такого вида: > #!/bin/sh > ip ro ad $MY_VPN_GW via $MY_USUAL_DEF_GW > > [или хотелка -- даже не файлик, а вообще галочка в options: "делать так, чтоб > этот gw оставался доступен через текущий default route", только обзывать лучше > без default -- вдруг вышеозвученное насчёт более интеллектуального выбора хоста, > через который доберёмся, получится реализовать когда-нибудь?] > 1. Так что, ifup-pre достаточно? 2. Где ты берешь def gw все-таки? > (In reply to comment #9) > > Проблема, например, в том, что интерфейс может не подняться, а роутинг мы > > изменили. И все, отваливание сети опять. > Так это, мы ж договорились /32 добавлять? Собственно, ровно так сейчас и > экспериментирую -- до меня вдруг дошло, что тестовый стенд давно под рукой :) А, ну да. Я уже и забыл, что ты пытаешься вообще починить :-)
(In reply to comment #11) > > /etc/net/ifaces/pppN/ifup-pre и помог -- вот такого вида: > > #!/bin/sh > > ip ro ad $MY_VPN_GW via $MY_USUAL_DEF_GW > 1. Так что, ifup-pre достаточно? Для добавления -- да; забыл добавить, что удаляет потом /etc/net/ifaces/pppN/ifdown-post: #!/bin/sh ip route del $MY_VPN_GW via $MY_USUAL_DEF_GW > 2. Где ты берешь def gw все-таки? Эээ... прямщас -- ничего умного: /sbin/ip ro | awk '/^default via/ { print $3; exit; }' Подумал было, мож брать с ифейса, который $REQUIRES, но решил, что начинаю заморачиваться и не решу вообще ничего, выпрыгивая за самый распространённый случай... > > (In reply to comment #9) > > > Проблема, например, в том, что интерфейс может не подняться, > > > а роутинг мы изменили. И все, отваливание сети опять. > > Так это, мы ж договорились /32 добавлять? > А, ну да. Я уже и забыл, что ты пытаешься вообще починить :-) Описанное по $URL применительно к результату настройки $COMPONENT.
В первом приближении fixed in 0.5.0-alt1. (In reply to comment #12) > /sbin/ip ro | awk '/^default via/ { print $3; exit; }' Уже хочу, чтоб по возможности брало само по указанию в options. Ещё пришлось рисовать workaround для случая, когда pppd пускается поверх eth, который настраивается по dhcp: ifup ppp0 при указанном REQUIRES=eth0 без persist обламывается, поскольку pppd пытается стартовать до того, как на самом деле поднялся подлежащий интерфейс. Вышло такое (ifcheckup водится в alterator-net-common): # sleep order is on purpose: dhcp runs in background start_iface() { [ -n "$1" ] || return for i in `seq 1 $retries`; do ifcheckup "$1" && break ifup "$in_iface" sleep 1 done }
* Tue Jan 15 2008 Michael Shigorin <mike@altlinux> 0.5.0-alt1 - first strike at routing issues (#13966): this version will setup an additional static route to VPN gateway via current defult gw (not exactly ideal but this seems to be done properly in etcnet) - added onboot and persist controls (another part of #11988) - updated strings and translations - somewhat tested
