OpenVPN при стартиране на Ubuntu: NetworkManager или systemd?

Повечето ръководства представят избора като козметичен: или оставете NetworkManager да вдигне тунела, или активирайте инстанция на systemd и готово. Двата пътя се различават по едно нещо, което решава изхода на машина без екран, и то няма нищо общо с това кой инструмент е по-нов. NetworkManager отключва тайни чрез сесия; инстанцията на systemd няма сесия, която да отключи. Изберете тази, чиято работа с тайни отговаря на машината пред вас.

Всичко останало, от инсталирането на маршрути до поведението при повторно свързване, следва от това първо решение.

Ключодържателят е разликата, за която никой не говори

Когато NetworkManager притежава VPN профил, паролата може да живее в ключодържателя за вход, който се отключва, когато потребителят влезе. Това работи добре на лаптоп: човекът е налице, ключодържателят се отваря, тунелът се вдига. На сървър, който зарежда без надзор, няма кой да отключи нищо, затова профилът чака тайна, която така и не идва. Връзката изглежда конфигурирана и никога не се активира.

Инстанцията на systemd избягва този проблем, като чете файл с идентификационни данни от диска, което прави файла това, което защитавате. chmod 400 плюс собственост от root е минимумът, а файлът трябва да остане извън резервни копия и шаблони на образи, които не контролирате.

Свързването на VPN към връзка не гарантира зареждане

В nm-connection-editor изберете кабелната или безжичната връзка, а не VPN, отворете раздела General, отметнете опцията за автоматично свързване с VPN и назовете профила. След това NetworkManager активира VPN като вторична връзка, когато основната достигне състояние на свързаност. Това е зависимост, а не правило на защитната стена. Пакетите все още могат да излизат през секундите преди тунелът да е вдигнат, а запазена тайна, която не се отключва, оставя машината онлайн без него.

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

Инстанцията на systemd се нуждае от съвпадащо име на файл

Поставете профила в клиентската директория, която пакетът очаква, например /etc/openvpn/client/office.conf, и посочете отвътре файла с идентификационни данни с auth-user-pass office.cred. Името на инстанцията е името на файла без суфикса, така че openvpn-client@office чете office.conf. Активирайте я с sudo systemctl enable --now openvpn-client@office и потвърдете съответствието с systemctl cat openvpn-client@office, вместо да се доверявате на пример от блог.

Пътищата в профила се разрешават спрямо работната директория на юнита, а не спрямо самия профил, така че относителен ред ca или auth-user-pass може да се провали при зареждане, докато работи при ръчен тест. Използвайте абсолютни пътища за всичко, което юнитът трябва да намери. След това прочетете journalctl -u openvpn-client@office -b след истинско зареждане; юнит, който съобщава активност без тунел, обикновено назовава липсващ файл в този журнал.

По-старите пакети доставят различно име на шаблон, затова systemctl list-unit-files 'openvpn*' решава кой съществува на този хост.

Поведението при повторно свързване е отделно решение

Профил с ping-restart изгражда тунела наново, след като падне, а юнит с директива за рестарт прави нещо подобно на ниво услуга. Това са политики, които избирате, а не настройки по подразбиране, които наследявате. Ако връзката трябва да се вдига само при поискване, премахнете поведението за рестарт умишлено и запишете защо. Ако юнитът стартира преди мрежата да е използваема, той се нуждае от политика за повторни опити, защото един неуспешен опит при зареждане не се повтаря сам.

Спирането е също толкова буквално: sudo systemctl disable --now openvpn-client@office спира работещата инстанция и премахва връзката за зареждане. Самото деактивиране оставя тунела работещ до следващото рестартиране, което изненадва всеки, който тества, като деактивира и гледа как интерфейсът остава вдигнат.

Рестартирайте, после проверете четири неща по ред

Рестартирането на услугата тества услугата; рестартирането на машината тества пътя на зареждане. След рестарта потвърдете, че юнитът се е вдигнал, после че съществува маршрут до отдалечената подмрежа, после кой адрес машината показва на интернет и накрая че имената се разрешават през тунела. Тези четири проверки се провалят в този ред, когато нещо не е наред, което прави първия провал полезния.

Активен юнит без маршрут обикновено означава, че профилът се е свързал, но сървърът не е изпратил маршрут, или маршрутът е бил инсталиран на интерфейс, който по-късно е изчезнал. Маршрут без работещо търсене на имена сочи към DNS конфигурацията, а не към самия тунел.

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