Нэг удаагийн хугацаа дууссаны дараа таны 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-тай үед төхөөрөмж сешнээс урт насалж, юу ч зөөгдөхгүй байхад шалгалт эрүүл гэж мэдээлдэг.