Чаму ваш кліент 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 прылада перажывае сеанс, і праверка паведамляе пра здароўе, пакуль нічога не перадаецца.