systemd спира VPN услугата: съобразете Type= с клиента

VPN юнит при зареждане става неактивен, когато Type= не съответства на жизнения цикъл на клиента. Съобразете типа, поправете собствеността и подредете услугата след тунела.

Юнитите може да изглеждат правилни, systemctl start може да съобщи успех, а десет секунди по-късно услугата стои неактивна. Или се рестартира на всеки половин минута, докато ограничението за стартиране не я спре. Нито едно от двете поведения не е мрежова повреда: юнитът описва жизнен цикъл на процес, който не съвпада с това, което клиентът всъщност прави. Клиентът може да форкне и да излезе или да конфигурира сесията и веднага да излезе.

Защо юнитът става неактивен секунди след успешно стартиране

systemd извежда състоянието от процеса, който е стартирал, така че Type= е твърдение за този процес, а не документация. С Type=simple юнитът се брои за активен, докато командата работи, и става неактивен, когато тя се върне. Затова клиент, който предава връзката на помощна програма и излиза, изглежда като срив, дори когато тунелът работи. Тогава журналът показва модел старт-стоп, който се чете като повреден изпълним файл.

Прочетете типа на юнита редом с поведението на клиента, преди да пипате мрежовата конфигурация.

Изберете типа, който пасва на клиента

Два модела покриват повечето CLI от доставчици: команда, която конфигурира сесия и излиза, и команда, която форква помощна програма преди да се върне. Всеки от тях изисква различна форма на юнит.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot с RemainAfterExit=true оставя юнита активен след връщането на командата, което пасва на модела „конфигурирай и излез“, а командата за спиране дава на услугата чисто затваряне. Форкващият клиент запазва същата форма, но му трябва Type=forking, за да проследи systemd дъщерния процес. Задайте Restart=on-failure, RestartSec=30 и краен StartLimitBurst, за да не се превърне прекъсване при доставчика в цикъл от рестарти, който заравя грешката.

Не позволявайте на наблюдаван клиент да демонизира

Наблюдаващите процеси извън systemd се удрят в същата стена. Скрипт на runit, който стартира демонизиран клиент, се връща веднага към наблюдателя, а той прочита връщането като срив и стартира още едно копие. Всеки наблюдател очаква да притежава процеса на преден план, както sshd -D остава отпред. Махнете флага за демон при наблюдаваните команди и оставете наблюдателя да върши работата във фонов режим. Обвивки, които се връщат преди тунелът да съществува, причиняват същото объркване.

Процес, който се отделя сам, е невидим за всичко, което е трябвало да го наблюдава.

Сесията приключва и отнася тунела със себе си

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

Потребителят на услугата е другата половина на същия проблем. Ключ, притежаван от root с режим 0600, е нечетим за юнит, работещ под друг акаунт, без значение какво е постигнал sudo в вашата обвивка.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Подредете зависимите след като адресът съществува

Когато демон се върже към адрес на тунел, който още не е създаден, той излиза с Cannot assign requested address. Поправката е явно подреждане, а не цикъл от повторни опити.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= подрежда задачите, докато Requires= на юнита на устройството свързва зависимия с наличието на интерфейса, което е по-силно от чакането само на мрежовата цел. Презаредете мениджъра след редактиране и рестартирайте зависимата услуга, после прочетете журнала ѝ, вместо да предполагате, че редът е подействал. Изпращайте изхода на клиента в журнала с StandardOutput=journal или опция за лог, защото наблюдаван клиент, който пише във файл, който никой не отваря, изглежда идентично с такъв, който никога не е стартирал.

След това рестартирайте веднъж и потвърдете, че юнитът е активен, след като се появи устройството на тунела. Поправка, проверена само с systemctl start, не е тествала реда при зареждане, който е трябвало да оправи.

Подобни статии