Bug 11016 - не восстанавливает default route
: не восстанавливает default route
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/openvpn)
: unstable
: all Linux
: P2 critical
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2007-03-05 15:08 by
Modified: 2007-03-09 18:39 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-03-05 15:08:23
пусть таблица маршрутизации выглядит так:
192.168.5.0/24 dev eth0  proto kernel  scope link  src 192.168.5.10
default via 192.168.5.201 dev eth0

после поднятия туннеля на 5.6.7.8 с туннельными адресами 10.8.0.1/10.8.0.2 
маршрутизация переписывается на 
192.168.5.0/24 dev eth0  proto kernel  scope link  src 192.168.5.10
5.6.7.8/32 via 192.168.5.201 dev eth0
default via 10.8.0.1 dev tun0

после опускания туннеля удаляется маршрут к 5.6.7.8 и default. получаем 
следующее:
192.168.5.0/24 dev eth0  proto kernel  scope link  src 192.168.5.10

это очень плохо.
------- Comment #1 From 2007-03-05 15:40:05 -------
А конфигурация сервера и клиента OpenVPN какая?
Маршрут по-умолчанию у клиента изменяется через 'push "redirect-gateway"' на 
сервере? 
Вариант 'push "redirect-gateway def1"' ситуацию не исправит?
------- Comment #2 From 2007-03-05 16:07:21 -------
> Маршрут по-умолчанию у клиента изменяется через 'push "redirect-gateway"' на 
сервере? 

да, конечно. если делать push route конкретным подсетям все нормально 
------- Comment #3 From 2007-03-05 18:23:34 -------
И не должно работать.

Причина: при поднятии соединения клиент получает директиву 'redirect-gateway' 
от сервера и меняет маршрут по-умолчанию на новый, через tunX. Далее, согласно 
директивам 'user' и 'group', процесс openvpn клиента _понижает_ свои 
привилегии. При разрыве соединения клиент пытается восстановить маршрут на 
старое значение - и по очевидным причинам этого сделать не может. См. сообщения 
в логах клиента, вида:

Mar  5 18:03:50 naf-m openvpn[3855]: ip route add 0.0.0.0/0 via 192.168.250.254
Mar  5 18:03:50 naf-m openvpn[3855]: ERROR: Linux route add command failed: 
could not execute shell command

------
Пути решения проблемы: использовать в конфигурации сервера директиву
push "redirect-gateway def1"

При этом клиент не удаляет старый маршрут, а добавляет в таблицу маршрутизации 
записи вида:
0.0.0.0/1 via 192.168.231.5 dev tun0 
128.0.0.0/1 via 192.168.231.5 dev tun0 

При работе интерфейса данные записи используются вместо оставшегося в таблице 
маршрута по-умолчанию как более детальные. При остановке интерфейса эти записи 
удаляются и снова начинает использоваться оригинальный маршрут.

В 2.1 это поведение будет использоваться по-умолчанию.



Альтернативными вариантами являются или запуск клиента с привилегиями 
суперпользователя, или разрешение непривилегированному пользователю openvpn 
править таблицу маршрутизации.
------- Comment #4 From 2007-03-05 20:54:46 -------
спасибо за разъяснение. 
------- Comment #5 From 2007-03-09 01:42:30 -------
Николай, а не подскажете -- возможно ли подобный финт ушами провернуть для
pppd?
 А то cleardefaultroute у нас есть, а вот восстанавливать автоматическим путём
дешевле service network restart -- непонятно как.

См. #3319, #9256
------- Comment #6 From 2007-03-09 18:39:01 -------
Идеологически финт вполне универсальный: 
- default route не трогается,
- прописываются пара маршрутов через некий интерфейс (tunX для openvpn, pppX 
для pppd, и т.п.), для сетей 0.0.0.0/1 и 128.0.0.0/1
- в результате при поднятом интерфейсе используются данные маршруты, как более 
детальные,
- а при опущенном интерфейсе - более общий 0.0.0.0/0.

Правда, для openvpn такое использование таблицы маршрутизации позволяет после 
конфигурирования интерфейса сделать chmod и chmod, и после завершения процесса 
восстановить default route. А для ppp, работающего с правами root и без всяких 
chroot'ов, и который может сам при своём завершении переписать таблицу 
маршрутизации, это будет явным хаком.

Во всяком случае, похоже, если и ppp будет так себя вести, то придётся мне 
думать, как при необходимости организовать разбиение маршрута на 4 куска...