OpenVPN client-connect катасы: disconnect учурундагы тазалоо кепилденгенби?
Четке кагылган клиент firewall эрежесин же жазылган жазууну кайтарбайт. Callback келишимин hook өзү аткарууга тийиш болгон кайтаруу менен салыштырыңыз.
Кээде client-connect скрипти нөл эмес код менен чыкканда, OpenVPN клиентти четке кагат, ал эми операторлор адатта тиешелүү client-disconnect скрипти баарын жөнгө салат деп ойлошот. Көбүнчө ал такыр иштебейт, анткени disconnect иштетүү connect баскычы эмнени бүтүрө алганына көз каранды. Четке кагуу менен кайтарууну бир механизм деп кароо — ийгиликсиз кирүүнү агын firewall эрежесине же ээсиз жазууга айландырат. Булар эки өзүнчө милдет, жана алардын бирөө гана автоматтык. Серверди абал калтырды деп күнөөлөөдөн мурун 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 ийгиликсиздик статусун кайтармайынча эмне кылганын кайтарышы керек.
Ийгиликсиз болгон скрипттин ичинде компенсация жасаңыз
Жалпы абалга тийишпестен мурун мүмкүн болгондун баарын текшериңиз: сертификат талааларын, даректин жеткиликтүүлүгүн, клиент кирген топту. Эң арзан четке кагуу — эч кандай бөлүштүрүүгө чейин болгону. Орнотуу бир нече сырткы операцияны камтыганда, кайсылары бүткөнүн жазып туруңуз жана ийгиликсиздик статусун кайтармайынча аларды тескери тартипте кайтарыңыз.
Так учур: скрипт ар бир клиент үчүн firewall жазуусун түзөт, анан аны сүрөттөгөн абал сабын жазууга ийгиликсиз болот. Ийгиликсиз тармак жаңы эле түзгөн жазууну алып салып, анан нөл эмес код менен чыгышы керек. Эч качан пландалбашы мүмкүн болгон disconnect окуясын күтүү — эреженин өзү арналган сессиядан узак жашоосунун жолу.
Компенсацияны идемпотенттүү жана ээси бар кылыңыз
Тазалоо эки жолу иштетүүгө коопсуз болушу жана эмнени жок кыла алары боюнча так болушу керек. Мурунку аракеттин кеч окуясы жаңыраак сессиянын бөлүштүрүүсүн эки тарап тең жалпы атка же кайра иштетилген туннель дарегине ээ болгондуктан гана алып салбашы керек. Так тутканы же операция идентификаторын ресурс менен бирге жазып, ат менен эмес, ошол ачкыч менен жок кылыңыз. Маалымат базасынын транзакциялары маалымат базасынын өз өзгөртүүлөрүндө гана жардам берет; ошол чектен тышкаркы firewall эрежеси ачык компенсация кадамын талап кылат.
Процесс өзгөртүү менен тазалоонун ортосунда өлүшү мүмкүн деп эсептеңиз жана сырткы абалды кабыл алынган клиенттер тизмеси менен график боюнча салыштырган жараштыруучу кошуңуз.
Чындап айырмаланган үч жолду сынаңыз
Үч учурду машыктырыңыз: эч нерсе бөлүштүрүлө электе четке кагуу, жарым-жартылай бөлүштүрүүдөн кийинки четке кагуу жана кийин бүткөн кадимки кабыл алынган сессия. Бул үчөө ар башка журнал саптарын жана ар башка калдыктарды берет. Ар биринен кийин сырткы абалды текшериңиз, клиенттин ийгиликсиздик билдирүүсүн гана эмес, анткени үчөөнүн экөөндө клиенттин ийгиликсиздиги күтүлгөн натыйжа.
hookтун баскычын, чыгуу статусун жана эмне бөлүштүрүлгөнүн же бошотулганын каттоо маалыматтарысыз жазыңыз. Өзү түзгөн ресурсту атаган hook журналы — агын эрежени алты айдан кийин табууга мүмкүндүк берген нерсе.