keepalive в OpenVPN или restart в systemd: кое възстановява връзката?

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

Три повреди, които изглеждат като една

Мълчанието на партньора означава, че другият край е спрял да изпраща, и OpenVPN може да го открие сам, защото притежава пулса. Смъртта на процеса означава, че демонът е излязъл, което управителят на услуги забелязва, а OpenVPN не може. Повредата на приложението означава, че тунелът е наред, а нещо зад него не е, и нито един от другите два механизма няма как да знае. Всяко от тях изисква различна реакция и нито едно не е същото като забелязването, че тунелът работи.

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

Запишете трите случая, преди да промените който и да е таймер. Самият списък обикновено показва, че от един механизъм се иска да покрие и трите.

До какво всъщност се разгръща keepalive

Директивата keepalive е съкращение и разгръщането зависи от режима. На сървър keepalive 10 60 се превръща в локален ping на всеки десет секунди, локален таймаут за рестарт от 120 секунди и стойности 10 и 60, изпращани към клиентите. Таймаутът на сървъра е умишлено удвоен, за да има клиентът шанс да рестартира, преди сървърът да се откаже. Четете разгърнатата форма в работещата конфигурация, а не съкращението в профила.

Това удвояване е причината всяко описание, което твърди, че двата края рестартират след шестдесет секунди, да е грешно. То обяснява и защо двата края не трептят в синхрон, когато пътят се влоши.

Пулсът е трафик между партньорите на OpenVPN, а не ICMP проба на някакъв публичен хост. Отговорът доказва само, че далечният край на тунела е жив. Той не казва нищо за базата данни или уеб услугата, от която потребителят наистина се нуждае.

Какво не следи Restart=on-failure

Прочетете инсталирания юнит, преди да добавите замяна. Restart=on-failure реагира на документирани условия за повреда на процеса, което не е същото като наблюдение на състоянието на връзката. Той не се задейства, защото е започнало вътрешно повторно свързване, а чистото излизане има различна семантика от срива.

Това разграничение е важно, защото вътрешният рестарт запазва същия процес жив. Юнитът не вижда нищо, тунелът се възстановява сам и това е правилният резултат.

Задайте RestartSec и лимити за стартиране умишлено, иначе цикъл от сривове ще удря шлюза и ще зарови истинската грешка под съобщения за рестарт. Лимит за рестарт, който се задейства, оставя юнита в състояние на повреда, което се вижда, докато неограничен цикъл не се вижда.

ping-restart и ping-exit не са взаимозаменяеми

ping-restart задейства вътрешния рестарт на OpenVPN и запазва процеса. ping-exit прекратява процеса при същия вид таймаут, което предава решението на управителя на услуги. Те са взаимно изключващи се и изборът на второто променя кой притежава възстановяването. Разликата е кой решава да опита отново и колко състояние оцелява при опита.

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

Изберете един жизнен цикъл за всяко внедряване и запишете защо. Профил, който носи и двете директиви, е профил, който не е решил.

Тествайте всяка повреда като отделен случай

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

Повтарящото се възстановяване също не е поправка. Отхвърлените идентификационни данни или два клиента, споделящи едно ефективно име, ще продължат да се заменят взаимно и по-бързите таймери само правят това трептене по-бързо.