Предупреждението на OpenVPN за няколко --up скрипта: работи само един

Предупреждението за няколко скрипта звучи като оплакване за планиране, затова очевидното решение е да пренареждате редовете, докато не изчезне. То не е оплакване за планиране. По-късна дефиниция --up замества командата, вече запазена за този етап, и анализаторът го казва, което значи, че от двата ви скрипта някога е работил точно един. Другият не чака на опашка зад него; той е изчезнал.

Затова предупреждението заслужава внимание, макар и да не е фатално: то предсказва обновяване на DNS или промяна на маршрут, които тихо са престанали да се случват.

Предупреждението не е за подредбата

OpenVPN пази една команда на потребителски скрипт за етапа up. Когато анализаторът срещне друга дефиниция — от профила, от включен файл или от командния ред — той замества това, което вече е държал, и издава предупреждението. Нищо не се обединява, нищо не работи два пъти и въпросът за подредбата не съществува. Остава командата, която анализаторът е видял последна, затова преместването на ред може да смени победителя, а другият скрипт да остане мъртъв.

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

Намерете двете дефиниции в реалното стартиране

Започнете от това, което демонът действително е получил, а не от профила, който сте редактирали. ps -ef и ExecStart на юнита показват командния ред, в който може да се добави --up от входна точка на контейнер или от обвивка; init файлът на дистрибуцията може да направи същото. systemctl cat openvpn-server@server разкрива какво добавя самата услуга, а рекурсивен grep през конфигурационната директория намира дефинициите на файлово ниво. Дубликатите обикновено идват от различни слоеве и точно затова редактирането на един файл не променя нищо.

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

Нека един hook поеме работата

Трайното решение е един диспечер, който изпълнява двете действия в обмислен ред. Кратък shell скрипт с set -eu, който извиква нужната интеграция и след това локалното действие, предавайки "$@", за да оцелеят границите на аргументите, държи поведението на едно проверимо място. Предаването на аргументи само ги запазва; то не доказва, че двата помощника очакват еднакъв интерфейс, затова прочетете договора на всеки. Решете какво трябва да прави повредата и дали частичните промени трябва да се обръщат.

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

Почистването принадлежи на съответния етап down. Действие up, което пренаписва DNS или добавя маршрути, се нуждае от документирано връщане назад, а диспечер, който се занимава само със стартирането, е половин дизайн.

Потвърдете интеграцията, не само тишината

Премахването на предупреждението за дубликат е лесната част; интеграцията все още трябва да работи. Проверете състоянието на резолвера след свързване с resolvectl status или като прочетете /etc/resolv.conf, и потвърдете маршрутите с ip route. След това се изключете и се свържете отново, защото прибързано свързан hook обикновено оставя нещо от предишната сесия. journalctl -u openvpn-server@server -b показва дали диспечерът ви е работил и какво е отпечатал.

Дръжте привилегиите на hook там, където им е мястото. Повишаването на script-security или пускането на демона с повече права не е поправка за заменен hook; то разширява какво може да прави всеки бъдещ скрипт, включително такъв, който нападател ще назове.

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