Дүйшөмбү таңы: жума күнү көтөрүлгөн туннель жок, интерфейс дагы эле тизмеде турат, ал эми журналда аны бирөө байкаганы тууралуу эч нерсе жазылган эмес. Хост онлайн, такта жашыл, ал эми дем алыш күндөрү жөнөткөнүнүн баары физикалык интерфейс аркылуу чыгып кеткен. Бул жерде эки көз карандысыз чечим жетишпейт: бири кардар процессинин убактылуу бузулуудан аман калары тууралуу, экинчиси анын үстүндөгү бир нерсе процессти чыккандан кийин кайра баштайбы тууралуу. Бирөөнү гана оңдоо экинчи кемтикти ачык калтырат.

Мониторинг айткандан эмес, юнит чындап эмне кылганынан баштаңыз. 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 менен түзмөк сессиядан узак жашайт жана эч нерсе ташылбаса да текшерүү ден соолук тууралуу билдирет.

Тектеш макалалар