OpenVPN client-connect алдаа: disconnect үеийн цэвэрлэгээ баталгаатай юу?
Татгалзсан клиент галт хананы дүрэм эсвэл бичигдсэн бүртгэлийг буцаахгүй. Callback гэрээг hook өөрөө хийх ёстой буцаалттай харьцуулна уу.
Нэг client-connect скрипт тэгээс өөр кодтойгоор гарч байгаа үед OpenVPN клиентийг татгалзаж, операторууд ихэвчлэн харгалзах client-disconnect скрипт бүгдийг цэгцэлнэ гэж үздэг. Ихэнхдээ тэр огт ажилладаггүй, учир нь disconnect боловсруулалт нь connect үе шат юуг амжиж дуусгасанаас хамаардаг. Татгалзал ба буцаалтыг нэг механизм гэж үзэх нь бүтэлгүй нэвтрэлтийг гоожсон галт хананы дүрэм эсвэл эзэнгүй бүртгэл болгон хувиргадаг. Эдгээр нь хоёр тусдаа үүрэг бөгөөд зөвхөн нэг нь автомат юм. Серверийг төлөв үлдээсэн гэж буруутгахын өмнө hook-ийн өөрийн гарах замыг уншина уу.
Тэгээс өөр гаралт клиентийг татгалздаг; энэ нь таны ажлыг буцаахгүй
client-connect-ийн гаралтын төлөв нь элсэлтийн шийдвэр юм. Тэг гэдэг нь элсүүлэх, бусад бүх утга нь инстансыг бүрэн тогтоохоос өмнө нураах гэсэн үг. Тэр гэрээнд скрипт гадаад ертөнцөд юу хийснийг шалгах зүйл байхгүй. Хэрэв скрипт iptables дүрэм нэмсэн, мөр бичсэн эсвэл тоолуур нэмэгдүүлсэн бол тэдгээр өөрчлөлт нь татгалзалтыг даван туулна.
Мөн адил тэгш бус байдал нэмэлтүүдэд хамаарна, нэг инстансын хувьд хэд хэдэн connect функц ажиллаж болно. Хожуу гарсан алдаа нь өмнөх амжилтыг буцааж цуцлахгүй бөгөөд өмнөх функц нь ах дүү функц бүтэлгүйтсэнийг мэдэх аргагүй.
Татгалзал автомат, цэвэрлэгээ биш
OpenVPN 2.6 гарын авлага client-disconnect боловсруулалтыг өмнөх connect боловсруулалт амжилттай болсонтой холбодог. Баримтжуулсан үл хамаарах зүйл нь каскад гинжийг хамардаг: нэг connect алхам аль хэдийн амжилт буцаасан бол инстансыг нураах үед харгалзах disconnect алхмууд хожуу connect алхам бүтэлгүйтсэн ч ажиллана. Тэр үл хамаарах зүйл нарийн бөгөөд хэдэн callback тохируулснаас хамаардаг, тиймээс нэг shell скриптийг турших нь гинжин хэлхээний талаар танд юу ч хэлэхгүй.
Дизайн хийхээс өмнө бодит тохиргоог зураглана уу: аль скрипт, аль нэмэлт, ямар дарааллаар ажилладаг. Доорх хүснэгт хагас дууссан тохиргоо юу үлдээдэг болохыг жагсаав.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Мөр бүр клиентийн хувьд ижил, хостны хувьд өөрөөр төгсдөг. Аль нь болсныг клиент хэлж чадахгүй тул hook нь алдааны төлөвийг буцаахаас өмнө хийсэн зүйлээ буцаах ёстой.
Бүтэлгүйтсэн скриптийн дотор нөхөн төлбөр хий
Хуваалцсан төлөвт хүрэхээс өмнө боломжтой бүхнийг шалгана уу: гэрчилгээний талбарууд, хаягийн хүртээмж, клиентийн харьяалагдах бүлэг. Хамгийн хямд татгалзал бол ямар ч хуваарилалтаас өмнө тохиолддог нь юм. Тохиргоо хэд хэдэн гадаад үйлдлийг хамарсан үед аль нь дууссаныг бүртгэж, алдааны төлөвийг буцаахаас өмнө тэдгээрийг урвуу дарааллаар буцаана уу.
Тодорхой тохиолдол: скрипт клиент бүрт галт хананы бичлэг үүсгээд, дараа нь түүнийг дүрсэлсэн төлөвийн мөрийг бичиж чадахгүй. Бүтэлгүйтсэн салбар нь саяхан үүсгэсэн бичлэгийг устгаад дараа нь тэгээс өөр кодтойгоор гарах ёстой. Хэзээ ч төлөвлөгдөхгүй байж болох disconnect үйл явдлыг хүлээх нь дүрэм өөрт зориулсан сессийг хэтрүүлэн амьдрах арга юм.
Нөхөн төлбөрийг идемпотент, эзэнтэй болго
Цэвэрлэгээ нь хоёр удаа ажиллуулахад аюулгүй, юуг устгаж болох талаар нарийн байх ёстой. Өмнөх оролдлогын хожуу үйл явдал нь зөвхөн нийтлэг нэр эсвэл дахин ашигласан туннелийн хаягтай гэсэн шалтгаанаар шинэ сессийн хуваарилалтыг устгах ёсгүй. Тодорхой бариул эсвэл үйлдлийн ID-г нөөцтэй хамт бүртгэж, нэрээр биш, тэр түлхүүрээр устгана уу. Мэдээллийн сангийн гүйлгээ нь зөвхөн мэдээллийн сангийн өөрийн өөрчлөлтөд тусалдаг; тэр хилээс гадуурх галт хананы дүрэм тодорхой нөхөн төлбөрийн алхам шаарддаг.
Процесс өөрчлөлт ба цэвэрлэгээний хооронд үхэж болзошгүй гэж үзэж, хуваарийн дагуу гадаад төлөвийг хүлээн авсан клиентүүдийн жагсаалттай харьцуулдаг зохицуулагч нэмнэ үү.
Үнэхээр ялгаатай гурван замыг туршина уу
Гурван тохиолдлыг дадлагажуул: юу ч хуваарилагдахаас өмнөх татгалзал, хэсэгчилсэн хуваарилалтын дараах татгалзал, дараа нь дуусах ердийн хүлээн авсан сесс. Тэдгээр гурав нь өөр өөр лог мөр, өөр өөр үлдэгдэл үүсгэдэг. Тус бүрийн дараа гадаад төлөвийг шалга, зөвхөн клиентийн алдааны мессежийг биш, учир нь гуравын хоёрт клиентийн алдаа нь хүлээгдэж буй үр дүн юм.
hook-ийн үе шат, гаралтын төлөв, юу хуваарилагдсан эсвэл чөлөөлөгдсөнийг итгэмжлэлгүйгээр бүртгэнэ үү. Өөрийн үүсгэсэн нөөцийг нэрлэсэн hook-ийн лог нь гоожсон дүрмийг зургаан сарын дараа олох боломжтой болгодог.