Предварително създаден tun в OpenVPN: сравнение на двата модела на собственост

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

Името не е прикачване

dev tun1 иска от OpenVPN интерфейса с това име и традиционните сборки в потребителско пространство ще се опитат да го отворят. Ако името не следва обичайния шаблон tun или tap, профилът се нуждае и от съответстващ dev-type, защото типът никога не се извежда от низ. Устройството TAP не е устройство TUN с друга етикета: прикачването на грешното или се проваля направо, или създава връзка, която носи кадри, каквито никой не очаква. Проверете типа преди всичко останало, защото всяка следваща проверка предполага, че двете страни са съгласни за него. След това потвърдете, че процесът наистина може да отвори устройството, а не само да го види.

dev tun1
dev-type tun

Мрежовият интерфейс и /dev/net/tun са различни обекти: едното е връзка в пространство от имена, другото е символното устройство, което програма в потребителско пространство използва за прикачване. Документацията за Linux TUN/TAP описва този път на прикачване и правилата за собственост върху постоянни устройства. Root обвивка, която може да изпълни ip link, доказва само, че обвивката има привилегии, а не че демонът ги има. Собствеността върху устройствения възел, наборът от способности на услугата и потребителят, под който работи трябва да съвпаднат, преди отварянето да успее.

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

Кой конфигурира връзката: два модела на собственост

В първия модел OpenVPN конфигурира адресите и маршрутите като част от вдигането на връзката. Това е поведението по подразбиране и най-лесното за осмисляне, защото един компонент създава състоянието и после го премахва. Във втория модел външен мениджър притежава интерфейса, а ifconfig-noexec спира OpenVPN да изпълнява командите си за конфигуриране на адреси и предава параметрите на скриптове. Тогава мениджърът трябва сам да приложи правилната локална и партньорска конфигурация, което е повече работа, отколкото предполага името на опцията. Изборът между двете е въпрос кой може да променя връзката, докато тя е вдигната.

ifconfig-noexec покрива само адресите: маршрутната таблица остава незасегната, а конфигурирането на маршрути принадлежи на route-noexec. Третирайте двете директиви като отделни управления с отделни собственици, защото задаването на едното и допускането на другото е обичайна причина за наполовина конфигурирани връзки. Изберете точно един собственик на слой: адресите на едно място и маршрутите на едно място. Мрежов мениджър и VPN помощник, които едновременно пишат адреси, са начинът, по който едно прекъсване изтрива състояние, от което другата страна още зависи.

Инспектирайте устройството от пространството от имена, което има значение

Инспектирайте устройството от пространството от имена, в което работи VPN процесът, а не от това, в което случайно се намира вашата обвивка. Двете команди по-долу отговарят на различни въпроси и разликата се появява, когато хост вижда интерфейс, който контейнер не вижда. Изпълнете ги в дадения ред, защото втората има смисъл само след като знаете дали връзката изобщо съществува.

ip -details link show dev tun1
ip tuntap show

Първата команда отпечатва връзката, както я вижда ядрото, включително флагове и тип на интерфейса, и точно така потвърждавате, че това е устройството, което имате предвид. Втората изброява постоянните записи tun/tap, които съществуват, без който и да е процес да ги държи. Интерфейс, който чака своя собственик, е различна ситуация от жив тунел, прикачен към друг VPN, и само втората обяснява защо вашето прикачване се проваля. Намерете процеса, който държи устройството, преди да променяте каквото и да е, защото постоянен запис и зает интерфейс имат различни решения.

Поддръжката на множество опашки е конкретна схема на драйвера със свои изисквания, а не разрешение несвързани процеси да делят един интерфейс. Жива сесия на друг собственик е проблем на координация и никаква редакция на профил не го решава.

Два различни вида постоянство

Постоянството в ядрото и persist-tun описват животи, които лесно се смесват и скъпо се бъркат. Постоянното устройство съществува независимо от всеки процес, затова оцелява при спиране и може да се използва от следващото стартиране. persist-tun запазва ресурсите през поддържаните меки нулирания в един OpenVPN процес, много по-кратък хоризонт. Нито едното не обещава, че спирането на услугата оставя маршрутите и адресите на място, а интерфейс, който остава видим, не е доказателство за работеща криптирана сесия.

Проверете и бекенда, защото предварително създаденият интерфейс не казва нищо за това коя реализация ще го отвори. Общностните сборки с директния път на данните ще се опитат да го използват, освен ако дизайнът не казва друго. Където версията поддържа превключвателя, disable-dco избира вместо това пътя в потребителско пространство; по-старите машини и други клиенти нямат такава директива, затова дръжте условието за версия до опцията, вместо да приемате, че се прилага.

Какво се чупи, когато се тества само стартирането

Споразумение за собственост може да мине първия тест и да се провали на последния, което прави стартирането само по себе си слаба проверка. Наблюдавайте вместо това два прехода: меко нулиране и пълно спиране, последвано от стартиране.

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Мекото нулиране трябва да остави сесията използваема и ресурсите цели, което е работата на persist-tun. Пълното спиране е мястото, където външен мениджър се издава: ако връзката или адресите ѝ преживеят спирането, някой друг ги притежава и това е или състоянието, което сте документирали, или грешката, която току-що намерихте. Запишете двете наблюдения до профила, за да започва следващата промяна от доказателства, а не от диаграма.