Обикновено приложение за Linux използва VPN, без да пипа TUN

Браузър, който използва вече установен VPN в Linux, не отваря /dev/net/tun. Той отваря сокет и ядрото решава през кой интерфейс излизат пакетите на този сокет. Процесът, който е създал тунела, върши друга работа от процеса, чийто трафик пренася. Разделянето на тези две роли отговаря на повечето въпроси за права, преди още да бъдат зададени.

Проследете един пакет от сокета до тунела

Обикновено приложение извиква connect или send и ядрото търси маршрут до дестинацията. Ако избраният маршрут сочи към интерфейса на тунела, пакетът се поставя в опашката на устройството, което демонът на VPN чете. Демонът го криптира и го изпраща през физическия интерфейс. Всяка стрелка в това описание е място, където може да се отговори на въпрос за права.

Нищо по този път не изисква приложението да знае за устройството. Демонът държи файловия дескриптор и извършва операциите с интерфейса, докато приложението вижда само нормален мрежов API.

Начертайте двете половини веднъж и въпросите за права стават по-лесни за поставяне. Горната половина е светът на приложенията, а долната принадлежи на демона.

Решете кой има нужда от устройството и кой не

Създаването на интерфейс TUN или свързването с него изисква достъп до устройството плюс правото да го конфигурирате, затова поддържана VPN услуга започва с права за администриране на мрежата или използва привилегирован помощник. Това изискване принадлежи на демона. То не казва нищо за браузъра, клиента на базата данни или инструмента за пренос на файлове. Услуга, на която е нужно правото, го иска за собствената си стъпка по настройка, не за своите клиенти.

След като маршрутът и политиката са на място, обикновен процес използва получения път чрез обичайните си извиквания на сокет. Той не се нуждае от възела на устройството и не се нуждае от root.

Промяната на правата на устройството не е начин да се даде на приложение достъп до дестинация. Тя само премества границата на устройството другаде.

Проверете пространството от имена, в което приложението наистина работи

Контейнер или второ мрежово пространство от имена дава на процесите си отделен набор интерфейси и таблица за маршрутизация. Тунел на хоста не се появява там автоматично и никаква промяна на правата на устройството не променя това. Приложението просто ще минава през каквото това пространство предоставя. Затова образът на контейнер не може случайно да наследи тунел на хоста.

Проверете с ip netns list и ip -n NAME route или като разгледате връзката на пространството от имена за процеса. Отговорът обикновено се вижда с една команда.

На двама потребители на един и същ хост също може да се дадат различни пътища чрез политика. Това е мрежово решение, а не доказателство за собственост върху устройството.

Отделете правата от мрежовата политика

Някои инструменти се нуждаят от повече от сокет. Захващането на пакети изисква суров сокет, а промяната на маршрути — права за администриране. Това са отделни операции с отделни разрешения и даването на едно не бива да се чете като общо изискване за използване на VPN.

Програма, която реализира собствен тунел, е третият случай. Тя наистина отваря TUN, защото поема ролята на демона, и затова се нуждае от привилегиите на демона.

Назовете операцията, преди да назовете привилегията. Обикновено двете се разделят по-лесно, отколкото изглежда.

Проверете разделението с два акаунта

Свържете тунела като услуга, после стартирайте приложението като обикновен потребител и потвърдете, че достига до частния ресурс. Проверете ip route get за дестинацията от обвивката на този потребител, за да видите кой интерфейс е избран. Ако маршрутът е правилен, а връзката пак се проваля, проблемът е в политиката, а не в привилегията.

Полученият дизайн е минимални права с ясна граница: един компонент притежава настройката и ресурсите на тунела, натоварванията пазят нормалните си акаунти, а мрежовата политика решава какво може да минава. Пускането на всичко като root сгъва тези роли, без да обяснява нищо.