Рестартиране на услуга при OpenVPN up: куките побеждават tun0.device

Свързването на зависима услуга с tun0.device изглежда като абониране за тунела, но не е. Устройственият unit отразява, че интерфейсът съществува, което може да остане вярно през неуспешна връзка и последващото повторно свързване. Тогава услугата действа в неподходящия момент или никога, в зависимост от това дали интерфейсът е изчезнал помежду. Куката, която описва събитието, което наистина ви интересува, е тази, която извиква OpenVPN, а не тази, която извежда systemd.

Решете кое условие е нужно на услугата, преди да изберете задействащото събитие, защото трите кандидата не са взаимозаменяеми.

Какво всъщност следи устройственият unit

systemd създава устройствен unit от представата на ядрото за мрежов интерфейс, така че tun0.device става активен, когато интерфейсът се появи, и неактивен, когато бъде премахнат. С persist-tun мекият рестарт оставя интерфейса на място, така че unit-ът никога не мига и нищо вързано към него не се задейства. Дори без устойчивост unit-ът не казва нищо за маршрути, DNS или дали далечната страна отговаря.

Това го прави лош заместител на 'VPN е готов'. Слушател, който се нуждае само от локалния адрес, може да се задоволи със съществуването на интерфейса, докато услуга, която извиква приложение в отдалечената мрежа, се нуждае от маршрути и достъпност, които устройственият unit не може да изрази.

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

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

С persist-tun рестартите използват отново устройството, така че up не се изпълнява отново, освен ако up-restart не е зададено. Тази опция включва up скрипта за документирания жизнен цикъл на рестарт, а средата му е намалена в сравнение с първото стартиране. Скрипт, който предполага пълната среда, работи при първата връзка и се проваля при следващата.

Изпратете действието, без да го чакате

Кука, която извиква systemctl restart синхронно, може да блокира срещу unit, чиято подредба чака тунела. systemctl --no-block try-restart vpn-dependent.service поставя задачата в опашка и се връща, което не позволява на куката да блокира връзката, на която е реагирала. try-restart действа само върху работещ unit, докато restart стартира и неактивен; избирайте нарочно, а не по навик.

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

Политиката за рестарт живее в unit-а, не в куката

oneshot unit с RemainAfterExit=yes остава активен след излизане на командата и второ искане за стартиране не прави нищо, защото systemd го смята за вече стартирано. Това е свойство, около което се проектира, а не дефект, който се заобикаля с повтарящи се извиквания за стартиране. Ако действието трябва да се изпълнява при всяка връзка, unit-ът се нуждае от форма, която го позволява.

After= подрежда unit-ите, а BindsTo= свързва животите, но нито едно от двете не значи 'рестартирай това при всяко повторно свързване на VPN'. Unit, вързан към тунела, спира, когато тунелът спре; той не се рестартира сам, когато тунелът се върне, освен ако нещо не го стартира отново.

Тествайте три повторни свързвания, не едно

Студено стартиране, пълен рестарт на клиента и меко повторно свързване всяко изпробва различен път. Мекото повторно свързване е това, което разкрива липсващо up-restart, намалена среда или устройствен unit, който никога не е ставал неактивен. Изпълнете и трите и потвърдете в двете посоки: услугата действа, когато тунелът се вдигне, и не се рестартира при несвързани промени на връзката като Wi-Fi роуминг.

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