Неге сіздің 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, ол физикалық арна арқылы сәтті болудың орнына сәтсіз болуы керек. Сәттілік брандмауэр ережесі жоқ немесе тым рұқсатшыл екенін білдіреді.

Қайта қосылыңыз, туннель қайтадан трафик тасымалдайтынын растаңыз, содан кейін ғана тексеруді мониторингке қосыңыз. cron арқылы ip addr сұрауы tun құрылғысы үшін ең жиі сәтсіз болатын қадағалау, өйткені persist-tun кезінде құрылғы сессиядан ұзақ өмір сүреді және ештеңе тасымалданбаса да тексеру денсаулық туралы хабарлайды.