LINUX.ORG.RU
Форум — General  

Права на /dev/net/tun в Debian 12; Подключение по OpenVPN без sudo

 


0

1

Усилиями freedesktop.org стандартизация столь продвинулась, что импортированное через любой совместимый DE (Gnome, Cinnamon, KDE) VPN-соединение доступно во всех других. Но увы, не работает. Можно нажать «Подключить» и DE скажет, «подключено», но на практике VPN активирован не будет.

Так как через консоль OpenVPN-соединение нужно поднимать через sudo openvpn, иначе Cannot ioctl TUNSETIFF tun, заподозрю, что дело в правах пользователя.

Вместе с этим:

$ ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 мар 14 00:36 /dev/net/tun

Насколько я понимаю, crw-rw-rw- означает, что права на запись есть у всех.

★★★★★

Последнее исправление: eugrus (всего исправлений: 1)

Можно нажать «Подключить» и DE скажет, «подключено», но на практике VPN активирован не будет.

В чём это выражается? Сетевой интерфейс создаётся? Может, провайдер просто блокирует OpenVPN?

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Может, провайдер просто блокирует OpenVPN?

Как уже было сказано, я могу успешно подключиться с root-правами (через sudo openvpn file.ovpn).

В чём это выражается?

Трафик не идёт через VPN и ресурсы удалённой локальной сети недоступны.

Сетевой интерфейс создаётся?

Действительно создаётся.

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

15: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.8.0.2/24 brd 10.8.0.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::829e:6f93:935d:ae01/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Рабочее соединение через sudo openvpn выглядит также:

14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.8.0.2/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::adb4:7725:d1a6:e5ae/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
eugrus ★★★★★
() автор топика
Ответ на: комментарий от etwrq

Вот что попробовал:

# echo KERNEL=="tun", MODE="0666" > /etc/udev/rules.d/99-openvpn.rules && udevadm control --reload-rules && udevadm trigger

Это ничего не изменило.

Как и

echo KERNEL=="tun", GROUP="users", MODE="0666" > /etc/udev/rules.d/99-openvpn.rules && udevadm control --reload-rules && udevadm trigger

Если имелось ввиду что-то другое, то прошу пояснений.

(Но tun, как мы установили чуть выше, создавался и ранее при подключении через GUI.)

eugrus ★★★★★
() автор топика
Последнее исправление: eugrus (всего исправлений: 1)
Ответ на: комментарий от etwrq

С --verb 11 или без, через консоль от просто пользователя только ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1) из релевантного.

Но в journalctl вот что заметил:

мар 17 14:06:22 eugensdebianpc systemd-udevd[199519]: /etc/udev/rules.d/99-openvpn.rules:1 Invalid key/value pair, ignoring.

Что я не так прописал в правиле?

eugrus ★★★★★
() автор топика
Ответ на: комментарий от eugrus

Смотри какие галки в настройках openvpn подключения через network manager ты выставил.

Там должна быть галка разрешающая или запрещающая добавлять маршруты с этого vpn подключения.

noprefixroute
              Do not automatically create a route for the network prefix
              of the added address, and don't search for one to delete
              when removing the address. Changing an address to add this
              flag will remove the automatically added prefix route,
              changing it to remove this flag will create the prefix
              route automatically.

У тебя выставлен флаг noprefixroute. За подробностями сюда: https://man7.org/linux/man-pages/man8/ip-address.8.html

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

В KDE для VPN есть диалог «Маршруты» и там можно галкой запретить автоматически полученные. Она НЕ выставлена.

eugrus ★★★★★
() автор топика
Последнее исправление: eugrus (всего исправлений: 3)
Ответ на: комментарий от Rootlexx 
eugrus@eugensdebianpc:~$ ip route # без VPN
default via 192.168.178.1 dev enp0s25 
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 metric 100 
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown 
169.254.0.0/16 dev enp0s25 scope link metric 1000 
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25 
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25 metric 100 
192.168.178.1 dev enp0s25 scope link 
eugrus@eugensdebianpc:~$ ip route # нерабочий VPN через GUI
default via 192.168.178.1 dev enp0s25 
default via 10.8.0.1 dev tun0 proto static metric 50 
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 metric 100 
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 metric 50 
94.198.134.88 via 192.168.178.1 dev enp0s25 proto static metric 50 
169.254.0.0/16 dev enp0s25 scope link metric 1000 
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25 
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25 metric 100 
192.168.178.1 dev enp0s25 scope link 
192.168.178.1 dev enp0s25 proto static scope link metric 50 
eugrus@eugensdebianpc:~$ ip route # рабочий VPN через sudo openvpn
0.0.0.0/1 via 10.8.0.1 dev tun0 
default via 192.168.178.1 dev enp0s25 
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 metric 100 
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 
94.198.134.88 via 192.168.178.1 dev enp0s25 
128.0.0.0/1 via 10.8.0.1 dev tun0 
169.254.0.0/16 dev enp0s25 scope link metric 1000 
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25 
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25 metric 100 
192.168.178.1 dev enp0s25 scope link
eugrus ★★★★★
() автор топика
Ответ на: комментарий от eugrus

Вот и причина: маршруты. При подключении через NM у проводного интерфейса остаётся более высокий приоритет.

Как настроено проводное соединение? — не через /etc/network/interfaces, случайно?

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Как настроено проводное соединение?

«Из коробки» - цепляется по DHCP.

/etc/network/interfaces тоже дефолтный:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
eugrus ★★★★★
() автор топика
Ответ на: комментарий от Rootlexx 
eugrus@eugensdebianpc:~$ nmcli connection show enp0s25 |grep -i ipv4.route
Ошибка: профиль подключения enp0s25 не обнаружен.
eugrus@eugensdebianpc:~$ nmcli connection show lxcbr0 |grep -i ipv4.route
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
eugrus@eugensdebianpc:~$ nmcli connection show korolev |grep -i ipv4.route # это VPN
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)

В итоге нужно вручную сделать nmcli connection modify для ipv4.route-metric проводного соединения или можно как-то заставить систему автоматически адекватно расставлять приоритеты?

eugrus ★★★★★
() автор топика
Последнее исправление: eugrus (всего исправлений: 4)
Ответ на: комментарий от eugrus

или можно как-то заставить систему автоматически адекватно расставлять приоритеты?

Ну у меня, например, NM ставит VPN маршрутом по умолчанию, и только флажок «Использовать только для ресурсов этой сети» в настройках заставляет его перестать это делать. Как задать метрики по умолчанию, я не в курсе.

Rootlexx ★★★★★
()
Ответ на: комментарий от eugrus

Вот сейчас достал ноут с проводным подключением — на всех маршрутах NM проставил метрики, в отличие от вашего случая. На другом ноуте с Wi-Fi то же самое.

Странно.

Rootlexx ★★★★★
()
General