Који openvpn бинарни фајл ради? Проверите путању покретања

Старо заобилазно решење преместило је извршни фајл OpenVPN-а на друго место и оставило shell омот на изворној путањи. Месецима касније долази надоградња, и поништавање решења постаје нагађање који је фајл заправо клијент. Назив команде, извршни фајл конфигурисан у услузи и сопствени списак фајлова пакета могу сви указивати на различите објекте, а поправка једног без осталих даје хост који изгледа поправљено и понаша се горе.

Почните од путање коју услуга покреће

Терминал и systemd јединица не разрешавају извршне фајлове на исти начин. Shell претражује PATH; јединица именује путању, а drop-in измене је могу заменити без дирања у фајл који читате. Та разлика објашњава већину забуне у овом задатку. Она такође одлучује на који фајл ваша поправка мора циљати.

Питајте јединицу шта покреће, укључујући drop-in фајлове који је мењају, и читајте резултујући ExecStart ред уместо фрагмента који сматрате меродавним. Затим пратите ту путању кроз сваку симболичку везу до коначног фајла. Омот који се завршава exec у скривени директоријум чест је распоред из ових старих поправки.

Запишите разрешену путању пре него што било шта промените.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Упоредите назив команде са путањом услуге

Два одговора се често разликују и та разлика није аутоматски квар. NetworkManager додатак може покретати своју путању, а контејнер може монтирати још једну.

Важно је знати који власник покреће процес који опслужује саобраћај. Ако јединица покреће /usr/local/sbin/openvpn-wrapper док ваш shell разрешава /usr/sbin/openvpn, поправка другог фајла не мења ништа у услузи.

Питајте који пакет поседује сваког кандидата, па одлучите да ли је фајл под управљањем пакета или локално постављен. Фајл без пакета који га поседује је фајл који је неко намерно тамо ставио и заслужује назив, власника и разлог пре брисања. Обрнута грешка је такође честа: преписивање фајла пакета старим сачуваним бинарним фајлом јер је објава на форуму користила исти директоријум.

Пустите базу података пакета да говори о фајловима пакета

Када софтвер долази из Debian пакета, база података пакета може вам рећи да ли се његови фајлови још подударају с оним што је инсталирано. То је уско питање целовитости, а не сигурносна пресуда, и разлика је важна када одлучујете шта поправити. Неподударање значи да се фајл променио после инсталације, што може бити ваше старо решење или легитимна локална измена. Излаз не решава које, па га читајте као показатељ, а не као закључак.

Покрените проверу и читајте излаз уместо да празан резултат сматрате доказом било чега.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Приручник за dpkg документује да провера пореди инсталиране фајлове с локално записаним метаподацима, користећи сачуване контролне суме где постоје. Примећује промењен фајл пакета и не може вам рећи да ли се уместо њега покреће други бинарни фајл.

Забележите стање пре поправке

Прикупите разрешену путању покретања, однос фајла с пакетом, локацију омота и запис о промени који га је увео. Копирајте омот на заштићено место ако садржи интеграциони рад који ће касније требати.

Не лепите садржај омота у тему подршке пре него што га прочитате, јер ове скрипте понекад носе акредитиве или детаље о пролазној тачки.

Забележите које профиле услуга користи и ко је повезан док радите, јер поновно покретање тунела може прекинути сесију којом администрирате хост.

Потврдите покретање, а затим уклоните омот

Након поправке покрените услугу и потврдите да процес ради на путањи коју сте наменили. Ручни упит верзије доказује да фајл ради; не доказује да га јединица користи.

Затим поново повежите клијента и проверите да ли се профил још увек аутентификује, јер замена бинарног фајла која игнорише изворне опције неће успети на начин који изгледа као проблем са сертификатом.

Уклоните премештен омот кроз исти запис о промени који га је увео. Завршена поправка наводи који извршни фајл ради, зашто и који је фајл уклоњен; враћање назива фајла и нада нису иста ствар.