Поновно покретање услуге при OpenVPN up: куке побеђују tun0.device

Повезивање зависне услуге на tun0.device изгледа као претплата на тунел, али није. Јединица уређаја одражава да интерфејс постоји, што може остати тачно кроз неуспелу везу и поновно повезивање које следи. Услуга тада делује у погрешном тренутку, или никада, зависно од тога да ли је интерфејс у међувремену нестао. Кука која описује догађај који вас заиста занима је она коју позива OpenVPN, а не она коју закључује systemd.

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

Шта јединица уређаја заправо прати

systemd ствара јединицу уређаја из погледа језгра на мрежни интерфејс, па tun0.device постаје активан када се интерфејс појави и неактиван када се уклони. Са persist-tun, меки рестарт задржава интерфејс на месту, па јединица никада не флапа и ништа на њу везано се не покреће. Чак и без постојаности, јединица не говори ништа о рутама, DNS-у или томе да ли даља страна одговара.

То је чини лошим посредником за 'VPN је спреман'. Слушалац коме треба само локална адреса може бити задовољан постојањем интерфејса, док услуга која позива апликацију на далекој мрежи треба руте и доступност, што јединица уређаја не може изразити.

up, route-up и up-restart значе различите ствари

up се извршава након што се TUN/TAP уређај отвори и интерфејс конфигурише, што је прави тренутак за слушаоца који везује додељену адресу. route-up се извршава након инсталирања рута, подложно било ком конфигурисаном кашњењу руте, и одговара послу коме треба завршена фаза рута. Ниједно не доказује да далека апликација одговара. Избор између њих је питање шта услузи треба, а не која кука звучи завршеније.

Са persist-tun, рестарти поново користе уређај, па се up не извршава поново осим ако up-restart није постављен. Та опција омогућава up скрипту за документовани животни циклус рестарта, а њено окружење је смањено у поређењу са првим покретањем. Скрипта која претпоставља пуно окружење ради на првој вези и пада на следећој.

Пошаљите радњу без чекања на њу

Кука која синхроно позива systemctl restart може доћи у застој са јединицом чији редосијед чека тунел. systemctl --no-block try-restart vpn-dependent.service ставља посао у ред и враћа се, што спречава куку да блокира везу на коју је реаговала. try-restart делује само на покренуту јединицу, док restart покреће и неактивну; бирајте намерно, а не по навици.

Стављање у ред није провера. Кука враћа успех чим се посао прихвати, па провера мора да се догоди у дневнику циљне јединице или у њеном стварном стању слушаоца.

Политика рестарта живи у јединици, не у куки

oneshot јединица са RemainAfterExit=yes остаје активна након што њена наредба изађе, а други захтев за покретање не ради ништа јер systemd сматра да је већ покренута. То је својство око ког се пројектује, а не дефект који се заобилази поновљеним позивима покретања. Ако радња мора да се извршава по вези, јединици треба облик који то дозвољава.

After= пореда јединице, а BindsTo= везује животне векове, али ниједно не значи 'рестартуј ово кад год се VPN поново повеже'. Јединица везана за тунел се зауставља када се тунел заустави; не рестартује се сама када се тунел врати, осим ако је нешто поново не покрене.

Тестирајте три поновна повезивања, не једно

Хладно покретање, потпуни рестарт клијента и меко поновно повезивање сваки вежбају други пут. Меко поновно повезивање је оно које открива недостајући up-restart, смањено окружење или јединицу уређаја која никада није постала неактивна. Покрените сва три и потврдите оба смера: услуга делује када тунел устане, и не рестартује се на неповезане промене везе као што је Wi-Fi роаминг.

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