Зарегистрирован: 21.11.2006
Пользователь #: 46,548
Сообщения: 369

Зарегистрирован: 22.07.2003
Пользователь #: 8,017
Сообщения: 100

Голоса: 3

Зарегистрирован: 21.11.2006
Пользователь #: 46,548
Сообщения: 369

Зарегистрирован: 28.01.2009
Пользователь #: 75,624
Сообщения: 8484
Откуда: Москва

Голоса: 157

Зарегистрирован: 21.11.2006
Пользователь #: 46,548
Сообщения: 369

Зарегистрирован: 28.01.2009
Пользователь #: 75,624
Сообщения: 8484
Откуда: Москва

Голоса: 157

Зарегистрирован: 22.07.2003
Пользователь #: 8,017
Сообщения: 100

Голоса: 3

Зарегистрирован: 21.11.2006
Пользователь #: 46,548
Сообщения: 369

Зарегистрирован: 22.07.2003
Пользователь #: 8,017
Сообщения: 100

Голоса: 3

Зарегистрирован: 21.11.2006
Пользователь #: 46,548
Сообщения: 369

Источник

OpenVPN: — PUSH тебе твой собственный ROUTE

К бессонной ночи привёло “молчание логов” OpenVPN сервера при невозможности прочесть файл.

Имеется OpenVPN сервер, к которому подключены VPN клиенты. За некоторыми клиентами находятся сети которые необходимо анонсировать другим клиентам OpenVPN и обеспечить маршрутизацию.

Для этого в OpenVPN предусмотрены четыре параметра находящиеся в двух разных файлах которые позволяют настроить роутинг в сети VPN клиента.

Файл /etc/openvpn/*.conf

client-config-dir определяет каталог в котором будут находиться файлы в которых будут объявлены сети клиентов. Имена файлов должны совпадать с CommonName сертификата клиента за которым находятся сети объявленные в файле. Например если за клиентом с сертификатом у которого CN равен “vpn03.gw01.common-client2” находится сеть 192.168.33.0 255.255.255.0 то файл /etc/openvpn/ ccd-vpn03 /vpn03.gw01.common-client2

При правильном поведении сервер должен посылать VPN клиентам команду PUSH ROUTE но обязан исключать сети самих клиентов которым посылается команда PUSH. Тоесть в нашем случае сервер из всего что отправлял клиенту с сертификатом “vpn03.gw01.common-client2” должен был исключить сеть 192.168.33.0 255.255.255.0 так как она объявлена в файле в директиве iroute. Однако он вёл себя так словно этого файла не существовало и поступал так:

На стороне роутера

Видно что и на сервере и на клиенте присутствует маршрут route 192.168.33.0 255.255.255.0 который приводит к вот такой ерунде на стороне клиента:

Как видно, подствеченные строки указывают один и тот же маршрут через разные интерфейсы. Но то что свой собственный “железный” маршрут прописан через виртуальный интефейс не идёт ни в какие ворота. Вполне логично, что маршрутизация на клиенте “ломается” самым серьёзным образом.

Всё это наводит на мысль что инструкция iroute 192.168.33.0 255.255.255.0 была сервером проигнорирована, либо не связана с CommonName сертификата грубо говоря сервер не признал что у клиента есть свои сети.

Когда файл недоступен первое средство проверить SELinux метки и даже отключить на время SELinux. Но в этом случае мне это не помогло.

Ларчик открылся только утром следующего дня, когда все танцы с бубнами закончились и остались два последних средства strace и отладка исходников.

И о этом ни единого байта в логах OpenVPN хотя об этом необходимо кричать!

Процесс выполняется от gid=99 и uid=99, а это nobody nogroup. А права на файл?

Только root может читать писать эти файлы.

В отличии от других конфигурационных файлов /etc/openvpn/ccd-vpn03/vpn03.gw01.common-client2 читается во время подсоединения клиента и ошибку стоит ловить в это время. И читается это файл непосредственно сервисом уже после переключения в nobody nogroup.

Вот для сравнения как выглядят логи сервера с заблокированным файлом и с разблокированным:
Вот как выглядит начало иницииации соединия при рестарте со стороны клиента:

файл нормально прочитан

когда файл не может быть прочитан

Как видно ошибки нет. Просто отсутствует строка OPTIONS IMPORT. И из-за этого я потерял несколько часов сна и написал эту статью.

ВЫВОД:
Устанавливая режим работы VPN сервера или клиента под Linux в nobody nogroup проверьте что файлы в каталоге ccd имеют возможность читаться всеми. На остальные файлы логи, статусы и конфиги достаточно что для root установлены права “читать и писать”.

Источник