Зошто вашиот 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 направата живее подолго од сесијата и проверката известува за здравје додека ништо не се пренесува.