Зашто ваш OpenVPN клијент остаје искључен после једног истека времена

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

Почните од онога што је јединица заиста урадила, а не од онога што тврди надзор. systemctl status openvpn-client@office и journalctl -u openvpn-client@office -n 50 показују разлог изласка и последњи ред који је клијент написао пре одласка.

Процес је изашао пре него што је ико приметио

Клијент који нестане без грешке обично је изашао намерно. Понашање одређује профил, а не менаџер услуга: ping-exit завршава процес чим друга страна престане да одговара, док ping-restart задржава процес и поново се повезује унутар њега. Ограничења сесије и тајмери неактивности споља дају исту слику: без тунела и без аларма.

Две ping директиве не могу бити заједно у једном профилу, зато изаберите једну и запишите избор. Погледајте и сервер, јер његов сопствени ping-exit затвара сесију без обзира на то шта је клијент затражио, и само дневник сервера бележи ко је донео ту одлуку.

Избор између ping-exit и ping-restart

Изаберите ping-restart за преносни рачунар или удаљено место које треба само да се излечи, а ping-exit сачувајте за случајеве када мртав тунел мора да заустави процес како би нешто друго могло да реагује на њега. Бројеви су мање важни од везе: ping 10 са ping-restart 60 значи десет секунди тишине пре провере и шездесет пре поновног покретања, што је агресивно на мобилној вези са губицима, а разумно на жичаној. Запишите разлог поред реда, иначе ће следећи читалац претпоставити да су подразумеване вредности биле намерне.

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

Надзор који заиста поново покреће јединицу

На systemd домаћину најмања трајна промена је једна drop-in датотека: Restart=on-failure и RestartSec=10 у /etc/systemd/system/[email protected]/restart.conf. Drop-in се чита само када systemd поново учита своје дефиниције, зато потом покрените systemctl daemon-reload. Проверите помоћу systemctl show -p Restart -p ExecMainStatus openvpn-client@office уместо да претпоставите да је вредност стигла. Инстанца у називу датотеке мора бити профил који јединица заиста учитава, па датотека написана за office не чини ништа за openvpn-client@home.

on-failure игнорише један случај: чист излазак са статусом нула. Неки путеви расклапања завршавају тако, зато читајте забележени статус уместо да верујете формулацији приручника. Ако ваш клијент одустане са нулом, потребан вам је Restart=always, а цена је да се заиста покварен профил враћа изнова и изнова док се не активира ограничење брзине покретања и дневник се не напуни.

Restart=always се активира и после намерног заустављања. Користите systemctl stop за одржавање и маскирајте јединицу ако мора да остане искључена док радите.

Ухватите цурење док је тунел искључен

Надзор враћа тунел; он не спречава саобраћај да изађе док тунела нема. persist-tun задржава уређај и његове руте између поновних повезивања, што је згодно и отвара прозор. Уређај преживљава, руте још показују на њега, а пакети отичу незаштићени и непријављени. То је избор политике, а не неутрална подразумевана вредност.

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

Тестирајте то намерним заустављањем клијента. Покрените systemctl stop openvpn-client@office, затим curl -m 5 https://example.com, који би требало да не успе, а не да успе преко физичке везе. Успех значи да правило заштитног зида недостаје или је превише дозвољавајуће.

Поново се повежите, потврдите да тунел опет носи саобраћај и тек онда додајте проверу у надзор. Анкетирање ip addr из cron-а за уређај tun је надзор који најчешће не успева, јер са persist-tun уређај живи дуже од сесије и провера извештава о здрављу док се ништа не преноси.