ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | не восстанавливает default route | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Nick S. Grechukh <gns> |
| Component: | openvpn | Assignee: | Nikolay A. Fetisov <naf> |
| Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus |
| Severity: | critical | ||
| Priority: | P2 | CC: | naf |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
Nick S. Grechukh
2007-03-05 15:08:23 MSK
А конфигурация сервера и клиента OpenVPN какая? Маршрут по-умолчанию у клиента изменяется через 'push "redirect-gateway"' на сервере? Вариант 'push "redirect-gateway def1"' ситуацию не исправит? > Маршрут по-умолчанию у клиента изменяется через 'push "redirect-gateway"' на
сервере?
да, конечно. если делать push route конкретным подсетям все нормально
И не должно работать. Причина: при поднятии соединения клиент получает директиву '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 править таблицу маршрутизации. спасибо за разъяснение. Николай, а не подскажете -- возможно ли подобный финт ушами провернуть для pppd? А то cleardefaultroute у нас есть, а вот восстанавливать автоматическим путём дешевле service network restart -- непонятно как. См. #3319, #9256 Идеологически финт вполне универсальный: - 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 куска... |
