Re: pppd по требованию (demand) при подключении к VPN (pptp)

В сообщении от 16 Февраль 2004 14:14 windmuff написал(a):
> Являясь абонентом локальной сети 192.168.114.0 (устройство eth0), из
> которой выход в Интернет осуществляется через микрософтовский VPN-сервер,
> настроил интерфейс ppp0 следующим образом:
> ----- BEGIN FILE "/etc/sysconfig/network-scripts/ifcfg-ppp0" -----
> NAME="vpn2inet"
> IPADDR=192.168.100.183
> BOOTPROTO=dialup
> PEERDNS=no
> ONBOOT=yes
> DEFROUTE=yes
> PPPOPTIONS="file /etc/ppp/peers/vpn2inet"
> PAPNAME="vpn00183"
> REMIP=192.168.100.254
> DEMAND=yes
> DEVICE=ppp0
> PROVIDER="lukinka"
> ----- END FILE "/etc/sysconfig/network-scripts/ifcfg-ppp0" -----
>
> ----- BEGIN FILE "/etc/ppp/peers/vpn2inet" -----
> name vpn00183
> pty "/usr/sbin/pptp 192.168.114.126 --nolaunchpppd"
> nobsdcomp
> nodeflate
> demand
> 192.168.100.183:192.168.100.254
> ipcp-accept-local
> ipcp-accept-remote
> idle 600
> connect /bin/true
> defaultroute
> ----- END FILE "/etc/ppp/peers/vpn2inet" -----
>
> После запуска службы network, как и требуется, образуется следующая
> маршрутизация:
> ----- BEGIN OUTPUTOF "/sbin/route -n" -----
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface 192.168.100.254 0.0.0.0         255.255.255.255 UH    0      0       
> 0 ppp0 192.168.114.0   0.0.0.0         255.255.255.128 U     0      0      
>  0 eth0 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0     
>   0 lo 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0      
>  0 ppp0 ----- END OUTPUTOF "/sbin/route -n" -----
>
> Затем наблюдается следующая особенность.
> При нахождении устройства ppp0 в холостом режиме (idle) при попытке
> соединения с каким-либо сервером вне сети 192.168.114.0, соединение
> перенаправляется на стандартный шлюз в местной сети,
> 192.168.114.126=gate.home, причём в случае соеднинения по HTTP (порт 80) в
> браузере вместо запроса
> http://remote.server/requeststring получаем http://gate.home/requeststring
>
> Если затем в течение 600 сек (значение idle в файле
> "/etc/ppp/peers/vpn2inet") снова запросить
> http://remote.server/requeststring или какой-либо любой другой сервер вне
> местной сети, то всё работает как следует.
>
> По идее, в случае обнаружения пакета, маршрутизированного в интерфейс ppp0,
> для которого установлен режим demand, pppd сначала должен установить
> соединение, и только потом посылать пакет в интерфейс, а не направлять его
> на стандартный шлюз в местной сети, который здесь совершенно ни при чём.
>
> Используется pptp из pptp-linux-1.3.1-1mdk (из дистрибутива Mandrake 9.2),
> причём обновление его до pptp-linux-1.4.0 с сайта
> http://pptpclient.sourceforge.net поведения не меняет, то есть дело здесь
> именно в pppd (используется версия 2.4.1 из дистрибутива Mandrake 9.2).
>
> Является ли это багом pppd, или необходимо внести дополнительные настройки?
Нет. Багом пппд это не является. Я не совсем разглядел в твоих описаниях такой
вопрос- а установлен-ли у тебя перед поднятием пппд в деман режиме шлюз по 
умолчанию?
Если да, то его надо убрать, и все будет работать как надо.
>
> Если это баг, то он весьма небезобидный, т. к. потенциально представляет
> дыру безопасности. Представим, что у кого-нибудь fetchmail периодически
> снимает почту с удалённого POP3-сервера. Если попытка соединения произойдёт
> в момент нахождения ppp-интерфейса в холостом состоянии, то, будучи
> перенаправленным на другой сервер, fetchmail либо получит ложное сообщение
> об отказе в соединении (если на том сервере закрыт POP3-порт), либо может
> сообщить не по назначению имя пользователя и пароль (если установлен
> POP3-сервер).
>
> Все эти проблемы устраняются, если убрать опцию demand. Но как раз в этой
> ситуации режим «по требованию» (demand) весьма актуален (и гораздо более
> практичен, чем при дозвоне по модему), поскольку процесс соединения с
> VPN-сервером занимает не более 2-5 секунд, а по ряду соображений соединение
> с VPN-сервером в локальной сети не хотелось бы держать открытым всё время
> при работе компьютера.
>
> С уважением,
> windmuff
>
> P. S.
> 1. Иногда соединение ppp0 включается после попытки соединиться с местным
> сервером, т. е., когда оно не нужно согласно таблицам маршрутизации.
> 2. При остановке службы network (как вручную, так и при отключении
> системы), сначала отключается eth0, а потом — ppp0 (который представляет
> собой тунель с сервером, подключённым через eth0). Отчего такое нарушение
> логики, почему не соблюдён принцип LIFO? Как сделать, чтобы сначала
> вызывалось ifdown ppp0, а затем — ifdown eth0?