Защо вашият клиент OpenVPN спира след един таймаут

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

Започнете от това, което unit-ът наистина е направил, а не от това, което твърди мониторингът. 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 означава десет секунди тишина преди проверка и шестдесет преди рестарт, което е агресивно за мобилна връзка със загуби и разумно за кабелна. Запишете причината до реда, иначе следващият читател ще приеме, че стойностите по подразбиране са били умишлени.

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

Наблюдение, което наистина рестартира unit-а

На хост със 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, вместо да предполагате, че стойността е пристигнала. Инстанцията в името на файла трябва да е профилът, който unit-ът наистина зарежда, така че файл, написан за office, не прави нищо за openvpn-client@home.

on-failure пренебрегва един случай: чист изход със статус нула. Някои пътища на приключване завършват така, затова четете записания статус, вместо да вярвате на формулировката от ръководството. Ако клиентът ви се откаже с нула, трябва ви Restart=always, а цената е, че наистина счупен профил се връща отново и отново, докато ограничението за скорост на стартиране се задейства и журналът се напълни.

Restart=always се задейства и след умишлено спиране. Използвайте systemctl stop за поддръжка и маскирайте unit-а, ако трябва да остане спрян, докато работите.

Хванете изтичането, докато тунелът е спрян

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

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

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

Свържете се отново, потвърдете, че тунелът отново носи трафик, и едва тогава добавете проверката към мониторинга. Анкетирането на ip addr от cron за устройство tun е наблюдението, което се проваля най-често, защото с persist-tun устройството живее по-дълго от сесията и проверката съобщава за здраве, докато нищо не се пренася.