OpenVPN-ийн дэгээ скрипт өөрийн дөнгөж бүтээсэн туннелийг ашиглаж чадах уу?

Дэгээ скрипт туннелийн нөгөө талд хүрэх эсэх нь гурван нөхцөлөөс хамаарна: аль үйл явдалд холбогдсон, скрипт ажиллах үед OpenVPN өөрийн эхлэлтийн дараалалд байгаа эсэх, ажил тэр дарааллаас тусгаарлагдсан эсэх. Ихэнх скрипт гурав дахь нөхцөлд бүтэлгүйтдэг. Унтахыг нэмэх нь амьдралын мөчлөгийн асуудлыг цаг хугацааны асуудал гэж үздэг бөгөөд төөрөгдүүлэхэд хангалттай байнга ажилладаг.

Эхлээд үйл явдлыг, дараа нь ажлыг хойшлуулах механизмыг, дараа нь хойшлуулсан ажил ажиллах газрыг шийдээрэй. Эдгээр гурван шийдвэр бие даасан бөгөөд тэдгээрийг хольсон нь хоёр мөрт дэгээг бүтэн үдэш болгодог.

Дэгээ яагаад өөрийгөө хүлээж буй туннелийг хүлээдэг вэ

OpenVPN дэгээнүүдээ пакетыг зөөдөг ижил процессын дотор синхроноор дууддаг. up нь tun эсвэл tap төхөөрөмж байгаа үед боловч ямар ч зам нэмэгдэхээс өмнө ажилладаг, route-up нь замуудын дараа ажилладаг; эдгээр мөчүүдийн аль нь ч эсрэг тал хариу өгнө гэж амлахгүй. Аль ч дэгээний скрипт ажиллаж байтал демон дамжуулахгүй байдаг тул туннелээр урсгал өнгөрнө гэж хүлээж буй команд өөрийг нь хүлээж буй туннелийг хүлээнэ. Энэ дугуй хүлээлт нь гараар ажиллуулахад давж, дэгээ хугацаа хэтэрдэг шалтгаан юм.

Тодорхой засвар, өөрөөр хэлбэл хэдэн секунд унтах нь заримдаа ажилладаг, учир нь хол тал өөрөө боссон, унтах нь ямар нэг зүйлийг зассандаа биш. Бэлэн байдлыг асуудаг туслах нь өөр хариулт: дэгээ буцаж, дамжуулалт эхэлж, туслах хэрэгтэй зүйлээ тэр үнэхээр байгаа үед авдаг.

Дэгээг тав тух биш, үйл явдлаар сонгоорой

up-г зөвхөн төхөөрөмж хэрэгтэй ажилд, route-up-г зам хэрэгтэй ажилд холбож, client-connect болон client-disconnect-г серверийн талд үйлчлүүлэгч тус бүрийн даалгаварт үлдээгээрэй. Салгах үеийн цэвэрлэгээ хоёр удаа ажиллахыг тэвчих ёстой, учир нь тогтмол интерфэйсээр дахин холбогдох нь бүрэн дахин эхлүүлэлтийн ижил дарааллыг дагадаггүй. Серверт client-connect нь демон эхлэх үед биш, үйлчлүүлэгч нэвтрэх үед ажилладаг бөгөөд логикийг тэнд зөөхөөс өмнө үүнийг баталгаажуулах нь зүйтэй. Хэрэв ажил нэг холболтод биш, үйлчилгээний амьдралын мөчлөгт хамаарах бол systemd нэгж нь ямар ч дэгээнээс илүү сайн газар.

Дэгээний командуудыг демон шууд гүйцэтгэдэг, хооронд нь бүрхүүл байхгүй тул up мөрөнд байгаа ifconfig_remote шууд утгаараа текст болж ирдэг. Командыг тодорхой бүрхүүлд ороож, эсвэл логикийг орчныг уншдаг скриптэд байлгаарай. ipchange нь өөрийн аргументуудыг нэмдэг нэг заавар: тэрээр команд руу хаяг, портыг дамжуулдаг тул хэнд ч зориулж бичээгүй скрипт хоёр гэнэтийн аргумент хардаг.

Ажлыг тусгаарлах гурван арга

Эхний сонголт нь туслахыг дэгээний дотроос арын дэвсгэрт явуулах: setsid эсвэл systemd-run --scope-ээр эхлүүлж, өвлөгдсөн тодорхойлогчдыг хааж, тэр даруй тэгээр гарна. Хоёр дахь нь дэгээ жижиг төлөвийн файл бичиж, systemd таймер эсвэл замын нэгж түүн дээр ажиллах бөгөөд энэ нь дэгээг энгийн байлгаж, дахин оролдлогын бодлогыг лог байдаг газарт байрлуулдаг. Гурав дахь нь дэгээг бүрмөсөн орхиж, ажлыг VPN үйлчилгээний дараа эрэмбэлсэн нэгж рүү зөөх бөгөөд ажил огт холболтын биш бол энэ нь зөв хариулт юм. Гурвуулаа нэг дүрмийг хуваалцдаг: дэгээ туннель хэрэгтэй болохоос өмнө буцаж ирэх ёстой.

Юу ч сонгосон, туслахыг идемпотент, ажиглах боломжтой болго. Хоёр давхцсан дуудлага ижил буцаах боломжгүй үйлдлийг хоёр удаа гүйцэтгэх ёсгүй, бүтэлгүйтсэн туслах хүн уншиж чадах зүйлийг үлдээх ёстой.

Sandbox-ийн алдааг амьдралын мөчлөгийн алдаанаас тусгаарла

Скрипт root промптоос ажиллаж, үйлчилгээ болж бүтэлгүйтвэл шалтгаан нь ихэвчлэн сүлжээ биш, sandbox. Хязгаарласан ProtectHome, зөвхөн унших ProtectSystem эсвэл байхгүй ажлын хавтас скрипт эсвэл түүний өгөгдлийг хүрэхгүй болгож болно, SELinux хост дээр файлд гүйцэтгэхийг зөвшөөрөх контекст ч хэрэгтэй. Нэгжийг systemctl cat openvpn-server@server-ээр, журналыг journalctl -u openvpn-server@server -n 80-ээр уншаад, холболтын хугацаа хэтрэлт биш, зөвшөөрөл эсвэл контекстийн алдаа хай. Sandbox-ыг идэвхгүй болгох нь эхний биш, сүүлчийн алхам байх ёстой.

Амьдралын мөчлөгийн алдаа өөр харагдана: дэгээ эхэлж, туслах ажиллаж, сокет нь хараахан байхгүй байна. Дэгээнээсээ цагийн тэмдэгтэй мөр бичиж, салгаад дахин холбогдож, үйл явдлуудыг дараалан унш. Туслах туннель үнэхээр хэрэгтэй бол тогтсон хугацаа унтахын оронд бэлэн байдлыг асуугаарай.

Гурван талбар дараагийн тайланг ашигтай болгоно: аль дэгээ ажиллав, ямар бүртгэл ашиглав, хаана зогсов. Тэдгээргүйгээр дараагийн мөрдөн шалгалт бүр эхнээсээ эхэлдэг.