OpenVPN неће да се покрене: прочитајте први ред, не конфигурацију

VPN који умре у првој секунди је другачија животиња од оног који се повеже и затим не успе, а уобичајена грешка је да се оба третирају исто. Овде нема руковања, нема размене сертификата ни руте за преглед. Који од неколико неповезаних поправака важи одлучује један ред у дневнику, а његово прескакање кошта поподне проведено у уређивању конфигурације која никада није прочитана. Најпре прочитајте тај ред.

До тога стижете са три команде само за читање: journalctl -u openvpn@server -b --no-pager прво, systemctl status openvpn@server друго и ss -lunp за UDP слушаоце и њихове власнике.

Први ред бира грану

Сукоб портова и недостајућа бинарна датотека обоје убијају покретање у секунди и остављају различите прве редове. Порука о већ коришћеној адреси именује порт; недостајући извршни фајл именује путању која више не постоји; неуспешан услов или одсутна конфигурациона датотека именује датотеку. Та три воде ка различитим поправкама и ниједној од њих не помаже поновна инсталација клијента. Први неуспех препишите у белешке пре него што било шта покренете.

Пазите на петљу поновних покушаја која скрива оригинални ред. Јединица са политиком поновног покретања може први неуспех затрпати туцетом истих, па је journalctl -b филтриран по јединици и читан од почетка бољи од краја.

Ко још држи порт 1194

Кривац обично није други сервер који је неко намерно подесио. Очекујте ручно покренутог клијента који је још жив у другом терминалу, други профил који је случајно изабрао исти порт, или добављачки пакет чији сопствени тунел држи 1194. Власник сокета се појављује у ss -lunp; тај PID проследите systemctl status да сазнате да ли је јединица одговорна. Скините га кроз сопствену контролну путању, не сигналом.

Сигнал процесу којим управља јединица обично изазива поновно покретање, а исти неуспех се за час поново појави као нов проблем. За јединицу користите systemctl stop, за добављачку инсталацију сопствену сервисну команду пакета, а сигнал само за нешто што сте ручно покренули у тој љусци.

Преостале јединице после чишћења

Чишћење брише бинарне датотеке; ручно написане датотеке јединица, обично под /etc/systemd/system, преживљавају га. Systemd затим понавља јединицу која показује на путању која више не постоји, а порука се тиче те недостајуће датотеке, а не јучерашњег уклањања. systemctl status приказује фрагмент путање јединице при врху, па је проверите помоћу dpkg -S пре него што било шта обришете. Када је сироче уклоњено, systemctl daemon-reload и systemctl reset-failed чисте стање; иначе га свака каснија провера стања наслеђује.

Када which openvpn одговори нечим под /usr/local, бинарна датотека у игри долази од добављачевог инсталатера, а не из apt. Такав инсталатер обично доноси сопствени слушалац, сопствени унос за покретање и сопствени конфигурациони директоријум, па уклањање видљиве команде оставља сокет заузет.

Уклоните га онако како добављач документује, потврдите да је порт слободан помоћу ss -lunp и додајте клијента дистрибуције само ако вам је потребан.

Смирите стање пре поновног покушаја

Пре извођења закључака очистите неуспешно стање: systemctl reset-failed уклања бројаче, а systemctl status затим пријављује тренутно стање јединице, а не њену историју. Покрените је једном и читајте дневник те инстанце, а не збирно стање машине. Јединица која пријављује активно док тунел ништа не преноси је засебан проблем и много чешћи. У пријавама грешака обоје се спаја јер се обоје завршава тако што корисник каже да VPN не ради.

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